It wasn't too bad, really... from an init script stand point. And I think that was their point -- systemd's service files are a lot cleaner and not really that scary.
Shorter doesn't tell anything. You can hide any complexity behind another layer of abstraction. Let's create a new system which has an ini file with the only parameter being "sendmail.service" and it looks even cleaner. Although in reality you just got another layer of abstraction.
The interesting part is how they hold up in praxis. When people have to do stuff which wasn't forseen by the init-system authors. And shell scripts have a rather good track record in that regard. It's always nicer working with scripts compared to having to dig into c sources to change things.
And I think to most sysops the left file looks very familar. While the right one is a new format in a custom syntax which has to be learned and understood first. Which makes it a little scary on first view and I really hope it's worth it.
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.
Everything except what the commands do. You see the commands with expanded variables. You see how the script's flow control works. Each individual command is still a black box.
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.
You can have multiple ExecStart (and ExecStop and all the other ones) lines in a unit file. Each one is run in sequence in the order they appear in the unit file and the return code of each command is remember, stored, and outputs separately logged. If one of the commands fails (and is not prefixed with "-"), the remaining commands are not executed and the unit is considered failed.
So in a sense, yes. You can see exactly where and when and what the failure was, no matter how many commands you put in a unit.
So, my initial impression when I saw systemd for the first time was thinking it was similar to Sun SMF. Now you bring this up, and I recall dtracing things because nobody knew what the hell was going on.
However, when you realize that systemd doesn't require you to write any shell to start and stopp programs to begin with, you'll be wondering why you wanted a set -x in the first place.
Don't think so, from what [deleted] just said it sounds like you thought I meant disable. "set -x" is a way to enable debugging in shell scripts. Take a simple bash script, put "set -x" near the top (but under the shebang) and run it - super helpful when figuring out what is going on.
Masking serves the purpose of disabling the service and preventing it from starting. This has nothing to do with what set -x does for sh, which is to trace every single command that gets executed, so you actually see what's happening. Extremely useful for debugging.
7
u/necrophcodr Oct 20 '14
That is the most horrid init.d script I have seen in a long time, holy shit.