<div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On Dec 29, 2017 15:32, "Mantas Mikulėnas" <<a href="mailto:grawity@gmail.com">grawity@gmail.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="quoted-text">On Fri, Dec 29, 2017 at 11:09 PM, Matt Hoosier <span dir="ltr"><<a href="mailto:matt.hoosier@gmail.com" target="_blank">matt.hoosier@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-2151760485754628016h5"><br>
</div></div>The approach that you and Pekka most recently put on record here:<br>
<br>
* User=foo<br>
* PAMName=weston<br>
<br>
with a /etc/pam.d/weston that just does minimal stuff (enforce the<br>
account exists and then execute pam_systemd.so for the session phase)<br>
works well for me.<br>
<br>
One thing I can't figure out though: using PAMName= causes the service<br>
process's journal entries emitted by regular stdout and stderr not to<br>
be visible with 'journalctl -u weston.service' anymore. Only the<br>
messages coming internally from systemd ("Started Weston." and<br>
similar) show in that journal.<br>
<br>
I've tacked in StandardOutput=journal and StandardError=journal to<br>
compensate for the StandardInput=tty-fail. The messages do make it<br>
across to journald; you can view them with 'journalctl<br>
/usr/bin/weston'. But somehow they're not associated with the system<br>
unit weston.service anymore. Does using the PAMName= directive cause<br>
the stdout/stderr messages to be reassigned to a user-session unit or<br>
something?<br clear="all"></blockquote><div><br></div></div><div>No, it's done by pam_systemd specifically.</div><div><br></div><div>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.)<br></div><div><br></div><div>(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.)<font color="#888888"><br></font></div></div><font color="#888888"><br>-- <br><div class="m_-2151760485754628016gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></font></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">-Matt</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><font color="#888888">
</font></div></div>
</blockquote></div><br></div></div></div>