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

[Lennart Poettering]

On Di, 15.08.17 09:14, Sergei Franco (sergei.fra...@gmail.com) wrote:

> Please accept my apologies for HTML email (using gmail client).
> 
> For our organisation mid-2016 was the year of systemd, and exposure
> has been minimal (only new builds), so I guess you had a head start. I
> fully grasp the config file layout and overrides (I use them to deal
> with things like LimitNOFILE and ExecStartPost). My comments were from
> perspective of someone recently coming from init scripts. I still
> thinks /lib/ is bad place for system config (should have been another
> directory in /etc/systemd).
> 
> In contrast I had no issues with upstart what so ever.
> 
> In any way, since it is going down towards personal attacks, lets go
> back to original problem:
> 
> How does one convey the service output (stdout/stderr) to the console
> from which user initiated systemctl? I guess consensus is that you
> cannot.
> 
> If so, is it possible to make systemctl to display status after a state 
> change?
> Eg: running systemctl restart apache2 it fires off systemctl status
> apache2 after?

Try "journalctl -u apache2 -f" to get a live view on the stuff apache2
does, and everything systemd does with it.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Mo, 14.08.17 22:31, Sergei Franco (sergei.fra...@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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Sergei Franco]

Please accept my apologies for HTML email (using gmail client).

For our organisation mid-2016 was the year of systemd, and exposure
has been minimal (only new builds), so I guess you had a head start. I
fully grasp the config file layout and overrides (I use them to deal
with things like LimitNOFILE and ExecStartPost). My comments were from
perspective of someone recently coming from init scripts. I still
thinks /lib/ is bad place for system config (should have been another
directory in /etc/systemd).

In contrast I had no issues with upstart what so ever.

In any way, since it is going down towards personal attacks, lets go
back to original problem:

How does one convey the service output (stdout/stderr) to the console
from which user initiated systemctl? I guess consensus is that you
cannot.

If so, is it possible to make systemctl to display status after a state change?
Eg: running systemctl restart apache2 it fires off systemctl status
apache2 after?

I guess I could alias systemctl with a wrapper...

Regards.


Sergei.




On 15 August 2017 at 02:14, Reindl Harald  wrote:
>
>
> Am 14.08.2017 um 12:31 schrieb Sergei Franco:
>>
>> 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/?
>
>
> guess what the loaded line tells you...
>
> [root@rh:~]$ systemctl status httpd
> ? httpd.service - Apache Webserver
>Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor
> preset: disabled)
>Active: active (running) since Mo 2017-08-14 15:11:06 CEST; 58min ago
>
> [root@rh:~]$ systemctl status dhcpd-vmware.service
> ? dhcpd-vmware.service - DHCPD VMWare
>Loaded: loaded (/etc/systemd/system/dhcpd-vmware.service; enabled; vendor
> preset: disabled)
>Active: active (running) since Mo 2017-08-14 09:59:18 CEST; 6h ago
>
>> 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).
>
>
> what about forward it to rsyslog as i do and just continue using what you
> used before
>
>> Why /lib/ for essentially config files? Isn't what /etc/ is for?
>
>
> beause now you can override distribution configs and unit-files in a
> predictable way by just create the eactly same file below /etc/systemd/sysem
> as the distribution shipped it with /usr/lib/systemd/system
>
> because now you have things like /etc/systemd/system/servicename.d/ for
> specific overrides which works *predictable* and can be combined as you want
> it - but you probably don't gasp that by lack of basic understanding
>
> and if you want to be taken serious stop convert a plaintext mail
> conversation into useless HTML responses overrding my font and color
> settings
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Reindl Harald]

Am 14.08.2017 um 12:31 schrieb Sergei Franco:

Admins expect output when starting and stopping services


admins should learn to deal with their system

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


when you still don't know that "systemctl status service" gives you the 
recent relevant journal output better do your homework before wwrite 
long emails


I am yet to see a systems engineer that praised systemd. All I hear from 
my 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


here i am - we migrated in 2012 to systemd for *all our infrastructure* 
and after invent our core-software 15 years ago, wrote all the server 
mnagment tools, maintainance and deployment stuff at my own i tend to 
call myself a "systems engineer"


get out of my sight with all that crappy initsripts for services

in the state of Fedora 15 systemd has a lot of problems but if you have 
in 2017 still serious *general* problems with it that are not irrelevant 
by the security/sandboxing features for servers the problem is in front 
of the screen

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Sergei Franco]

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.

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 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
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.

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/?. 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).

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

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.

I would take simplicity over boot up times any day. How often do you think
we reboot our servers? I have no problem with actual unit definitions and
what systemd as init system trying to do.
I have a problem with binary logs that simply discard all information after
the corruption (right where fiber channel dropped couple of packets and you
needed to see those IO erros).
I have a problem where dhcp clients, ntp and resolvers are being reinvented
for sake of it (and with whole bunch of new security holes).

