Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In that sense, systemd doesn't solve anything for the same reason sysv-init doesn't. All those preconditions in systemd will still either time out or never finish.

The point is, back then I just moved the apache startup script to back, added a wait-and-check loop in that script and had everything in one place and done.

With systemd I have to rely on a dependency on some notoriously broken network-up-target, add a separate script with my wait-and-check loop to the apache unit, add a dependency on an NFS mount or maybe autofs and then hope I didnt forget something. Then notice that autofs units are usually broken because they exit too early (before they mount anything) and add a "sleep 10" unit in between. Now I'm at more complexity, a shellscript, multiple files and still not ahead in functionality and reliability. Progress!



> In that sense, systemd doesn't solve anything for the same reason sysv-init doesn't. All those preconditions in systemd will still either time out or never finish.

No, they will run until the configured timeout and be restarted following your configured restart policy. Once that's happened, all dependent services will automatically be started.

> The point is, back then I just moved the apache startup script to back, added a wait-and-check loop in that script and had everything in one place and done.

Nothing prevents you from putting a wait loop in the Apache systemd unit, either — in fact, it'll be a lot easier because you can use an override rather than needing to modify a packaged file which will be clobbered by updates.

> Now I'm at more complexity, a shellscript, multiple files and still not ahead in functionality and reliability. Progress!

It's interesting because you keep describing what sounds like the SysV experience, which I haven't seen since switching to Upstart/systemd over a decade ago.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: