On Tue, Dec 25, 2012 at 7:56 AM, Joshua Murphy <poiso...@gmail.com> wrote: > On Tue, Dec 25, 2012 at 3:01 AM, Canek Peláez Valdés <can...@gmail.com> wrote: >> [ snip ] >> * Really simple service unit files: The service unit files are really >> small, really simple, really easy to understand/modify. Compare the 9 >> lines of sshd.service: >> >> $ cat /etc/systemd/system/sshd.service >> [Unit] >> Description=SSH Secure Shell Service >> After=syslog.target >> >> [Service] >> ExecStart=/usr/sbin/sshd -D >> >> [Install] >> WantedBy=multi-user.target >> >> with the 84 of /etc/init.d/sshd (80 without comments). >> > [snip] >> >> Hope it helps. >> >> Regards. >> -- >> Canek Peláez Valdés >> Posgrado en Ciencia e Ingeniería de la Computación >> Universidad Nacional Autónoma de México >> > > I've not yet made the leap, as the benefit of faster boot really > doesn't affect me between systems that're always on and laptops that > typically spend 75% of their time asleep, rather than ever getting > turned off, so I'm in no position to speak for or against the whole of > systemd's changes... but one issue I've had with the claimed benefits > is the reduction in size compared to startup scripts like > /etc/init.d/sshd ... based on that service declaration above, it's a > horribly unfair comparison. /etc/init.d/sshd is doing a lot more than > simply starting/stopping the service and dropping all of that > functionality, then claiming "these few lines serve the same purpose" > isn't an equal comparison. It would still be a (notable, at that) drop > in size if the shell script was redone to provide exactly the same set > of features, then compared, but that size difference wouldn't have the > same shock value as the comparison against 80+ lines. The argument > that those functions should be handled by the service rather than the > service handler is for another day, 'course.
No, I think that's the interesting argument. Like you say "/etc/init.d/sshd is doing a lot more than simply starting/stopping the service"; why it should do that? That's the work of the package manager and/or the administrator. An init system should only start/stop/monitor the services; it should not be checking if the keys are generated or not, or if the config file is there or not. That should happen at install time, and if for some reason they got borked between the last reboot and this one, the system is probably fucked up anyway, and putting checks in the *init script* will not help at all. But *even* if you really want to have those checks, you can do it in systemd in a cleaner way: put the checks in an executable script, and call the script with ExecStartPre: [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStartPre=/usr/local/bin/checksshd ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target There; the unit file is now 10 lines, it *still* doesn't use a Turing-complete language, you got your checks (which I believe they don't belong there, but whatever), and it will timeout if the checksshd goes into an infinite loop (30 seconds is the default timeout, I believe). That's how yo properly do more than start/stop/monitor services; the init system doesn't need to know about it, you clearly move the init system responsibility (start/stop/monitor services) from the service requirements (checking that the config files are there, or that you need to generate keys, which I repeat, I think they belong at install time), and it keeps the unit files nice and simple. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
