Can systemctl list all enabled services, including legacy services

init-scriptlsbstartupsystemdsysvinit

This question asks: "How to list all enabled services from systemctl?" Answers on that page include:

systemctl list-unit-files | grep enabled
systemctl list-unit-files --state=enabled

At least as of systemd version 229 (on Ubuntu 16.04), systemctl list-unit-files will not include "LSB" services that are launched via legacy init scripts.

Therefore, the original question seems to remain unanswered: Can systemd display a list of ALL the services (and other unit types) that it will try to start at boot, including legacy services?

Consider:

$ systemctl list-units | grep LSB | grep grub
  grub-common.service    loaded    active exited    LSB: Record successful boot for GRUB

$ systemctl list-unit-files | grep enabled | grep grub || echo 'nothing found'
nothing found

$ systemctl is-enabled grub-common
grub-common.service is not a native service, redirecting to systemd-sysv-install
Executing /lib/systemd/systemd-sysv-install is-enabled grub-common
enabled

systemctl knows about grub-common, and if you ask explicitly systemctl will tell you it is enabled.

So… is there a way to get systemd to display a list of ALL the services it will attempt to run at boot, including legacy scripts?

Best Answer

I believe the command you want is:

systemctl list-units --type service --all

This from my test lists all service even those from legacy boot services.

Source:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sect-managing_services_with_systemd-services

Related Solutions

Ubuntu – All services of a user are killed when running multiple services under this user with systemd

The changelog for systemd (v230) says:

systemd-logind will now by default terminate user processes that are part of the user session scope unit (session-XX.scope) when the user logs out. This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of "no" is now changed to "yes". This means that user sessions will be properly cleaned up after, but additional steps are necessary to allow intentionally long-running processes to survive logout.

So this is default behaviour. It also explains what to do to undo the change: logind.conf, set KillUserProcesses= to no (and --without-kill-user-processes option to configure)

But the changelog also includes a ...

While the user is logged in at least once, user@.service is running, and any service that should survive the end of any individual login session can be started at a user service or scope using systemd-run. systemd-run(1) man page has been extended with an example which shows how to run screen in a scope unit underneath user@.service. The same command works for tmux.

and

After the user logs out of all sessions, user@.service will be terminated too, by default, unless the user has lingering enabled. To effectively allow users to run long-term tasks even if they are logged out, lingering must be enabled for them. See loginctl(1) for details. The default polkit policy was modified to allow users to set lingering for themselves without authentication.

That one is more important since it uses the default (kill'm all) with a way to provide exceptions: enable lingering.

Some more info:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394

Init service failing to enable once a systemd service file is generated

I've now found that the issue was that the service file automatically generated by systemd-sysv-generator lacks an install section with a WantedBy option. I added the following to my generated file at /etc/systemd/system/programexample.service which allowed me to properly enable the service:

[Install]
WantedBy = multi-user.target

After that I ran

systemctl daemon-reload

to ensure my service file was read by systemd.

Now I received a proper notification that my service was actually symlinked somewhere to be "enabled":

[root@centos7-box ~]# systemctl enable programexample.service
Created symlink from /etc/systemd/system/multi-user.target.wants/programexample.service to /etc/systemd/system/programexample.service.

This link helped me better understand the service file.

I am not a fan of the way that systemd-sysv-generator does not include an install section with a WantedBy option by default. If systemd can dynamically read the LSB headers and properly start services at boot, why doesn't it generate the service file accordingly? I suppose some systemd growing pains are to be expected.

Update July 7 2020:

Working with Debian Buster and trying to enable a SysVInit legacy service, I was presented with this wonderful message, which I believe would have saved me some time when I dealt with this issue in 2017:

Synchronizing state of programexample.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable programexample
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled using systemctl. 
Possible reasons for having this kind of units are:

• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

Best Answer

Related Solutions

Ubuntu – All services of a user are killed when running multiple services under this user with systemd

Init service failing to enable once a systemd service file is generated

Related Question