What happen to do one thing and do it well philosophy?

Regards.

Sergei.

On 14 August 2017 at 21:20, Zhujiafa <zhuji...@huawei.com> wrote:

> "  With systemd all output is "hidden",  "
>
>  He just wanted to see more detailed boot messages
>  too determine the .service is correct !
> 
> ZhuJiafa
> email: zhuji...@huawei.com
> tel: +86 18651652661 <+86%20186%205165%202661>
>
>
> *From:* vcap...@pengaru.com
> *Date:* 2017-08-12 02:57
> *To:* Zhujiafa <zhuji...@huawei.com>
> *CC:* Reindl Harald <h.rei...@thelounge.net>; systemd-devel@lists.
> freedesktop.org
> *Subject:* Re: [systemd-devel] Outputting STDOUT and STDERR to current
> $SSH_TTY
>
> This is not recommended.  Forwarding is currently implemented
> synchronously in journald, and can have a very substantial negative
> impact on journald performance in general as a result.
>
> BTW: are we not averse to top-posting on systemd-devel?
>
> Regards,
> Vito Caputo
>
>
> On Fri, Aug 11, 2017 at 05:47:15AM +, Zhujiafa wrote:
> > add
> > " systemd.journald.forward_to_console=1 "
> >  to your kernel  parameters.
> >
> >
> > 
> > 
> > ZhuJiafa
> > email: zhuji...@huawei.com<mailto:zhuji...@huawei.com
> <zhuji...@huawei.com>>
> > tel: +86 18651652661 <+86%20186%205165%202661>
> >
> > From: Reindl Harald<mailto:h.rei...@thelounge.net
> <h.rei...@thelounge.net>>
> > Date: 2017-08-11 13:37
> > To: systemd-devel@lists.freedesktop.org<mailto:systemd-devel@lists.
> freedesktop.org <systemd-devel@lists.freedesktop.org>>
> > Subject: Re: [systemd-devel] Outputting STDOUT and STDERR to current
> $SSH_TTY
> >
> >
> >
> > Am 11.08.2017 um 04:29 schrieb Sergei Franco:
> > > I am trying to retain behaviour of the startup scripts the same as
> sysvinit.
> > > For example, on sysv the script outputs feedback to the console when
> the
> > > stopping and s

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

[Zhujiafa]

"  With systemd all output is "hidden",  "

 He just wanted to see more detailed boot messages
 too determine the .service is correct !

ZhuJiafa
email: zhuji...@huawei.com<mailto:zhuji...@huawei.com>
tel: +86 18651652661

From: vcap...@pengaru.com<mailto:vcap...@pengaru.com>
Date: 2017-08-12 02:57
To: Zhujiafa<mailto:zhuji...@huawei.com>
CC: Reindl Harald<mailto:h.rei...@thelounge.net>; 
systemd-devel@lists.freedesktop.org<mailto:systemd-devel@lists.freedesktop.org>
Subject: Re: [systemd-devel] Outputting STDOUT and STDERR to current $SSH_TTY

This is not recommended.  Forwarding is currently implemented
synchronously in journald, and can have a very substantial negative
impact on journald performance in general as a result.

BTW: are we not averse to top-posting on systemd-devel?

Regards,
Vito Caputo


On Fri, Aug 11, 2017 at 05:47:15AM +, Zhujiafa wrote:
> add
> " systemd.journald.forward_to_console=1 "
>  to your kernel  parameters.
>
>
> 
> 
> ZhuJiafa
> email: zhuji...@huawei.com<mailto:zhuji...@huawei.com>
> tel: +86 18651652661
>
> From: Reindl Harald<mailto:h.rei...@thelounge.net>
> Date: 2017-08-11 13:37
> To: 
> systemd-devel@lists.freedesktop.org<mailto:systemd-devel@lists.freedesktop.org>
> Subject: Re: [systemd-devel] Outputting STDOUT and STDERR to current $SSH_TTY
>
>
>
> Am 11.08.2017 um 04:29 schrieb Sergei Franco:
> > I am trying to retain behaviour of the startup scripts the same as sysvinit.
> > For example, on sysv the script outputs feedback to the console when the
> > stopping and starting is done via console.
> > With systemd all output is "hidden", and to see the output you need to
> > check the journal (or syslog if configured). There is no feedback.
> >
> > Is it possible to configure StandardOutput=tty (and StandardErrror)
> > where TTYPath= is set to current $SSH_TTY env (be that
> > /devpts/0,/dev/pts/1 or /dev/pts/n)?
>
> no, because PID1 is a completly different process than any TTY
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[vcaputo]

