3 ms·

Apache waiting for NFS mounts is still not solved. Now Apache may depend on a file system, but it still cannot depend on "the LDAP is available so you can resol

by corty 5y ago

Apache waiting for NFS mounts is still not solved. Now Apache may depend on a file system, but it still cannot depend on "the LDAP is available so you can resolve the UIDs on that NFS". So we are a tiny step ahead maybe. But the problem isn't solved at all, and back in the day we just solved it by reordering Apache manually all to the back, maybe with a "check that UIDs are resolvable"-script in front. systemd can't do that (except if you allow "evil" shell-scripts in bootup again...).

zxzax 5y ago
I don't see why you couldn't do that in systemd (or any other init), it's not hard to make a small unit that simply runs a shell script.
- corty 5y ago
  But it is a mess. You'll need 2 files for that unit (itself and the shellscript) plus changes to all necessary dependencies to put it in the right place. A sysv-init script is just edited in the right place and you are done.
  - vetinari 5y ago
    > A sysv-init script is just edited in the right place and you are done. If you never intended to update the package, that owns the sysv-init script, that is. If you do, you will find out at update time, that you have to manually play with 3-way diff and hope, that the init script didn't change too much. You are never done. With systemd, you have an override, you don't change the original unit. It will update cleanly.
- Icathian 5y ago
  I think the implication is that "systemd as designed" cannot do that, and shell scripts are a hacked-in solution. I disagree with this implication because the fact that systemd left that door open is enough for me, but I get where they're coming from.
acdha 5y ago
1. We didn’t “solve” that back in the SysV days by reordering - mostly we just lived with the occasional race conditions and restarted it. 2. You could use systemd’s health check or pre-exec to handle prerequisite checks like this if you can’t use the dependency mechanism for some reason (there’s no reason why you couldn’t have a custom type=oneshot service set as a requirement for Apache). There’s nothing “evil” about scripting like this - the thing which makes me tired of SysV is the limited standard feature set (daemonization, logging, restarts, dependencies, event handling, etc.) and challenges coordinating across distributions for things like overrides. The wheels fall off shell scripting when you need to deal with that much complexity and do so in a portable manner with a bunch of shell code you don’t control - a health check is far less tedious to deal with, especially since you have a ton of functionality in systemd which avoids the need to handle the hard parts.
- corty 5y ago
  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!
  - acdha 5y ago
    > 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.

by corty 5y ago

zxzax 5y ago

I don't see why you couldn't do that in systemd (or any other init), it's not hard to make a small unit that simply runs a shell script.

corty 5y ago
But it is a mess. You'll need 2 files for that unit (itself and the shellscript) plus changes to all necessary dependencies to put it in the right place. A sysv-init script is just edited in the right place and you are done.
- vetinari 5y ago
  > A sysv-init script is just edited in the right place and you are done. If you never intended to update the package, that owns the sysv-init script, that is. If you do, you will find out at update time, that you have to manually play with 3-way diff and hope, that the init script didn't change too much. You are never done. With systemd, you have an override, you don't change the original unit. It will update cleanly.
Icathian 5y ago
I think the implication is that "systemd as designed" cannot do that, and shell scripts are a hacked-in solution. I disagree with this implication because the fact that systemd left that door open is enough for me, but I get where they're coming from.

acdha 5y ago

1. We didn’t “solve” that back in the SysV days by reordering - mostly we just lived with the occasional race conditions and restarted it. 2. You could use systemd’s health check or pre-exec to handle prerequisite checks like this if you can’t use the dependency mechanism for some reason (there’s no reason why you couldn’t have a custom type=oneshot service set as a requirement for Apache). There’s nothing “evil” about scripting like this - the thing which makes me tired of SysV is the limited standard feature set (daemonization, logging, restarts, dependencies, event handling, etc.) and challenges coordinating across distributions for things like overrides. The wheels fall off shell scripting when you need to deal with that much complexity and do so in a portable manner with a bunch of shell code you don’t control - a health check is far less tedious to deal with, especially since you have a ton of functionality in systemd which avoids the need to handle the hard parts.

corty 5y ago
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!
- acdha 5y ago
  > 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.