Le mercredi 05 septembre 2012 à 07:07 +0200, Jan Engelhardt a écrit :
On Tuesday 2012-09-04 21:10, Andreas Jaeger wrote:
Yes, and that's very good. But in 12.1, service status reporting was quite lacking with SystemD, and it was a SystemD shortcoming, not a packaging or training issue.
Can you give me an example so that we can compare with 12.2?
Thinking about it...
Something I always held up was that the rc* scripts were able to directly output (some) problems to the tty that they were executed from.
- dhcpd: when DHCPD_INTERFACES in /etc/sysconfig/dhcpd was not set, rcdhcpd would blurt it out on stdout/stderr. With the systemd unit, you now have to take the detour to /var/log/messages to figure out why.
- mysql: Like when starting mysql for the first time, you were instructed to set a password. Because systemd does not output anything, you now have a blazingly open sql service.
- rcXX gave visual feedback on whether starting a daemon succeeded (or rather, seemed to succeed from a startproc(8) perspective); the startproc(8) heuristic included waiting half a second or so by default to see if the daemon died again shortly after starting it. AFAICS systemctl does no such thing, which means you have to also call an extra command just to see whether all went ok.
And it does not seem to be technically difficult either. `systemctl start whatever` would just need to display the stdout/stderr stream from the daemon (which systemd has already captured to relay it to /var/log/messages) for .5 sec, and call and display "status whatever" afterwards.
That would do a lot in terms of reporting.
Which is why journal was written, and since 12.2, systemctl status
<servicename>.service is reporting the relevant log from the service.
--
Frederic Crozat