Re: [systemd-devel] [PATCH weston] doc/systemd: system service example
On Dec 29, 2017 15:32, "Mantas Mikulėnas"wrote: On Fri, Dec 29, 2017 at 11:09 PM, Matt Hoosier wrote: > > The approach that you and Pekka most recently put on record here: > > * User=foo > * PAMName=weston > > with a /etc/pam.d/weston that just does minimal stuff (enforce the > account exists and then execute pam_systemd.so for the session phase) > works well for me. > > One thing I can't figure out though: using PAMName= causes the service > process's journal entries emitted by regular stdout and stderr not to > be visible with 'journalctl -u weston.service' anymore. Only the > messages coming internally from systemd ("Started Weston." and > similar) show in that journal. > > I've tacked in StandardOutput=journal and StandardError=journal to > compensate for the StandardInput=tty-fail. The messages do make it > across to journald; you can view them with 'journalctl > /usr/bin/weston'. But somehow they're not associated with the system > unit weston.service anymore. Does using the PAMName= directive cause > the stdout/stderr messages to be reassigned to a user-session unit or > something? > No, it's done by pam_systemd specifically. The main purpose of pam_systemd is to create a user session and move the process to the session's own cgroup (from the weston.service cgroup). As a result systemd no longer considers it as belonging to the weston.service unit, but to session-c123.scope or such.) (The same happens with all other interactive login types -- e.g. when you log in at the console, you get moved out of getty@.service and into your own cgroup.) -- Mantas Mikulėnas Okay, thanks. So that's just hardwired behavior that we should expect? I tried looking around the source to pam_systemd a bit, but quickly lost track of the way that the 'type', 'class', and other parameters to logind's CreateSession() eventually interact with systemd recordkeeping. -Matt ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH weston] doc/systemd: system service example
On Fri, Dec 29, 2017 at 11:09 PM, Matt Hoosierwrote: > > The approach that you and Pekka most recently put on record here: > > * User=foo > * PAMName=weston > > with a /etc/pam.d/weston that just does minimal stuff (enforce the > account exists and then execute pam_systemd.so for the session phase) > works well for me. > > One thing I can't figure out though: using PAMName= causes the service > process's journal entries emitted by regular stdout and stderr not to > be visible with 'journalctl -u weston.service' anymore. Only the > messages coming internally from systemd ("Started Weston." and > similar) show in that journal. > > I've tacked in StandardOutput=journal and StandardError=journal to > compensate for the StandardInput=tty-fail. The messages do make it > across to journald; you can view them with 'journalctl > /usr/bin/weston'. But somehow they're not associated with the system > unit weston.service anymore. Does using the PAMName= directive cause > the stdout/stderr messages to be reassigned to a user-session unit or > something? > No, it's done by pam_systemd specifically. The main purpose of pam_systemd is to create a user session and move the process to the session's own cgroup (from the weston.service cgroup). As a result systemd no longer considers it as belonging to the weston.service unit, but to session-c123.scope or such.) (The same happens with all other interactive login types -- e.g. when you log in at the console, you get moved out of getty@.service and into your own cgroup.) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH weston] doc/systemd: system service example
Hi Lennart, On Mon, Dec 4, 2017 at 9:11 AM, Pekka Paalanenwrote: > On Fri, 1 Dec 2017 18:25:35 +0100 > Lennart Poettering wrote: > >> On Fr, 01.12.17 13:42, Pekka Paalanen (ppaala...@gmail.com) wrote: >> >> > > > > This is racy, as the session ID is not really reliably predictable, >> > > > > and is synthesized in different contexts in different ways, for >> > > > > example depnding on whether audit is enabled in the kernel it might >> > > > > be >> > > > > session-1.scope rather than session-c1.scope. >> > >> > > > If we could determine the bug doesn't exist anymore, that would be >> > > > awesome and I could just drop this. >> > >> > Hi Lennart, >> > >> > taking a step back, the session-c1.scope directive is definitely not >> > wanted and we should drop it. We should also use a custom PAM name >> > setup. If we do that, is the service file otherwise good for >> > guaranteeing: >> > >> > - a full user session setup (I presume we want it), specifically >> > XDG_RUNTIME_DIR being set up >> > >> > - running exclusively on a VT that is made current >> >> This really depends on how weston sets up a VT. I really don't know >> Weston and what it does. > > Weston doesn't set up the VT, we rely on the systemd unit directives to > set it up. > > Weston calls sd_pid_get_session(getpid()), sd_session_get_seat(), and wants > sd_session_get_vt() to succeed and give a VT number. Then it connects > to logind, wants TakeControl to succeed, and calls Activate. It uses > TakeDevice to open the DRM KMS device and input devices. I think that's > the start-up sequence, it also listens on signals from logind etc. > >> > - access to DRM and input devices via logind >> >> So, I can't comment on Weston really. > > No worries, that was more of a general question about whether the > example unit file was making any unwarranted assumptions. > >> Here are brief (and possibly slightly out-of-date, but probably not) >> notes on how to write display managers with logind: >> >> https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/ > > Thanks, I had a quick read through. We expect the systemd unit to also > set up PAM, Weston itself does not touch PAM. > >> > so that all these are already in place by the time the Weston process >> > is started? >> > >> > As you can see from Martyn below, the first issue that prevented Weston >> > from running was that XDG_RUNTIME_DIR was not set. Furthermore, this >> > failure did not occur always, sometimes things just worked as we >> > expected. >> >> So, as long as weston runs from a PAM enabled service (and its PAM >> snippet pulls in pam_systemd) all should be good and race-free: as the >> PAM session is set up XDG_RUNTIME_DIR will be made available and the >> systemd --user instance is invoked in the background. > > This is exactly what we attempted with the User and PAMName directive, > and it turned out to be racy somehow. > >> What currently is not supported is to run things independently of any >> session, i.e. run weston as systemd --user service with nothing that >> creates a session in the first place. In that case XDG_RUNTIME_DIR >> will not be set up, and no devices are made available to weston... > > Weston never was a --user service. > > As far as I know, there was also nothing that would manually attempt to > start user@.service, the only trigger for that were the User and PAMName > directives in the system weston.service. > >> > > > > > +# Set up a full user session for the user, required by Weston. >> > > > > > +PAMName=login >> > > > > >> > > > > Piggy-backing on "login" is a bad idea. "login" is a text tool, and >> > > > > thus the PAM rules for it usually pull in some TTY specific PAM >> > > > > modules. YOu shoudl really use your own PAM fragment here, and >> > > > > configure only the bits you need. >> > > > >> > > >> > > Oh, so could it just be that we needed something other than >> > > "PAMName=login"? >> > >> > What are they key bits in the PAM configuration we must have, and are >> > there any often used bits we must not have to avoid the race Martyn >> > describes? >> >> well, pam_systemd needs to be pulled in from it, that's the most >> important thing. A PAM snippet that pulls in pam_systemd means you get >> a session allcoated in logind, which in turn sets up XDG_RUNTIME_DIR >> for you. > > Yes, it was, but apparently somewhere in the PAM stack or something it > calls there was a race, which sometimes let Weston to start before > XDG_RUNTIME_DIR environment variable was set, causing weston to fail. > > We all here were quite baffled on what could even be racing, unless it > is possible that the weston process gets started in parallel with the > PAM setup done by the User/PAMName in weston.service. We assumed that > all the setup described in the systemd unit file would be guaranteed to > complete before the actual process gets started. > > It seems our and your expectations are aligned. Maybe we
[systemd-devel] question about socket activation
Hi, All I tried to test the socket activation by a simple foobar.socket and foobar.service, which are as the following: foobar.socket: [Socket] ListenStream=/dev/socket/foobar [Install] WantedBy=sockets.target foobar.service: [Service] Type=simple ExecStart=/usr/bin/test-socket Restart=no I also wrote a simple program to connect to /dev/socket/foobar , in order to activitate the foobar.service. When I ran the program, the foobar.service was started by systemd , and the foobar.socket changed from 'listening' state to 'running' state. All works OK as expected, but when I killed the test-socket, it was started again by the systemd, even if I didn't run my program. And from the system journal logs , I found that " Line 2035: 31,29604,571630004,-;systemd[1]: foobar.socket got notified about service death (failed permanently: no) Line 2038: 31,29605,571630065,-;systemd[1]: foobar.socket changed running -> listening Line 2050: 31,29609,571632385,-;systemd[1]: Incoming traffic on foobar.socket Line 2056: 28,29611,571633087,-;systemd[1]: Cannot add dependency job for unit systemd-bus-proxyd.socket, ignoring: Unit systemd-bus-proxyd.socket failed to load: No such file or directory. Line 2056: 28,29611,571633087,-;systemd[1]: Cannot add dependency job for unit systemd-bus-proxyd.socket, ignoring: Unit systemd-bus-proxyd.socket failed to load: No such file or directory. Line 2065: 31,29614,571633544,-;systemd[1]: foobar.socket changed listening -> running " It seems that immediately after the death of foobar.service,some unknown incoming traffic on foobar.socket made the foobar.service started again by the systemd . Could anyone give me some suggestion that who connected to the foobar.socket ? Any idea about how to debug this problem is very appreciated. Thanks a lot.___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel