Troubleshooters.Com®, Linux Library, and DIY Linux Present:
Running Daemontools-Encore On Top Of Systemd
Copyright © 2015 by Steve Litt
See the Troubleshooters.Com Bookstore.
Contents:
Why would you run daemontools-encore on a machine already initted by systemd? I can think of several reasons:
There are probably fifty other reasons to run daemontools-encore on top of systemd. Whatever your reason, it's trivial to do, because daemontools-encore installation is trivial, and telling systemd to run daemontools-encore at from-boot is trivial.
I tech edited this document using Lubuntu 15.04 on a VirtualBox VM. And please keep in mind, I'm no systemd expert. So although this setup has been proven to work on Lubuntu 15.04, there may be better ways of doing. I imagine that the After property in my daemontools.service unit file is especially sketchy. But it worked.
No need to rewrite this. I've already covered it. Once you have daemontools-encore to the point where manually running svscanboot makes daemontools run the test "write to /tmp/junk.log, you're ready to tell systemd about it.
I'm writing this on 7/4/2015. Systemd is changing very fast, so this could be obsolete soon. But I'm pretty sure the basics will remain similar.
The way I did it was to put a brand new unit file, called daemontools.service, into directory /etc/systemd/system. This is the directory that you put your own units into, and units in that directory override the distro-packaged unit files in /lib/systemd/system. There's also a way to do partial edits, on unit files defined in /lib/systemd/system, in /etc/systemd/unitname.d/, but that's well beyond the scope of this document. Anyway, getting back on track, my /etc/systemd/system/daemontools.service follows:
[Unit] Description=Daemontools-encore After=systemd-remount-fs.service [Service] Type=fork ExecStart=/usr/local/bin/svscanboot [Install] WantedBy=multi-user.target
Like I said, I'm no systemd expert. I guessed that daemontools-encore would be ready to rock and roll by the time the hard disk was mounted read-write, so I specified After=systemd-remount-fs.service. There might be many reasons why you want to delay startup of daemontools-encore, in which case you'd use a later starting unit as the value of the After= key.
Note also that I chose WantedBy=multi-user.target. I probably should have used a more generic target, such as basic.target, but most other services seemed to use WantedBy=multi-user.target, so I just did the same thing and it worked.
I then issued the following command:
systemctl start daemontools.service
After the preceding command, a check indicated that /tmp/junk.log was being written to every 10 seconds, so I knew systemd had run daemontools-encore. The last step is to make sure daemontools-encore runs at boot, so I performed the following command to make system run daemontools-encore at boot:
systemctl enable daemontools.service
Then I rebooted and tested, and daemontools-encore had come up running, supervising the test script that writes to /tmp/junk.log.
You might have come from an environment where you ran daemontools or one of the supervisors it inspired on a sysvinit initted system. This is done all the time because the daemontools inspired supervisors are so easy to use, so reliable, and just a breath of fresh air. If, before leaving the sysvinit initted environment, you backed up all the service directories, there's a good chance you could simply lay them down in the new environment, symlink them to /service or whatever head you used as the target for your symlinks, and daemontools would do the exact same job for you in the new environment.
Don't forget, however, that you don't want two copies of anything running. So if daemontools-encore is running your openntpd daemon, make sure to disable systemd from running openntpd, using the following command:
systemctl disable openntpd.service
Also, if any systemd units have After=openntpd.service or Before=openntpd.service, you're going to need to deal with that. You can determine such dependencies with the following two commands:
systemctl --after \ list-dependencies openntpd.service
systemctl --before \ list-dependencies openntpd.service
Definition:
--after in the previous command means "show me everything that runs before openntpd.service. --before means "show me everything that runs after openntpd.service runs.
In general, unless you're going to completely replace systemd, it's probably easiest and best to reserve daemontools-encore for the later running daemons.
[ Training | Troubleshooters.Com | Email Steve Litt ]