This is not recommended.  Forwarding is currently implemented
synchronously in journald, and can have a very substantial negative
impact on journald performance in general as a result.

BTW: are we not averse to top-posting on systemd-devel?

Regards,
Vito Caputo


On Fri, Aug 11, 2017 at 05:47:15AM +, Zhujiafa wrote:
> add
> " systemd.journald.forward_to_console=1 "
>  to your kernel  parameters.
> 
> 
> 
> 
> ZhuJiafa
> email: zhuji...@huawei.com<mailto:zhuji...@huawei.com>
> tel: +86 18651652661
> 
> From: Reindl Harald<mailto:h.rei...@thelounge.net>
> Date: 2017-08-11 13:37
> To: 
> systemd-devel@lists.freedesktop.org<mailto:systemd-devel@lists.freedesktop.org>
> Subject: Re: [systemd-devel] Outputting STDOUT and STDERR to current $SSH_TTY
> 
> 
> 
> Am 11.08.2017 um 04:29 schrieb Sergei Franco:
> > I am trying to retain behaviour of the startup scripts the same as sysvinit.
> > For example, on sysv the script outputs feedback to the console when the
> > stopping and starting is done via console.
> > With systemd all output is "hidden", and to see the output you need to
> > check the journal (or syslog if configured). There is no feedback.
> >
> > Is it possible to configure StandardOutput=tty (and StandardErrror)
> > where TTYPath= is set to current $SSH_TTY env (be that
> > /devpts/0,/dev/pts/1 or /dev/pts/n)?
> 
> no, because PID1 is a completly different process than any TTY
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Mantas Mikulėnas]

Doing that directly makes little sense. The terminal will eventually go
away, and your service will start getting write errors for stdout.

Instead it would be better if systemctl could spawn `journalctl --follow
--unit=`... I remember it used to have a follow option for status.

On Fri, Aug 11, 2017, 05:29 Sergei Franco  wrote:

> Hi,
>
> I am trying to retain behaviour of the startup scripts the same as
> sysvinit.
> For example, on sysv the script outputs feedback to the console when the
> stopping and starting is done via console.
> With systemd all output is "hidden", and to see the output you need to
> check the journal (or syslog if configured). There is no feedback.
>
> Is it possible to configure StandardOutput=tty (and StandardErrror) where
> TTYPath= is set to current $SSH_TTY env (be that /devpts/0,/dev/pts/1 or
> /dev/pts/n)?
>
> Regards.
>
> Sergei.
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-- 

Mantas Mikulėnas 
Sent from my phone
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Zhujiafa]

add
" systemd.journald.forward_to_console=1 "
 to your kernel  parameters.




ZhuJiafa
email: zhuji...@huawei.com<mailto:zhuji...@huawei.com>
tel: +86 18651652661

From: Reindl Harald<mailto:h.rei...@thelounge.net>
Date: 2017-08-11 13:37
To: 
systemd-devel@lists.freedesktop.org<mailto:systemd-devel@lists.freedesktop.org>
Subject: Re: [systemd-devel] Outputting STDOUT and STDERR to current $SSH_TTY



Am 11.08.2017 um 04:29 schrieb Sergei Franco:
> I am trying to retain behaviour of the startup scripts the same as sysvinit.
> For example, on sysv the script outputs feedback to the console when the
> stopping and starting is done via console.
> With systemd all output is "hidden", and to see the output you need to
> check the journal (or syslog if configured). There is no feedback.
>
> Is it possible to configure StandardOutput=tty (and StandardErrror)
> where TTYPath= is set to current $SSH_TTY env (be that
> /devpts/0,/dev/pts/1 or /dev/pts/n)?

no, because PID1 is a completly different process than any TTY
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Reindl Harald]

Am 11.08.2017 um 04:29 schrieb Sergei Franco:

I am trying to retain behaviour of the startup scripts the same as sysvinit.
For example, on sysv the script outputs feedback to the console when the 
stopping and starting is done via console.
With systemd all output is "hidden", and to see the output you need to 
check the journal (or syslog if configured). There is no feedback.


Is it possible to configure StandardOutput=tty (and StandardErrror) 
where TTYPath= is set to current $SSH_TTY env (be that 
/devpts/0,/dev/pts/1 or /dev/pts/n)?


no, because PID1 is a completly different process than any TTY
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Sergei Franco]

Hi,

I am trying to retain behaviour of the startup scripts the same as sysvinit.
For example, on sysv the script outputs feedback to the console when the
stopping and starting is done via console.
With systemd all output is "hidden", and to see the output you need to
check the journal (or syslog if configured). There is no feedback.

Is it possible to configure StandardOutput=tty (and StandardErrror) where
TTYPath= is set to current $SSH_TTY env (be that /devpts/0,/dev/pts/1 or
/dev/pts/n)?

Regards.

Sergei.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel