4 ms·
sysv init scripts are more complicated than just a list of commands to run to start the service. They have start / stop / reload functions and express dependenc
by Arnavion 3y ago
sysv init scripts are more complicated than just a list of commands to run to start the service. They have start / stop / reload functions and express dependencies. The sysv generator handles all of those. Like this jank: https://github.com/systemd/systemd/blob/08423f6d30f5db045b8a25307857f111f45ff292/src/sysv-generator/sysv-generator.c#L464-L476 https://github.com/systemd/systemd/blob/08423f6d30f5db045b8a...
So it's not as simple as "Just write a .service with ExecStart=/etc/init.d/whatever start", but it's also not too complicated, especially if someone forks the sysv generator and keeps it working like I said in another comment.
- bandrami 3y agoWell, wait: sysv scripts can express dependenices but they don't have to. The admin is totally free to just set the start and stop orders in the runlevels themselves (that's how the BSD world does it). Setting up a dependency system means you're just making a worse systemd and I've never really gotten the appeal of it.
- ilyt 3y agoFun fact: Debian, thanks to those dependencies, had ability to start SysV services in parallel, before any of that fancy upstart/systemd happened. It just had batch job that solved the dependencies, ordered the init scripts numerically, and then started in batches all of those that started in same number (IIRC, there might've been a bit more fancy stuff there too). It was kind of worse systemd but systemd wasn't around back then
- bandrami 3y agoAnd I had a staticly compiled make that read /etc/rc.mk in my toy distribution in 1999; none of this is a groundbreaking idea. There were plenty of ways to do parallel startup in the oughts but admins rejected them because parallel startup is largely a bad idea. Start the services in the order I tell you to, one at a time, logging the results. Anything else will eventually bite you.
- ilyt 3y agoWell, since the 90's we had more than one core in the average machine. There is no reason parallel start would be problematic; I even got stuff working that needed network access to get creds for encrypted partition that was required for database to start and it was handled flawlessly. More than that, if for some reason that file system wasn't mounted it would be when I told systemd to start database, it would run the service retrieving the secrets, then the mount using it, then the DB. The worse story is with shutdown; by default most distros will cut ssh access before services are closed so if some of them hang you can't debug that remotely. But that's mostly bad settings rather than bad design of the daemon
- bandrami 3y agoI think you're definitely right that shutdown is the harder problem and it's one that init systems in general pay a lot less attention to, unfortunately. If the system has a problem coming up it often at least gets into a state where I can access it; if it hangs after being told to reboot, well... I once had to drive from Arlington VA to Seacaucus NJ to press a power button on a rack server in our datacenter, and I don't like that.