Bazze 1 Posted February 14, 2018 Share Posted February 14, 2018 (edited) 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 February 14, 2018 by Bazze Link to comment Share on other sites More sharing options...
ESET Staff MartinK 383 Posted February 14, 2018 ESET Staff Share Posted February 14, 2018 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: systemd (checks present of systemctl command) upstart (checks present of initctl command) 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 More sharing options...
Bazze 1 Posted February 14, 2018 Author Share Posted February 14, 2018 Thanks @MartinK for the quick answer. Deleting /bin/systemctl did the trick, the installation was now successful. Link to comment Share on other sites More sharing options...
Recommended Posts