4 ms·

What's so hard about init scripts ? Since few years peoples are literally demonizing them, ROFL. "Maintaining" that few lines of shell code that start/stop/che

by Woodi 3y ago

What's so hard about init scripts ? Since few years peoples are literally demonizing them, ROFL. "Maintaining" that few lines of shell code that start/stop/check some program is incomparable to mainatining source code so can't be serious reason for demanding of removing them from existence. And from that little scripts you literally know everything about starting/stopping managed program. Compare this to systemd undocumented, buggy and not working as expected "configs" :>> Of course it's possible to make mess with scripts. But you can't manage to mess script so badly it becomes so monstrous as systemd :) And you realy can't include so many CVEs as systemd introduced - that brain-dead not-a-init moved init process to ranks of sendmail and bind... Well done ? Works for me ? Minorities only problem ?

jcranmer 3y ago
> What's so hard about init scripts ? Unixes have this nasty property that forking new processes tends to inherit all the attributes of the parent process, and shell scripts are really good at making sure all the attributes are passed by default unless you bitch and complain and try really hard to not do so. Things like signal masks or environment variables, etc. If you wanted a system where a service you're setting up runs differently because it was invoked by init on startup versus invoked by someone over an ssh session versus invoked by a different user over an ssh session versus someone running in a terminal in an X session, well, init scripts are a great way to do that. If you think such a system is horrific for debugging purposes and should be avoided at all costs, you're going to start by avoiding shell like the plague. (Also, shell is just an atrocious language for most tasks.)
- Woodi 3y ago
  But you can do all that above. You can split onto separate parts when needed. You can start small and grow your scripts. You can comfortably replace them. You can do everything you have rights to. Good luck debugging, fixing and splitting or just modifing or twiking systemd implementation :) So what deserve bigger "avoiding like the plague" ? Possibility or not possibility ?
  - jcranmer 3y ago
    You actually can't. The first problem is you can only write a shell script to be defensive about the things you know about. Do you personally know which environment variables need to be reset to their default value for your service to work correctly? The next problem is that there's actually some inheritable process state you can't manage with shell builtins. Combine that with the above, and it really makes sense for you to have a utility that knows how to spawn a service in a pristine, controlled environment. While we're working on that pristine, controlled environment tool, we should also reflect on the fact that process management in Linux is a real complicated bitch. Simple is invariably neither robust nor correct. If we've already got a utility to help us write a services, we might as well extend it to be able to help with detecting stuff like "is this service still actually running or did it somehow fart itself and die?" Of course, once you have this tool, you look back at your new init script and realize that all of the work you have to do is now in this tool, so why should you have to bother with boilerplate in a defective-by-default language [1]? > Good luck debugging, fixing and splitting or just modifing or twiking systemd implementation :) I've had more issues debugging init scripts than I have with systemd stuff. I actually find debugging easier with systemd... it actually tells me when things go haywire! [1] Try having directories with spaces in their name with shell and see how often you get tripped up by it!
    - Ckirby 3y ago
      [flagged]
      - Spivak 3y ago
        That's fine and all but systemd is a real-life example of if you actually offer someone a "The Right Thing" solution that takes all of their hard problems, swallows the complexity of them and presents a simple interface with the right abstractions people will choose it overwhelmingly over alternatives. I couldn't care less about design-by-ideology when I'm paid to design correct systems.
        Ckirby 3y ago

by Woodi 3y ago

jcranmer 3y ago

> What's so hard about init scripts ? Unixes have this nasty property that forking new processes tends to inherit all the attributes of the parent process, and shell scripts are really good at making sure all the attributes are passed by default unless you bitch and complain and try really hard to not do so. Things like signal masks or environment variables, etc. If you wanted a system where a service you're setting up runs differently because it was invoked by init on startup versus invoked by someone over an ssh session versus invoked by a different user over an ssh session versus someone running in a terminal in an X session, well, init scripts are a great way to do that. If you think such a system is horrific for debugging purposes and should be avoided at all costs, you're going to start by avoiding shell like the plague. (Also, shell is just an atrocious language for most tasks.)

Woodi 3y ago
But you can do all that above. You can split onto separate parts when needed. You can start small and grow your scripts. You can comfortably replace them. You can do everything you have rights to. Good luck debugging, fixing and splitting or just modifing or twiking systemd implementation :) So what deserve bigger "avoiding like the plague" ? Possibility or not possibility ?
- jcranmer 3y ago
  You actually can't. The first problem is you can only write a shell script to be defensive about the things you know about. Do you personally know which environment variables need to be reset to their default value for your service to work correctly? The next problem is that there's actually some inheritable process state you can't manage with shell builtins. Combine that with the above, and it really makes sense for you to have a utility that knows how to spawn a service in a pristine, controlled environment. While we're working on that pristine, controlled environment tool, we should also reflect on the fact that process management in Linux is a real complicated bitch. Simple is invariably neither robust nor correct. If we've already got a utility to help us write a services, we might as well extend it to be able to help with detecting stuff like "is this service still actually running or did it somehow fart itself and die?" Of course, once you have this tool, you look back at your new init script and realize that all of the work you have to do is now in this tool, so why should you have to bother with boilerplate in a defective-by-default language [1]? > Good luck debugging, fixing and splitting or just modifing or twiking systemd implementation :) I've had more issues debugging init scripts than I have with systemd stuff. I actually find debugging easier with systemd... it actually tells me when things go haywire! [1] Try having directories with spaces in their name with shell and see how often you get tripped up by it!
  - Ckirby 3y ago
    [flagged]
    - Spivak 3y ago
      That's fine and all but systemd is a real-life example of if you actually offer someone a "The Right Thing" solution that takes all of their hard problems, swallows the complexity of them and presents a simple interface with the right abstractions people will choose it overwhelmingly over alternatives. I couldn't care less about design-by-ideology when I'm paid to design correct systems.
      - Ckirby 3y ago