Please create an account to participate in the Slashdot moderation system


Forgot your password?

Comment Re:Newbie question (Score 1) 85

So why was it no problem that most distributions forced SysV on you, or that Ubuntu forced upstart on you? In fact there are tons of software that are forced on me by a distribution, be it grub, libc, or which version of gcc they used to compile the binaries with (not to mention which cflags they used). That it comes as default does not meant that you cannot use another init system if you want, all SysV scripts are still there.

Comment Re: And a big reduction in manageability... (Score 1) 110

No you don't understand what is happening here, it's the service/daemon it self that redirects stderr to /dev/null, and it does this regardless of if you run it on BSD, on SysV or on systemd. How do you propose to be able to log stderr when the application itself redirects it to /dev/null?

Comment Re:Newbie question (Score 1) 85

Which user space applications depends on a specific binary being pid 1? And for the other utilities in the systemd suite, why is it seen as a major problem that you get more choices for which software to run? Did you get just as upset when lighttpd or nginx where created since Apache should be the only piece of software that we need?

Comment Re: Newbie question (Score 1) 85

So it seams, looks like I spoke too soon. Has this been changed because I remember (but of course that memory can be false) that apache2 was /usr/sbin/httpd in Debian back in the day (it's several years since I used either Debian nor Apache). Either way, sorry for speaking while uninformed.

Comment Re: Newbie question (Score 1) 85

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 /etc/sysconfig/httpd file by setting $OPTIONS. This way there can be a unified unit file but still differences between distributions. Because to have unified unit files is one of the goals of systemd, the thought is to have a central shared repository of unit files from which the various distributions then simply can sync whenever they update systemd (or when the feel like updating their unit files) without putting the burden on each maintainer/developer to create a distribution specific init script which is the case with SysV.

Comment Re: And a big reduction in manageability... (Score 1) 110

systemd does not swallow stderr, if you see no stderr in the journal then it's because who ever wrote the unit code decided to redirect it to /dev/null or the service did a daemon() call to do the same (in which case you wouldn't get stderr in SysV either), and it doesn't hide the error (it just works differently than SysV).

Comment Re:What the fuck is $MT_LOGFILE set to? (Score 1) 110

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":
-l, --logfile
Do not output log messages to stdout, but redirect everything to a
specified file.

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!

Comment Re:Newbie question (Score 3, Interesting) 85

The unification with systemd is so that you as a daemon developer only have to write one single unit file that then will work across all different distributions that use systemd, it has nothing to do with limiting your choice in configuration. There should be no less choice in configuration of systemd for you as an administrator than what you already have with SysVInit. You can run what ever scripts from the unit files that you want. I would very much like to hear why you think that systemd lessens your configurability.

Comment Re: And a big reduction in manageability... (Score 1) 110

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.

Comment Re: And a big reduction in manageability... (Score 1) 110

Or simply it will take some time until developers and managers discover that things that they did and which made sense in a SysVInit script no longer does in a systemd unit file. Often in SysVInit scripts stderr and co are sent to /dev/null (or forking using the daemon() call which does exactly that) something that is no longer needed for systemd.

Comment Re: And a big reduction in manageability... (Score 1) 110

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 /var/log/mysql.err. So it's another case where the people who created the systemd unit file didn't know what they where doing, they simply copied how they did it in the SysVInit script.

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.

Comment Re: And a big reduction in manageability... (Score 4, Informative) 110

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 /run/ -l $MT_LOGFILE -m $MT_HOME -f $MT_CFGDIR -p $MT_PORT -e $MT_INTERFACE

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.

Slashdot Top Deals

Been Transferred Lately?