[prev in list] [next in list] [prev in thread] [next in thread] 

List:       systemd-devel
Subject:    Re: [systemd-devel] Fwd: Handling ExecStop failure
From:       Lennart Poettering <lennart () poettering ! net>
Date:       2016-05-24 9:27:50
Message-ID: 20160524092749.GA13996 () gardel-login
[Download RAW message or body]

On Tue, 24.05.16 14:29, Ashish Sangwan (ashishsangwan2@gmail.com) wrote:

> > As discussed in the other mails in this thread: maybe this is simply
> > confusion about what "console" in StandardOutput=console+journal
> > actually means. It does not mean the tty that you invoked "systemctl"
> > from. Instead, it literally means /dev/console, i.e. the kernel's
> > console device, wherever that may point to. if you are running a
> > graphical UI of some kinda, /dev/console is usually not seen.
> 
> Yeah, you are right. /dev/console is there but it is not used.
> The bash shell on which systemctl is executed is using /dev/pts/X
> So I used the StandardOutput=tty option and set TTYPath=/dev/pts/X
> and it worked. But the issue is we cannot hard code the TTYPath in the unit
> file as the "X" in /dev/pts/X keeps changing. It could be 0/1/2 and so on.

Yeah, systemd will run services completely detached from the session
and terminal you started the command from. This is necessary to ensure
that the same execution environment is used, regardless how the
service is started and job merging can work properly.

systemd is quite different from sysv this way: systemd's focus is
really on executing the services it runs in completely cleaned up,
pristine execution contexts, with no relationship to the client that
might have started it.

Lennart

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

[prev in list] [next in list] [prev in thread] [next in thread]