Daemons do not have different names across distributions, the Apache2 daemon is httpd regardless of distribution. However as you point out configuration locations can and will vary and also package names (but package names has nothing to do with systemd). If we look at the systemd unit file for Apache2 from RHEL7 there is these two lines:
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
So what happens here is that the unit file is the same regardless of distribution and then the distribution sets it's configuration locations into the
It doesn't matter what $MT_LOGFILE is set to, that is besides the point that I'm making. With SysVInit you have to tricks like this but with systemd it's no longer necessary since the journal will group together stdout, stderr and syslog into a single log.
But just to prove you wrong, let's look at "man mediatomb":
Do not output log messages to stdout, but redirect everything to a
So as you can see the whole point of -l is to not use stdout or stderr, in fact it cannot be any of those since it must be a physical file!
It's not always 0, it's only 0 of everything went ok for the things that the "systemctl start" command is concerned which is that it could schedule the service to be activated. This is just the way that the "modern" init launches like systemd, solaris smf, osx launchd and the upcoming new launcher for BSD (which I don't know the name for) works. With these you no longer run a shell script but instead schedule an event to occur and if that event does not occur, then it can wait some time and then try again (respawning failed services is one feature of systems like this) and thus there is a different way of finding out if a service is currently running or not.
With SysVInit there was no guarantee that the service would be running after it returned 0 since the service could encounter an error sometime after it forked (and that happens a lot I can tell you) so even there one really cannot use the exit code of "service xx start" but you have to do a "ps ax | grep xx" dance, or if the service was smart enough so store it's pid in a file you had to do that dance instead. So once people just calm down and get used to systemd they will probably discover that they now have a generic way to see if services are running and so on. And we need better unit files, the mysqld one is completely insane with the use of mysqld_safe since what that script does, systemd already does better, so it's completely useless not to mention that it makes mysqld to not log to the "correct" places.
The journal is empty because mysql.service does not start mysqld but the ancient mysqld_safe (which is no longer needed with systemd anyway):
And mysqld_safe by default prevents mysqld from syslog, from stdout and stderr. Instead it redirects all these to
Regarding the exit code from systemctl, I'm not really sure but I think that it only returns an error code if you tried to start a disabled service or a service that didn't exist. The proper way to check if the service is running is to issue a "systemctl is-failed mysqld.service" and then it will return 0 if the service failed to start and 1 if it's running.
Just to show an example, look what I found in the MediaTomb unit file:
ExecStart=/usr/bin/mediatomb -d -u $MT_USER -g $MT_GROUP -P
That "-l" there means that MediaTomb will not log to stdout/stderr/syslog but that it instead logs to it's own logfile in $MT_LOGFILE so no wonder one will never ever find MediaTomb logs in the journal, they are never sent there by the daemon in the first place.
Been Transferred Lately?