I'm trying to un-configure or remove a systemd wrapper script for an old sysV service. The wrapper is provided by a Debian package so I can't just delete it.

The wrapper shows up as an artifact and is listed as "generated":

$ systemctl list-unit-files | grep -i -E 'rng|rand'
rng-tools.service                      generated
systemd-random-seed.service            static
urandom.service                        static

I added a new systemd service to replace it according to Creating and Modifying systemd Unit Files:

# touch /etc/systemd/system/rng-tools.service
# chmod 664 /etc/systemd/system/rng-tools.service
# emacs /etc/systemd/system/rng-tools.service
<edit file>

However, when I try to enable the new service file the old sysV script is used instead:

# systemctl enable rng-tools
Synchronizing state of rng-tools.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable rng-tools

Searching has turned up 0 hits to remove the old wrapper. I get lots of similar hits, like creating a wrapper script. But I have not found information on removing one from systemd's database.

How do I un-configure or remove a systemd wrapper script for sysV service?

And here are the result after Stephen's suggestion. The new rng-tools.service is being used:

$ systemctl status rng-tools
● rng-tools.service - Entropy daemon for /dev/random using a hardware RNG
   Loaded: loaded (/etc/systemd/system/rng-tools.service; enabled; vendor preset
   Active: failed (Result: exit-code) since Mon 2018-10-15 07:19:32 EDT; 20min a
 Main PID: 674 (code=exited, status=1/FAILURE)


# journalctl -b -u rng-tools.service
-- Logs begin at Mon 2018-10-15 07:19:29 EDT, end at Mon 2018-10-15 07:49:13 EDT. --
Oct 15 07:19:31 beaglebone systemd[1]: Started Entropy daemon for /dev/random using a hardware RNG.
Oct 15 07:19:31 beaglebone rngd[674]: can't open /dev/hwrng: No such file or directory
Oct 15 07:19:32 beaglebone systemd[1]: rng-tools.service: Main process exited, code=exited, status=1/FAILURE
Oct 15 07:19:32 beaglebone systemd[1]: rng-tools.service: Unit entered failed state.
Oct 15 07:19:32 beaglebone systemd[1]: rng-tools.service: Failed with result 'exit-code'.


# dd if=/dev/hwrng count=16 bs=1
▒▒▒▒ȿ▒3▒▒ ▒▒#16+0 records in
16+0 records out
16 bytes (16 B) copied, 0.00942799 s, 1.7 kB/s

And for completeness, here is the new rng-tools.service:

# cat /etc/systemd/system/rng-tools.service
# ...

Description=Entropy daemon for /dev/random using a hardware RNG

ExecStart=/usr/sbin/rngd -r /dev/hwrng -f

Synchronizing state of rng-tools.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable rng-tools

only means that systemd is “aware” that there’s a sysvinit-style init script present, and that it needs to take it into account when considering the state of the rng-tools service. It doesn’t mean that it’s going to use the init script to manage the service.

If both an init script and a unit file are present, systemd will use the latter (at least, when the service isn’t running).

You can see which file is used to start a service by running systemctl status; the “Loaded” line will show which script was used. For example, here’s a service which has both a systemd unit and an init script:

● infnoise.service - Wayward Geek InfNoise TRNG driver
   Loaded: loaded (/lib/systemd/system/infnoise.service; enabled; vendor preset: enabled)

Here’s a service which only has an init script:

● sensord.service - LSB: lm-sensors daemon
   Loaded: loaded (/etc/init.d/sensord; generated; vendor preset: enabled)

Checking your service should show that systemd is using your new unit.

If all else fails, you can delete /etc/init.d/rng-tools: it should be tracked as a conffile, and dpkg will note that it was deleted and won’t restore it on package upgrades. /etc is owned by the system administrator, not the packaging system, even though packages can install files there.

  • Thanks @Stephen. OK, so I removed the changes to rc.local that manually enabled rng-tools, and I left the new rng-tools.service in place. Unfortunately no joy. The service did not start and /dev/random is out of entropy. But it does look like the new service was used. It is amazing /usr/sbin/rngd -r /dev/hwrng -f works from rc.local but not rng-tools.service. – user56041 Oct 15 '18 at 11:32
  • What does systemctl status show after trying to start the service? Could it be that /dev/hwrng isn’t available early enough? – Stephen Kitt Oct 15 '18 at 11:38
  • Given the timestamps in the logs, I take it the unit fails to start at boot, is that right? What happens if you restart it afterwards? You might need to trigger the unit from a udev rule so that it starts after the hwnrg device is available. – Stephen Kitt Oct 15 '18 at 12:04
  • M. Kitt may also be interested in the status of dev-hwrng.device. – JdeBP Oct 15 '18 at 12:06
  • @JdeBP that’s assuming that the udev rule tags the device appropriately; but we’re addressing the parent question at this point... – Stephen Kitt Oct 15 '18 at 12:12

Your Answer

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