5 ms·

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

by 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
      How about you tell me who or what you work for and which systems you design supposedly so I can avoid them like the plague
    - deleted 3y ago
      [deleted]
- Woodi 3y ago
  > You actually can't. Maybe, maybe it can be done in some way, whatever 'it' is. > you can only write a shell script to be defensive about the things you know about And that is a problem strictly unique to shell scripting ? :) With systemd you know ? Or pick one arbitrary thing and just deny other possibilities ? Of course you deny (you as in the systemd implementer / beliver / user), as has been seen many many times. Suddenly usecase has been changed ! And maybe now you can do that with scripts even better then with systemd ? :) > inheritable process state you can't manage with shell builtins Is "builtins" a key world here ? Becouse shell scripts are quite literaly about using not build in pieces :) > spawn a service in a pristine, controlled environment. See ? Use case changed. It is no longer "user" or "other user", nor ssh or console or interactive, nor txt or X or W... Use case refactoring :) You can rething how to script it to not loss functionality. Oh, wait... It's systemd ! Functionality loss is a motto there :) But scripts need to handle orginal usecase, for PR reasons :) > process management in Linux is a real complicated bitch nixes are complex. Lastly Linux have even more namespaces, contexts, etc. And you know what ? Systemd do not helped to make it simpler. Just wrapped some of them, badly (context v1 for years!) into internals and hijacked development of sane and modern system utilities. > Simple is invariably neither robust nor correct. Luckily we talking shell scripting here :) Becouse any system utility can be used. And they can be combined even ! Shocking ! ;) > 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 Valid use case. Had been done ages ago. In modular fassion. With possibility of replacing monitoring part into other implementation. Can be even started from init.d script :) > "is this service still actually running or did it somehow fart itself and die?" And this is working on systemd ? :) Working better then in other service managers ? How systemd detect such conditions that other managers can't do that ? :) And why systemd display that not-funny messages of waiting for service to do something ? And permamently halting system halt ? And making my screen / tmux not working ? :) > > 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 have more problems with systemd configs then I had with using init.d scripts - they are just like command line(s), sequencial execution, easy to debug by just looking on them and checking system / app state. And usually it's not script problem but something with app. How systemd can improve on that ? By blackboxing managing service ? :) > I actually find debugging easier with systemd... Maybe. But just wait systemd will make debugging effort poinless by changing systemd behavior :) But you missed something: with pure scripts or simpler managers you know everything* about system you are running. With systemd you don't - you introduce additional complication. And constant CVEs stream. How that is easier to debug ? > defective-by-default language / directories with spaces in their name On contrary, *nix shell scripts are perfect for work they are doing - batching commands you type into pack for re-execution. Tested commands that work as expected. And "spaces" problem is solved. Do tar or cpio in script have problem with directories with spaces ? Do ls, find and others have options for better separating things ? Do shell allow '""' usage ? Thing about scripts is that you are supouse to stop using them when usecase is more complicated. This is counted as +1 for scripts and +1 for init.d usage (and -1 for systemd monitic monster). Scripts work is just to be agregators for fast and clear development eg. for start / stop / check helpers that you copy / paste almoust literally. Just like configs in systemd :) Edit: Btw. Hey, I don't specially like init.d - it works, is simple, extendable, replacable in few hours, etc, etc. Just systemd is such monstrous insanity...

by Woodi 3y ago

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
    How about you tell me who or what you work for and which systems you design supposedly so I can avoid them like the plague
  - deleted 3y ago
    [deleted]
Woodi 3y ago
> You actually can't. Maybe, maybe it can be done in some way, whatever 'it' is. > you can only write a shell script to be defensive about the things you know about And that is a problem strictly unique to shell scripting ? :) With systemd you know ? Or pick one arbitrary thing and just deny other possibilities ? Of course you deny (you as in the systemd implementer / beliver / user), as has been seen many many times. Suddenly usecase has been changed ! And maybe now you can do that with scripts even better then with systemd ? :) > inheritable process state you can't manage with shell builtins Is "builtins" a key world here ? Becouse shell scripts are quite literaly about using not build in pieces :) > spawn a service in a pristine, controlled environment. See ? Use case changed. It is no longer "user" or "other user", nor ssh or console or interactive, nor txt or X or W... Use case refactoring :) You can rething how to script it to not loss functionality. Oh, wait... It's systemd ! Functionality loss is a motto there :) But scripts need to handle orginal usecase, for PR reasons :) > process management in Linux is a real complicated bitch nixes are complex. Lastly Linux have even more namespaces, contexts, etc. And you know what ? Systemd do not helped to make it simpler. Just wrapped some of them, badly (context v1 for years!) into internals and hijacked development of sane and modern system utilities. > Simple is invariably neither robust nor correct. Luckily we talking shell scripting here :) Becouse any system utility can be used. And they can be combined even ! Shocking ! ;) > 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 Valid use case. Had been done ages ago. In modular fassion. With possibility of replacing monitoring part into other implementation. Can be even started from init.d script :) > "is this service still actually running or did it somehow fart itself and die?" And this is working on systemd ? :) Working better then in other service managers ? How systemd detect such conditions that other managers can't do that ? :) And why systemd display that not-funny messages of waiting for service to do something ? And permamently halting system halt ? And making my screen / tmux not working ? :) > > 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 have more problems with systemd configs then I had with using init.d scripts - they are just like command line(s), sequencial execution, easy to debug by just looking on them and checking system / app state. And usually it's not script problem but something with app. How systemd can improve on that ? By blackboxing managing service ? :) > I actually find debugging easier with systemd... Maybe. But just wait systemd will make debugging effort poinless by changing systemd behavior :) But you missed something: with pure scripts or simpler managers you know everything* about system you are running. With systemd you don't - you introduce additional complication. And constant CVEs stream. How that is easier to debug ? > defective-by-default language / directories with spaces in their name On contrary, *nix shell scripts are perfect for work they are doing - batching commands you type into pack for re-execution. Tested commands that work as expected. And "spaces" problem is solved. Do tar or cpio in script have problem with directories with spaces ? Do ls, find and others have options for better separating things ? Do shell allow '""' usage ? Thing about scripts is that you are supouse to stop using them when usecase is more complicated. This is counted as +1 for scripts and +1 for init.d usage (and -1 for systemd monitic monster). Scripts work is just to be agregators for fast and clear development eg. for start / stop / check helpers that you copy / paste almoust literally. Just like configs in systemd :) Edit: Btw. Hey, I don't specially like init.d - it works, is simple, extendable, replacable in few hours, etc, etc. Just systemd is such monstrous insanity...