[systemd-devel] Outputting STDOUT and STDERR to current $SSH_TTY

[Lennart Poettering]

On Mo, 14.08.17 22:31, Sergei Franco (sergei.franco at gmail.com) wrote:

> Admins expect output when starting and stopping services.
> This is even more important when there are runbooks and other processes
> involved.
> The journalctl output is very messy (because it is a log). When you are on
> call and you have to deal with an issue at 3am in the morning, the messy
> output adds to the already high cognitive load.
> As system engineers we used to be able write our own init scripts that
> would leave colourized and concise messages about particular sub-services
> of a service.
> This would make it easy for admin on call to determine if everything OK or
> not.

Note that there's "systemctl status" as a quick way to determine the
service status in one go, along with a brief excerpt of the most
recent logs.

> What is even more annoying when start up fails, it just tells you that it
> failed and for more info to see the status or journalctl. Would it not be
> more logical dump the standard error into current tty and status instead of
> pointless message?

There has been a TODO list item for a while to optionally show the log
output of a service during "systemctl start" as it
happens. i.e. "systemctl start -v" or so as a something of a
combination of "sstemctl start" + "journalctl -uf", but so far nobody
implemented that. It's not trivial though, due to the races involved,
i.e. it's hard ot know when precisely to stop waiting for logs, after
we got the start completion notification. This is fixable, but it#s
not trivial.

> There needs to be a setting to pass through stdout and error to whatever
> the tty is used to invoke the systemctl.
> 
> Warning: rant follows!
> 
> I am yet to see a systems engineer that praised systemd. All I hear
> from my

Maybe I live in a bubble, but I have seen quite a few actually...

> colleagues is swearing when they deal with systemd. What makes them angry?
> Inability to actually see what is going on. Has mysql actually failed to
> start or is it repairing tables after a crash? Who knows, systemd ate the
> output. Is the firewall script actually doing what is supposed to do or
> not, who knows, there is no way to pass that information directly without
> systemd hiding it. The only way to catch errors with bash scripts is using
> "set -e" (there is no eye balling it), which means even partial
> functionality now is a failure.

Well, this is deeply unfair.. "systemctl status" shows you ton of
information SysV never was able to show you. Please play around with
it before coming to early conclusions. Yes, it's different than Sysv,
but in many good ways, too.

> Even simple things like where is the bloody unit defined, is it in
> /etc/systemd/system/ or /lib/systemd/system/ or is it in
> /usr/lib/systemd/system/?.

Try "systemctl cat foobar.service" to see where something is defined,
and how exactly.

> What about tail -f 1000 /var/log/messages | grep
> bla | awk .. Can't really do that any more, as journalctl does not support
> number of lines to follow from (and again, I could be wrong here, I have
> been wrong many times).

Yes, you are wrong... "journalctl -f -n 1000" works just fine. Did you
actually play around with systemd at all?

> Why /lib/ for essentially config files? Isn't what /etc/ is for?

They aren't configuration files, they are vendor supplied defaults. If
you want to change them, copy them to /etc and modify them there, they
will then override the vendor defaults. "systemctl edit" does that for
you automatically btw.

> Then we have the whole "predictable" interface naming scheme, with names
> like enp35s0f1. Very "predictable" (they change!) and very "easy" to type
> in middle of night.

Well, then turn them off, if they don#t work on your hardware...

Lennart

-- 
Lennart Poettering, Red Hat