Jump to content

Installation issue: Failed to connect to bus


Bazze
 Share

Recommended Posts

Hello!

I'm dockerizing the ESET Remote Administrator and trying to get it to run locally, however, I'm facing an unknown error during installation as well as a "Failed to connect to bus" error. See installation log in the bottom of this post. Just below here I'll highlight the errors occurring.

OS: Ubuntu 16.04

 

This error occurs at first installation attempt, the error number is different every time.

Failed to get unit file state for eraserver.service: Unknown error 1778006384

 

The error below occurs at first installation attempt, but persist the next time I try the installation (and the status of the install is then in REPAIR instead).

Failed to connect to bus: No such file or directory

 

Complete output of first installation attempt.

ESET Remote Administrator Server Installer (version: 6.5.417.0), Copyright © 1992-2017 ESET, spol. s r.o. - All rights reserved.

Extracting archive, please wait...
Archive extracted to /tmp/tmp.jHO0z5kSD5.
Checking OpenSSL ... done [OpenSSL 1.0.2g 1 Mar 2016]
Reading previous installation settings ... failure
Checking installed version... done
Status of current installation is: NEW
Checking database connection ... done
Loading GUID ... done [GUID = adec6e18-45b1-4556-990d-0fa85c98d273]
Inserting root password ... done
Generating certificates ... done
Skipping static groups synchronization scheduling.
Stopping service... Creating database ... done
Storing ports into configuration ... done
Storing server peer certificate to configuration ... done
Moving scripts from '/tmp/tmp.jHO0z5kSD5/setup/Scripts' to /var/opt/eset/RemoteAdministrator/Server/Scripts/... done
Moving ESET Modules from '/tmp/tmp.jHO0z5kSD5/setup/Modules' to /var/opt/eset/RemoteAdministrator/Server/Modules/... done
Creating 'config' directory path: /etc/opt/eset/RemoteAdministrator/Server
Creating 'libs' directory path: /opt/eset/RemoteAdministrator/Server
Creating 'data' directory path: /var/opt/eset/RemoteAdministrator/Server
Creating 'logs' directory path: /var/log/eset/RemoteAdministrator/Server
Moving LangData.dat to /var/opt/eset/RemoteAdministrator/Server/Localization/LangData.dat... done
Extracting ReportPrinter files... done
Creating startup configuration file /etc/opt/eset/RemoteAdministrator/Server/StartupConfiguration.ini ... done
Creating config file /etc/opt/eset/RemoteAdministrator/Server/config.cfg ... done
Backing up contents of /opt/eset/RemoteAdministrator/Server
Copying files to target destination: /opt/eset/RemoteAdministrator/Server
Copying installer to target destination: /opt/eset/RemoteAdministrator/Server/setup/installer_backup.sh
File ownership set to: root:root
Setting auto-start service...
Failed to get unit file state for eraserver.service: Unknown error 1778006384
Failed to connect to bus: No such file or directory

 

I'm pretty stuck, can't really find anything online about this error and I was unable to pinpoint the issue by looking at the "server-linux-x86_64.sh" source code. Any tips or pushes in some direction would be very much appreciated!

Thanks

Edited by Bazze
Link to comment
Share on other sites

  • ESET Staff
6 hours ago, Bazze said:

I'm pretty stuck, can't really find anything online about this error and I was unable to pinpoint the issue by looking at the "server-linux-x86_64.sh" source code. Any tips or pushes in some direction would be very much appreciated!

Thanks

In short: ERA installer tries to register daemon startup using /bin/systemctl (systemd) which fails. This is caused by fact, that it either does not work at all, or is not properly configured. Simplest solution is to remove file /bin/systemctl (or move/rename) before SERVER installer is started, so that it is not detected.

ERA tries 3 daemon management alternatives in this order:

  1. systemd (checks present of systemctl command)
  2. upstart (checks present of initctl command)
  3. init-scripts

Our experience is that in dockerized environment, first two are almost never working - there are even containers where tools is available, but it is instantly crashing when called from inside of container, so workaround we are using is to remove first two command line tools, so that plain init-scripts are used.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...