1

I recently upgraded my server from Ubuntu V14.04 to V16.04 and now systemctl doesn't seem to work anymore.

I need to prevent transmission-daemon from starting automatically on boot so I issue the command

sudo systemctl disable transmission-daemon.service

And I get the following response

Synchronizing state of transmission-daemon.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install disable transmission-daemon
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
The script you are attempting to invoke has been converted to an Upstart job, but lsb-header is not supported for Upstart jobs.
insserv: warning: script 'screen-cleanup' missing LSB tags and overrides
insserv: Default-Start undefined, assuming empty start runlevel(s) for script `screen-cleanup'
insserv: Default-Stop  undefined, assuming empty stop  runlevel(s) for script `screen-cleanup'
insserv: warning: current start runlevel(s) (empty) of script `transmission-daemon' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `transmission-daemon' overrides LSB defaults (0 1 6).
initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused

The service does not become disabled


Update Per @JdeBP deleting the screen-cleanup script resolved the problem

$ sudo rm /etc/init.d/screen-cleanup
$ sudo systemctl disable transmission-daemon.service

Synchronizing state of transmission-daemon.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install disable transmission-daemon
insserv: warning: current start runlevel(s) (empty) of script `transmission-daemon' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `transmission-daemon' overrides LSB defaults (0 1 6).
insserv: warning: current start runlevel(s) (empty) of script `transmission-daemon' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `transmission-daemon' overrides LSB defaults (0 1 6).

I can see the service is now disabled as required

systemctl status transmission-daemon
● transmission-daemon.service - Transmission BitTorrent Daemon
   Loaded: loaded (/lib/systemd/system/transmission-daemon.service; disabled; ve
  Drop-In: /etc/systemd/system/transmission-daemon.service.d
           └─local.conf
   Active: active (running) since Thu 2018-03-08 08:16:00 EST; 2 days ago
 Main PID: 2423 (transmission-da)
   Status: "Uploading 329.89 KBps, Downloading 11.04 KBps."
   CGroup: /system.slice/transmission-daemon.service
           └─2423 /usr/bin/transmission-daemon -f --log-error -g /etc/transmissi
  • Answers belong in answers, not in questions. – JdeBP Aug 22 '18 at 8:11
6

/lib/systemd/systemd-sysv-install is a hook whose job is to do the non-native enable/disable actions that systemd-sysv-generator and other service management systems will recognize. Ubuntu's /lib/systemd/systemd-sysv-install simply calls Ubuntu's /usr/sbin/update-rc.d. That in turn calls /sbin/insserv. That in turn sees that there's a van Smoorenbug rc script in /etc/init.d and tries to get LSB header information from it.

/sbin/insserv has a special case where it recognizes when the van Smoorenburg rc script that it has found is really a symbolic link to Upstart's /lib/init/upstart-job program. Because that's a generic program that fills in for many van Smoorenburg rc scripts, it won't have LSB header information appropriate to specific services. So /sbin/insserv tries to invoke the rc script, really /lib/init/upstart-job, with the lsb-header subcommand to get it to calculate and print out the right LSB headers for the service.

But /lib/init/upstart-job does not in fact support that subcommand. The softwares were never integrated properly. /lib/init/upstart-job runs initctl, which tries to connect to a running Upstart service manger and of course fails (because one is not running) and prints the first error that you see about not being able to connect to socket /com/ubuntu/upstart, and then it prints the second error that you see about the lsb-header subcommand not being supported "for Upstart jobs" (even though those were what it was for).

The upshot is that it all goes wrong.

It has been going wrong for years. One can find people reporting this bug, which of course happened when people ran insserv directly or indirectly under Upstart and van Smoorenburg init too, going back well over a decade at this point. It was asked about on AskUbuntu in 2016. It is several Launchpad bugs such as this one from 2016.

Interestingly, in one of those Launchpad bugs, one from 2010, someone attempted to supply a patch so that upstart-job would understand the lsb-header subcommand and give insserv at least something to work with, even if it was fairly uninformative. Nobody, except some users who did not have the access to fix the software themselves, noticed.

Of course, these van Smoorenburg rc scripts are wrappers around Upstart for the benefit of softwares and people that do not understand how to drive Upstart directly with initctl, but do know how to drive the old van Smoorenburg rc scripts. However, you are using Ubuntu 16; a systemd operating system. systemd's backwards compatibility mechanism is taking some van Smoorenburg rc scripts that themselves are something else's backwards compatibility mechanism, wrapping them up in systemd native units, and ending up trying to reflect commands sent to a systemd service manager to an Upstart service manager that isn't there.

This is just ludicrous.

  1. Find the symbolic link in /etc/init.d that is pointing to /lib/init/upstart-job. By the looks of things it is /etc/init.d/screen-cleanup.
  2. Remove it.

The icing on the cake is that transmission-daemon is controlled by a native systemd service unit (/lib/systemd/system/transmission-daemon.service) on Ubuntu 16, and van Smoorenburg rc backwards compatibility mechanisms and /lib/systemd/systemd-sysv-install do not apply to it in the first place.

Further reading

  • Very detailed. Might want to draw the reader's eyes to the solution at the bottom and leave the history lesson to those that want more depth. Great answer though! – Patrick Aug 22 '18 at 2:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.