Greg Wooledge: > > Suppose you want to start DJB's daemontools from a locally created systemd > unit/service. Here's a file that will do that: >
... albeit poorly. If one wants to run daemontools under systemd, svscanboot is not the way; svscanboot is a thing of the past http://jdebp.eu./FGA/inittab-is-history.html#svscanboot , and was a source of problems long before systemd was invented. Greg Wooledge: > > (The Linux kernel introduced an entirely new thing called a "cgroup" to > make this possible. That's how ridiculous self-backgrounding is.) > Control groups are not jobs http://jdebp.eu./FGA/linux-control-groups-are-not-jobs.html ; they were introduced to do resource limiting, and the systemd developers have actually complained quite a lot over the years that control groups did not turn out to be what they thought they were. Greg Wooledge: > > $ systemctl status daemontools.service > > * daemontools.service – daemontools supervisor > Loaded: loaded (/etc/systemd/system/daemontools.service; enabled) > Active: active (running) since Wed 2017-01-11 03:28:47 EST; 2 months 21 > days ago > Main PID: 529 (svscanboot) > CGroup: /system.slice/daemontools.service > |- 529 /bin/sh /command/svscanboot /dev/ttyS0 > |- 531 svscan /service > ... and there is svscanboot being a problem again. Notice how the main PID is wrong, and the log output from svscan (when there is some) does not go into the log that systemctl shows below this. Greg Wooledge: > > if you want to change the behavior of the Debian default getty@ service to > make it stop clearing the screen all the damned time, > The world wants you to clean your screen http://unix.stackexchange.com/a/233855/5132 , and this is merely one of the ways that it makes you do so.
