Did you even follow the link to the StackOverflow article? It wasn't about systemd dropping stderr or stdout (which it doesn't do btw) but was about quite the opposite.
Even more hilarious is that the StackOverflow link he provided as help was for quite the opposite. It was a question from someone who did get stdout and stderr into the journal but didn't want to (short summary version):-)
A security nightmare? You anti systemd trolls are getting more and more tiresome. But oh please do tell which security nightmares that you have discovered in systemd?!
IF they are source code checkers then how do you propose that they work with closed source equally well? If they are used by the closed source companies, then yes if of course works but the point is that the company manufacturing the source code checker can use the large pool of open source software to improve their checker while also providing finds such as this. With the closed source company the company would have to actively run the checks, that's a big difference.
Of course you will have time syncs and os updates, but those things can hardly bee seen as unsolicited traffic like the telemetry that people are discussing. If the Windows 10 users are complaining about time syncs and os updates then they are completely crazy.
True that Ubuntu did it by default before (they have since disabled it) but you could easily disable it via the GUI settings. I disabled it and unless I actively do something with the network like surf the web with Firefox or stream music then a "sudo tcpdump -nvpi eth0" on my Ubuntu shows absolutely no connection attemps from my machine what so ever, all that I see is some other machine on the network sending broadcast ARP requests for the MAC of the defautl gateway.
Why would you be lost with very simple unit files as compared with lengthy and complex init scripts? There is no need to do distribution specific unit files since there is no difference there between distributions, file locations might differ but that is handled by configuration files and not by unit files. That each distribution needs their own init scripts is the problem, not the solution.
That is not a dependency on a specific pid 1 binary, that is a dependency on a functionality. How else do you think that they solved GDM on BSD, Solaris et al?
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.
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?
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?
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.
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:
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.
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).
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!
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.
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.
There is also a "systemctl is-active mysql.service" which returns 0 if it's running and 1 if it's not. Just so no one barks at the reversed exit code in my previous post.
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.
The journal is empty because mysql.service does not start mysqld but the ancient mysqld_safe (which is no longer needed with systemd anyway):
ExecStart=/usr/bin/mysqld_safe
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.
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.
So show one such repro step then, in every example that I have seen people have actively told the daemon to drop stderr due to it beeing copyied from a SysVInit script since SysVInit does not support stderr
Slashdot Mirror
Did you even follow the link to the StackOverflow article? It wasn't about systemd dropping stderr or stdout (which it doesn't do btw) but was about quite the opposite.
Even more hilarious is that the StackOverflow link he provided as help was for quite the opposite. It was a question from someone who did get stdout and stderr into the journal but didn't want to (short summary version) :-)
A security nightmare? You anti systemd trolls are getting more and more tiresome. But oh please do tell which security nightmares that you have discovered in systemd?!
IF they are source code checkers then how do you propose that they work with closed source equally well? If they are used by the closed source companies, then yes if of course works but the point is that the company manufacturing the source code checker can use the large pool of open source software to improve their checker while also providing finds such as this. With the closed source company the company would have to actively run the checks, that's a big difference.
You say that as if not all browsers will leave Pwn2Own 2016 broken by at least one team.
Of course you will have time syncs and os updates, but those things can hardly bee seen as unsolicited traffic like the telemetry that people are discussing. If the Windows 10 users are complaining about time syncs and os updates then they are completely crazy.
Why are a Windows 10 box in 2016 actually sending out freaking NetBIOS broadcasts for? That shit should be dead and buried decades ago.
True that Ubuntu did it by default before (they have since disabled it) but you could easily disable it via the GUI settings. I disabled it and unless I actively do something with the network like surf the web with Firefox or stream music then a "sudo tcpdump -nvpi eth0" on my Ubuntu shows absolutely no connection attemps from my machine what so ever, all that I see is some other machine on the network sending broadcast ARP requests for the MAC of the defautl gateway.
f.ultra@ubuntu:~$ sudo tcpdump -nvpi eth0
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:49:51.946496 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
19:49:53.996275 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
19:49:56.054219 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
19:49:58.136104 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
19:50:00.221756 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
19:50:02.276667 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
19:50:04.353056 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
19:50:06.431986 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
19:50:08.520302 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
19:50:10.584220 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
19:50:12.625328 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
19:50:14.712258 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
19:50:16.782389 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
19:50:18.856272 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.0.1 tell 192.168.0.249, length 46
And it goes on and on like that for hours, so no most Linux distros does not do some of this too.
Why would you be lost with very simple unit files as compared with lengthy and complex init scripts? There is no need to do distribution specific unit files since there is no difference there between distributions, file locations might differ but that is handled by configuration files and not by unit files. That each distribution needs their own init scripts is the problem, not the solution.
That is not a dependency on a specific pid 1 binary, that is a dependency on a functionality. How else do you think that they solved GDM on BSD, Solaris et al?
Think you are right, must have been since apache 1 I remember this, I switched to lighttpd when it came and never looked back :)
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.
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?
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?
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.
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:
EnvironmentFile=/etc/sysconfig/httpd
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.
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).
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!
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.
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.
There is also a "systemctl is-active mysql.service" which returns 0 if it's running and 1 if it's not. Just so no one barks at the reversed exit code in my previous post.
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.
The journal is empty because mysql.service does not start mysqld but the ancient mysqld_safe (which is no longer needed with systemd anyway):
ExecStart=/usr/bin/mysqld_safe
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.
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/mediatomb.pid -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.
So show one such repro step then, in every example that I have seen people have actively told the daemon to drop stderr due to it beeing copyied from a SysVInit script since SysVInit does not support stderr