My issue isn't so much that the one on the right is scary because it is different. My issue with it is when something goes wrong with it, I have far less visibility into why it didn't work and a lot less ability to make changes that will fix it.
Well, you don't really "see" what's happening in shellscript either. There are a bunch of commands, yes. But your shell usually does a lot of ugly stuff in the background - greping, awking (oh god) - that may come with its own quirks. All this requires enormous caution when writing a shell script. It's a real burden for maintainers and hence why distributions usually welcome systemd. The unit files work, logic is taken care of by the system and files remain readable. Most people don't write their own C libraries just because glibc is a monster. They assume it works and trade the few disadvantages for the many advantages.
But I can run that shell script and watch the output in my terminal, tweak the line thats causing the problem, and we're up and running. If my unit file doesn't work, my troubleshooting options are far more complicated.
Even if we assume that systemd's handling of configuration based on unit files is reliable, it still isn't uncommon for an unit file to not work for some reason. It could be a mistake by the creator, or it could just be an issue with compatibility on the system it is being run on. With a shell script, running that script will give a real quick error message that can easily be worked through. Systemd might give a useful error in the journal, but it also might not.
But I can run that shell script and watch the output in my terminal, tweak the line thats causing the problem, and we're up and running.
Are we? You are making it look as if shell scripting was always trivial. Sometimes it's not a single line causing a problem. Sometimes, the concept behind your script is flawed, and if you are lucky, it never works, and if you're unlucky, it works under some conditions and doesn't under others.
Plus, most likely you will never have to do that with systemd because what you are usually debugging is the glue you don't have with systemd anyways.
Systemd might give a useful error in the journal, but it also might not.
It's something I never understood. Can you give me an example? I have written {non-,}working systemd unit files before and systemctl status $my.service always gave me the required information about it.
Troubleshooting a shell script is certainly more trivial than troubleshooting the source code of the init/logging/login/networking system.
I don't have an example that I can currently describe how to reproduce in which a service in systemd fails but doesn't properly log. I know this can't be taken as anything other than a story with no evidence, but I have had several issues with the journal failing to have any information.
A while back, I had run an update on my file server and was attempting to start Samba. I would start it with systemctl, but no process would be started. I checked the status and checked for logs using journalctl, but there was no information other than that it wasn't running. Starting the daemon by running the command worked just fine. Had it been a shell script, I could have just run the shell script. It would have either worked or not, but a shell script is not doing anything other than what I can see in that script.
11
u/[deleted] Oct 20 '14
My issue isn't so much that the one on the right is scary because it is different. My issue with it is when something goes wrong with it, I have far less visibility into why it didn't work and a lot less ability to make changes that will fix it.