4 ms·

Thanks, but I don't follow this. Saving a few keystrokes here and there, and process monitoring (which can be provided for by plenty of other packages ) is suff

Thanks, but I don't follow this. Saving a few keystrokes here and there, and process monitoring (which can be provided for by plenty of other packages ) is sufficient cause to reinvent init? Even if djb's /service claims makes sense, it still doesn't support the significantly expanded scope of, say, systemd. I mean, hijacking system logging? What could possibly justify doing that in an init system?

otabdeveloper 11y ago
> I mean, hijacking system logging? What could possibly justify doing that in an init system? DBJ's /service also hijacks logging. In fact, every decent init system hijacks logging -- you want your init to daemonize processes, and when you daemonize a processes you want its stdout to get logged properly.
jononor 11y ago
systemd is not really an init system project. Its a project to make GNU/Linux systems work better. Logging is one of the things I think they have tackled, along with service startup ("init"). I'd argue that logging is better and more useful with systemd as compared to with typical sysvinit (say in Debian/Ubuntu).
geocar 11y ago
Fifteen years ago there weren't plenty of other packages that offered process monitoring: There was init (inittab), /etc/ttys, and roll your own (init.d aka rc.d). People didn't use inittab or /etc/ttys because telling programmers to edit these files was error prone and if they got it wrong, the system wouldn't boot up correctly. init.d didn't have that problem, but programmers so frequently and regularly and consistently got "init.d" wrong in some other way (supervision, logging, etc) that some time in the last fifteen years most unix sysadmins stopped expecting programmers to daemonize and write pid files and simply started monitoring their services for them with tools like daemontools.

4 ms·

Thanks, but I don't follow this. Saving a few keystrokes here and there, and process monitoring (which can be provided for by plenty of other packages ) is suff

by vox_mollis 11y ago

otabdeveloper 11y ago
> I mean, hijacking system logging? What could possibly justify doing that in an init system? DBJ's /service also hijacks logging. In fact, every decent init system hijacks logging -- you want your init to daemonize processes, and when you daemonize a processes you want its stdout to get logged properly.
jononor 11y ago
systemd is not really an init system project. Its a project to make GNU/Linux systems work better. Logging is one of the things I think they have tackled, along with service startup ("init"). I'd argue that logging is better and more useful with systemd as compared to with typical sysvinit (say in Debian/Ubuntu).
geocar 11y ago
Fifteen years ago there weren't plenty of other packages that offered process monitoring: There was init (inittab), /etc/ttys, and roll your own (init.d aka rc.d). People didn't use inittab or /etc/ttys because telling programmers to edit these files was error prone and if they got it wrong, the system wouldn't boot up correctly. init.d didn't have that problem, but programmers so frequently and regularly and consistently got "init.d" wrong in some other way (supervision, logging, etc) that some time in the last fifteen years most unix sysadmins stopped expecting programmers to daemonize and write pid files and simply started monitoring their services for them with tools like daemontools.