How to remove a systemd wrapper script for sysV service and use a unit file instead?

Question

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)

And:

# 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'.

And:

# 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
# ...

[Unit]
Description=Entropy daemon for /dev/random using a hardware RNG
After=syslog.target
Requires=syslog.target

[Service]
Type=simple
ExecStart=/usr/sbin/rngd -r /dev/hwrng -f

[Install]
WantedBy=basic.target

Answer 1

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.