I've been almost convinced by systemd (and have switched to using it), but God the syntax of those service files is so ugly ...
back
8 comments
Never thought I'd see hackers saying INI format looked ugly of all things. It's basic, sure, but that's a good thing for something meant to be easily editable by hand from any editor. Otherwise, it's just key value pairs in named sections, how ugly can it be about that?
key-value pairs where the = cannot be surrounded by spaces, so I have to write
[Service]
Type=oneshot
WorkingDirectory={{ home }}/current/
Environment=RAILS_ENV=production
ExecStart=/bin/sh -lc "bin/db-backup --verbose"
Whitespace immediately before or after the equals sign is completely ignored by the parser. Its the standard INI format.
Standard INI format™:
https://specifications.freedesktop.org/desktop-entry/latest/...
What? You absolutely can have spaces; most of mine look more like
[Service]
Type = oneshot
WorkingDirectory = %h/current/
Environment = RAILS_ENV=production
ExecStart = /bin/sh -lc "bin/db-backup --verbose"Friend, you have changed my life
Is this one of those cases where at one point you had an error in the file and you figured it was down to spaces? You fixed that issue, it still didn't work but from that point you never thought to question the assumption.
I find myself doing this sort of thing all the time..
Somewhere in my head I had that spaces caused a syntax error, and the UI for systemd is not obvious when you first start using it ... so if it's working then leave well alone. I'll be making all of my .service files (not so many) human-readable in the near future!
That was (cough still is) ddclient for me.
My epiphany a month ago was that I can use
Environment = MULTIPLE=environment VARIABLES="in single line"Just remember: never use Environment= for secrets, since they are visible to all users on the system.
(Use EnvironmentFile= instead)
TOML would look a lot more quiet, but I'm not sure if TOML would be a good fit
unit files barely have any nesting, so the INI-like format is already 90% of the way towards TOML, no?
I suppose some things that can be multiply specified would be arrays, and maybe there'd be a stronger argument for combining say timer & service in the same file (or that it could be optional) given some structure.
Personally though I'm not really a fan of TOML when the data is highly structured - prefer YAML even a lot of the time for some visual indication. (If I were writing a parser, I have zero doubt I'd rather parse TOML!)
There's definitely some weirdness to certain parts of systemd service files, but was a huge improvement over Upstart and the old SysV-style init scripts.
Over all I think Systemd get way to much criticism. You don't have to use all the parts, but if you care to go through the documentation you'll find interesting features such as journald log-shipping and systemd-machined which can manage containers and VMs.
I love how easy it is to create a completely isolated daemons with systemd. In a single .service file one can define a daemon that has a very limited view to the filesystem, can only open specific devices, uses randomized UIDs, and has limited capabilities: https://www.freedesktop.org/software/systemd/man/latest/syst...
It is way simpler and cleaner than Docker/Podman IMHO.
As a passionate systemd hater I would say I do not agree. Cron syntax is worse.
This is why I like NixOS. Defining systemd services in it is very neat.
Could have been worse.
Could have been YAML.
Could have been XML.
XML would have the advantage of having a grammar so we could validate the config files.
It would also make it much simpler to make good GUI editors for the files instead of the Notepad approach most unix config files take.
The systemd dialect of INI is actually pretty well-defined though.
https://www.freedesktop.org/software/systemd/man/latest/syst...
I'd really like a collection of unit tests for parsers. There is a lot of details that can differ between parsers.
E.g. in "Section C" the resulting KeyThree is "value 3▵▵▵▵▵▵▵value 3 continued" where each "▵" symbol is a space.
I think most people would expect a single (or no) space here.
I would guess that most software would strip the comments in SectionC or rearrange the output so that it will result in a diff even when nothing in SectionC changed.
So if you edit the file by hand in the same style as shown in the examples, then most editors would not be able to make a minor edit without making a large diff as many sections would be formatted differently.
Since systemd is successfully parsing its INI files, and barks at you when you put weird shit into them, a grammar for them does exist as well.
XML is that wonderful format that gave us vulnerabilities like death by million laughs, up to a certain moment, you could MitM DTDs, and a whole slew of everything-XML stuff back when XML was like AI is today, none of which I miss today.
Oh, and remember times when programmers would argue whether argument order in XML files should be significant or not?
But XML books with their idealized XML future description did give me the same warm fuzzies as some intricate clockwork mechanism to a Victorian geek.
There are good GUI editors for XML?
XML - I see you’ve used macOS’ LaunchD, the system that inspired Systemd
Yeah, I'm a man of culture like this. However, systemd with its service dependencies runs circles around launchd in pretty much every aspect.
Service dependency resolution and parallel startup is super in systemd. Big fan of what I can do with it.
Could have been better.
Could have been XML Property Lists.
ducks
To be honest, I think either of those would have been better ...
/me cowers in fear
Oh yes, because the well documented clean syntax of sys v init shell scripts was so nice.
If I never recall hacking in ulimit calls in the top of buggy shell scripts for crappy old services that done respect pam_limits it won’t be soon enough.
Relevant, a golfed systemd polyglot file that is simultaneously an executable script: https://domi.work/blog/posts/compose_polyglot/
Yes, I have too much time sometimes... and I agree, I don't like the syntax.
Hard disagree. Compared to an init script, with all its boilerplate, I'd take a systemd unit file.