On Mon, Jan 22, 2018 at 7:49 AM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Fri, 29 Dec 2017 15:09:28 -0600
> Matt Hoosier <matt.hoos...@gmail.com> wrote:
>
>> Hi Lennart,
>>
>> On Mon, Dec 4, 2017 at 9:11 AM, Pekka Paalanen <ppaala...@gmail.com> wrote:
>> > On Fri, 1 Dec 2017 18:25:35 +0100
>> > Lennart Poettering <lenn...@poettering.net> wrote:
>> >
>
>> >> 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.
>
>> >> > > > > > +# 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.
>
>>
>> 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.
>
> Hi Matt,
>
> that is cool. Could you share your PAM file for 'weston'? When I get to
> re-spinning the example patch, I could use that instead of trying to
> craft my own which I probably could not test in any reasonable time.
Sure, although I'm not certain about its applicability to desktop
distributions. Mine is intended for an OpenEmbedded-style device, and
I basically just adapted the PAM file that some XDM recipe had:
auth required pam_unix.so null
account required pam_unix.so
session required pam_unix.so
-session optional pam_systemd.so
The entry about pam_systemd.so could probably be promoted to be
strictly required.
>
>> 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?
>
> That was an interesting point and it's nice to see Mantas' reply
> explaining what happens there. I should make a note of that as well.
>
>
> Thanks,
> pq
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
