4 ms·

The dependency issue is referring to start up process order. One of the headaches of the old SysV init system was you had specify what order daemons started an

The dependency issue is referring to start up process order. One of the headaches of the old SysV init system was you had specify what order daemons started and when they started in the boot process. The login daemon started while the OS was still in single user mode. Then you'd start the logger. Now you bring up multiple users, and the network stack. Maybe NTP, DNS resolve,run as separately users? They definitely need system log. Systemd you just state what your daemon already needs running and it'll on boot resolve the daemon start order. If you've only ever lived in a package managed eco system and never rolled several of your own daemons you likely never encountered this issue.

davidu 10y ago
Having been an operator for nearly 20 years, is this a problem actual admins face? I've never experienced this. I always used runit or daemontools, but even with sysvinit I never had these issues.
SwellJoe 10y ago
There's always folks suggesting that systemd is too complicated, and that simpler solutions are better. But, I have to assume they've never dealt with the complexity that SysV initscripts leave up to the developer and packager. I don't mind giving that complexity to the systemd developers. The old Apache initscript (for just one egregious example) was a huge ball of shell script wizardry that checked all sort of things on startup, handled restarting/reloading based on the command and some other factors (graceful restart is only possible under some circumstances, etc.), kept up with PIDs, and cleanup. The systemd unit file for Apache is 17 lines long, minus comments; it is declarative, looks like every other unit file, and handles all the same stuff, and better than the old initscript. The complexity is gonna be there. These systems are complex and do complex things. it's just a question of what layer the complexity shows up in. systemd pushes it all down into systemd where most users and administrators and packagers and developers never have to see (much of) it. And, as you note, run levels and process order are another layer of complexity pushed onto the administrators that could be pushed into the init, but never were under SysV initd. Again, it's handled by humans who have to have a lot of knowledge about the system, the service in question and its dependencies, in order to write the initscript and put it in the right place in the boot order...and there's room for mistakes. I've been packaging system level services long enough to have had many experiences getting it wrong in subtle ways.
johncolanduoni 10y ago
And it's worth noting that using a package manager just bunts the issue to your distro maintainers. Who have a lot more than "several" daemons that all need to play nice, across virtually infinite combinations and configurations.
creeble 10y ago
I'm a little lost on systemd myself. Seems like an attempt to solve the problem of startup complexity by...adding complexity. Maybe I'm just getting old and grumpy. But I have a Linux 2.0 kernel machine that has been running a LAMP stack for over 10 years that boots in one tenth the time my Ubu 16.04 machines - that run the same LAMP stack - do. Ah for the old and simple days...
- petre 10y ago
  > Maybe I'm just getting old and grumpy Do try out FreeBSD then -- an OS for the old and grumpy. Systemd free. Uses an init system written in sh(1) that just works.
petre 10y ago
Yeah, but the ball of shell script wizardry managed to somehow start apache nicely every single time. Systemd doesn't. So I have to resort to running critical services under runit.
- oblio 10y ago
  Do you have an example?
  - petre 10y ago
    Asterisk, varnishd. Apache I don't restart from cronjobs running backups anymore just to make sure systemd doesn't fail to restart it, upsetting our clients. Apache fails to start cleanly if it cannot resolve ServerName.
  - petre 10y ago
    Asterisk, varnishd. Apache I don't restart from cronjobs running backups anymore just to make sure systemd doesn't fail to restart it, upsetting our clients. Apache fails to start cleanly if it cannot resolve ServerName.
dozzie 10y ago
You see, the problem is that systemd promised not needing to specify those dependencies in the first place, but then we have exactly the same stupid situation that we had with upstart, Gentoo's initsystem, or SysV init (sic!): sysadmin needs to manually tweak things to get the boot order right, only that none of the init systems (except with SysV init) can't tell you the boot order without rebooting your machine. And yes, sysadmin will still need to tweak things, because a distribution maintainers cannot predict all the possible dependencies between services. One could never forsee that Mailman would fail to run when OpenLDAP was stopped, and this is what I had in one place.

davidu 10y ago

Having been an operator for nearly 20 years, is this a problem actual admins face? I've never experienced this. I always used runit or daemontools, but even with sysvinit I never had these issues.

SwellJoe 10y ago

There's always folks suggesting that systemd is too complicated, and that simpler solutions are better. But, I have to assume they've never dealt with the complexity that SysV initscripts leave up to the developer and packager. I don't mind giving that complexity to the systemd developers. The old Apache initscript (for just one egregious example) was a huge ball of shell script wizardry that checked all sort of things on startup, handled restarting/reloading based on the command and some other factors (graceful restart is only possible under some circumstances, etc.), kept up with PIDs, and cleanup. The systemd unit file for Apache is 17 lines long, minus comments; it is declarative, looks like every other unit file, and handles all the same stuff, and better than the old initscript. The complexity is gonna be there. These systems are complex and do complex things. it's just a question of what layer the complexity shows up in. systemd pushes it all down into systemd where most users and administrators and packagers and developers never have to see (much of) it. And, as you note, run levels and process order are another layer of complexity pushed onto the administrators that could be pushed into the init, but never were under SysV initd. Again, it's handled by humans who have to have a lot of knowledge about the system, the service in question and its dependencies, in order to write the initscript and put it in the right place in the boot order...and there's room for mistakes. I've been packaging system level services long enough to have had many experiences getting it wrong in subtle ways.

johncolanduoni 10y ago

And it's worth noting that using a package manager just bunts the issue to your distro maintainers. Who have a lot more than "several" daemons that all need to play nice, across virtually infinite combinations and configurations.

creeble 10y ago

I'm a little lost on systemd myself. Seems like an attempt to solve the problem of startup complexity by...adding complexity. Maybe I'm just getting old and grumpy. But I have a Linux 2.0 kernel machine that has been running a LAMP stack for over 10 years that boots in one tenth the time my Ubu 16.04 machines - that run the same LAMP stack - do. Ah for the old and simple days...

petre 10y ago
> Maybe I'm just getting old and grumpy Do try out FreeBSD then -- an OS for the old and grumpy. Systemd free. Uses an init system written in sh(1) that just works.

petre 10y ago

Yeah, but the ball of shell script wizardry managed to somehow start apache nicely every single time. Systemd doesn't. So I have to resort to running critical services under runit.

oblio 10y ago
Do you have an example?
- petre 10y ago
  Asterisk, varnishd. Apache I don't restart from cronjobs running backups anymore just to make sure systemd doesn't fail to restart it, upsetting our clients. Apache fails to start cleanly if it cannot resolve ServerName.
- petre 10y ago
  Asterisk, varnishd. Apache I don't restart from cronjobs running backups anymore just to make sure systemd doesn't fail to restart it, upsetting our clients. Apache fails to start cleanly if it cannot resolve ServerName.

dozzie 10y ago

You see, the problem is that systemd promised not needing to specify those dependencies in the first place, but then we have exactly the same stupid situation that we had with upstart, Gentoo's initsystem, or SysV init (sic!): sysadmin needs to manually tweak things to get the boot order right, only that none of the init systems (except with SysV init) can't tell you the boot order without rebooting your machine. And yes, sysadmin will still need to tweak things, because a distribution maintainers cannot predict all the possible dependencies between services. One could never forsee that Mailman would fail to run when OpenLDAP was stopped, and this is what I had in one place.