Can I use SysV init scripts for systemd

5,607

Solution 1

systemd has some backwards compatibility, but it is not one-to-one. For example, in SysV init scripts, you can add custom subcommands, but in systemd you can't.

In my experience, you can expect additional debugging or strange behavior if you try to keep those old init scripts working.

I think you'll save time in the long run by rewriting your init scripts as systemd unit files.

If you are using standard, third-party software, chances are that the project already ships it's own systemd unit files you can use.

Solution 2

systemd compatibility with SysV init scripts is provided by the systemd-sysv-generator, which writes systemd units on the fly calling the init script with proper arguments to implement start/stop/reload.

To do its job, systemd-sysv-generator depends heavily on the LSB headers of the SysV init script, which look like this:

### BEGIN INIT INFO
# Provides: lsb-ourdb
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start:  2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop OurDB
# Description: OurDB is a very fast and reliable database
#    engine used for illustrating init scripts
### END INIT INFO

If your SysV init script doesn't have proper LSB headers, it's likely that systemd-sysv-generator won't be able to do a good job of converting it automatically to a systemd unit...

The units generated by systemd-sysv-generator will be stored under /run/systemd/system, so you can either look for the *.service file there, or just use the systemctl cat command to list the contents of the unit. You can potentially also add overrides to units generated from SysV init scripts, by using the systemctl edit command. (That is useful, for example, if you want to add additional dependencies or ordering directives to the unit.)

But perhaps taking the plunge and converting the SysV init scripts to native systemd units is a better approach and will pay off long term, especially if the command is able to run in foreground (and not daemonize) and the SysV init scripts are daemonizing the commands themselves (in which case, systemd can do a better job at it, and will work better if it daemonizes the commands itself.)

Check out this article in Fedora Magazine for tips and tricks on how to convert SysV init scripts into systemd units, hopefully this will help get you started. Don't hesitate ask back here for more specifics if you get stumped while trying to convert the init scripts. Good luck!

Share:
5,607

Related videos on Youtube

robert
Author by

robert

Updated on September 18, 2022

Comments

  • robert
    robert almost 2 years

    In Ubuntu 14 I have a bunch of SysV init scripts (/etc/init.d/).

    After migration to Ubuntu 16 they do not really work, as I understand Ubuntu 16 generates systemd unit files on the fly. Some services can be started but some not.

    My idea is to:

    1. relocate SysV init scripts (/etc/init.d/ -> /var/lib/my-services/) and make sure that services can be started via them

    2. create proper systemd unit files (/etc/systemd/system) and use relocated SysV init scripts (/var/lib/my-services/)

    Can I reuse SysV init scripts or can they contain something specif to SysV that doesn't work for systemd?

    UPDATE #1: out of the box on Ubuntu 16 Apache2 is shipped with SysV init script (/etc/init.d/apache2). Is there a systemd example for Apache2?

    • dr_
      dr_ almost 6 years
      The best would be to write proper systemd files to run the applications at startup. Anyway, systemd is backward-compatible with SysV.
    • muru
      muru almost 6 years
      Ubuntu 17.10 and newer have an apache2.service. You can use that as a reference.
  • robert
    robert almost 6 years
    Is there a systemd example for Apache2 service? Out of the box on Ubuntu 16 there is only SysV init for Apache2.
  • filbranden
    filbranden almost 6 years
    @robert That's correct, after apt-get install apache2 on Ubuntu 16.04 it will install a SysV init script for Apache2, but it will also install a drop-in override for systemd under /lib/systemd/system/apache2.service.d/apache2-systemd.conf, and by running systemctl cat apache2 you'll see that systemd-sysv-generator is in action already, setting up a unit for it. In Ubuntu 18.04, they've done something similar, but they're shipping a generated unit for Apache2 with the package.
  • filbranden
    filbranden almost 6 years
    Ubuntu developers test that particular setup, so you should be fine with it, the way they prepared it. Just use systemd commands (systemctl start apache2, etc.) to manage it and you'll be fine!
  • Integrator
    Integrator about 4 years
    I found out the hard way that if the file in /etc/init.d is a symlink, the systemd generator "systemd-sysv-generator" that scans for legacy init.d scripts will skip it. My gerrit file in init.d was a symlink to /home/gerrit2/gerrit/bin/gerrit.sh, I fixed it with: cd /etc/init.d; sudo unlink gerrit; sudo cp /home/gerrit2/gerrit/bin/gerrit.sh gerrit