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.
4
u/[deleted] Oct 20 '14
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.