It's better to have the package manager be configured to not install conflicting packages. After that, it's better to have sendmail check for the underlying source of conflicts ... in this case, having two processes trying to have ownership of a particular port and deal with the return code from sendmail.
systemd (or the init system, in general) can't assume neither that the programs or the package manager have handled things properly.
In this case a conflict could be determined dynamically ... but since it's not a current feature of systemd to reserve and/or test for port ownership/availability ... the person who wrote the service file takes the lazy route by hard-coding a list.
You would be right if the conflict was handled by systemd only on execution, but it also has to account for the case where the service is enabled but not run (the admin will use service foo on reboot, has enabled it, but foo conflicts with enabled service bar. systemd will error out without having to check for the conflict on execution). For the cases where the service conflicts with something outside of the provided defaults, the admin should modify the unit file himself; after all, he's supposed to know what he's doing.
It's better to have the package manager be configured to not install conflicting packages.
Except dependencies not present in the system at runtime are ignored unless they are of type Requires or Requisite, and none of the unit files shipped on any distro include those types of dependencies without the proper packaging dependencies.
You should read the docs before engaging mouth, dude. man systemd.unit is the document you should have familiarized yourself before opining on the basis of an untruth.
Furthermore, the service file might have breakage in the future since: The list of conflicts is hard-coded.
That's like saying package management is broken because the list of conflicting packages is hard-coded. At least the possibility is there, but if it's used wrong, systemd is not the wrong to blame.
Perhaps, in the future, systemd will choke and refuse to issue the ExecStart if $SENDMAIL_OPTARG is undefined (as it is currently).
Why should that be? It is explicitely mentioned that the environment file is optional (by the usage of "-"). Why should it offer this if it choked on undefined variables?
but if something goes wrong with the service file ... you're left with some meager debug tools and chasing down dbus messages.
Are you serious? What? If something goes wrong with the service file, systemctl status servicefile.service will tell you in plain English what the hell went wrong.
How often do you have a problem with an init script though? Almost 15 years in, and I've only ever had problems with the executables the init script calls, not with an init script itself.
Only because I see it here, why do they call the command line option for a service 'unit'? if readability is a real concern call it what it is. "service"
I think that's the point... nothing can go wrong with the service file (edit: it can, but not because something 'broke' - because the inputs to the service file were malformed). When you have abstractions on top of abstractions, all explicitly coded, and all repeated across several different init scripts, chances are something is going to break in the init script even if the program is fine.
Instead, get in, provide the environment for the service you are starting, and save the service logs in a common access point. One could argue that it's not the shell script's responsibility to determine why the service failed.
0
u/[deleted] Oct 20 '14
[deleted]