Re: [systemd-devel] Monotonic time went backwards, rotating log

[Pekka Paalanen]

On Thu, 05 Oct 2023 13:32:37 -0400
Phillip Susi  wrote:

> Phillip Susi  writes:
> 
> > Lennart Poettering  writes:
> >  
> >> It actually checks that first:
> >>
> >> https://github.com/systemd/systemd/blob/main/src/libsystemd/sd-journal/journal-file.c#L2201
> >>   
> >
> > That's what I'm saying: it should have noticed that FIRST and not gotten
> > to the monotonic time check, but it didn't.  
> 
> I decided to try looking into this again.  It seems it's also my system
> log that is rotated on each boot with this message about the monotonic
> clock, despite the fact that it should be rotated first just because
> it's a new boot.

Hi,

have you checked your boot ID, maybe it's often the same as the previous
boot?

IIRC I had that problem on a device that had no RTC and when no
software (kernel, etc.?) had been updated at all. The said device had
problems keeping its logs in order, too, with some old systemd version.


Thanks,
pq

> There are some debug prints that might shed light on what is happening,
> but I can't seem to get them to enable.  I tried setting
> Environment=SYSTEMD_DEBUG_LEVEL=debug on systemd-journald.service, but I
> still don't get them.
> 



pgpt3diZjWPGL.pgp
Description: OpenPGP digital signature

Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?

[Pekka Paalanen]

On Fri, 1 Sep 2023 13:37:46 +0200
Lennart Poettering  wrote:

> On Fr, 01.09.23 13:13, Christian Pernegger (perneg...@gmail.com) wrote:
> 
> > I don't know about this. Yes, seat1 could hog the GPU that seat0's
> > outputs are attached to, or vice versa, but seat1 could just as well
> > hog all the RAM or saturate the CPU. My point being, seats share the
> > host's CPU power, RAM, ..., already, why not the rendering/compute
> > power as well. IMVHO it's really just inputs and outputs that should
> > be seat-specific. Restricting the shared resources available to a
> > given seat, allocating them fairly, etc., is a different problem (and
> > arguably one that I'd tackle per user and not per seat).  
> 
> CPU/RAM are by default resource managed, i.e. each user logged in gets
> a similar amount under pressure, as controlled via the cgroups
> logic.
> 
> This is different from GPU resources, there's no such reosurce
> management for that.

If you mean cgroup resource limits for GPUs, yeah, it's not there yet,
but I've seen people trying to add them. It just seems difficult to
define what those resources are exactly and how to measure them in a
sensible way, since GPUs have wildly different execution unit
architectures.

I'm not sure what the current patch state is.


Thanks,
pq


pgp8gyq3kPyME.pgp
Description: OpenPGP digital signature

Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?

[Pekka Paalanen]

On Fri, 1 Sep 2023 13:13:12 +0200
Christian Pernegger  wrote:

> Alright. I only played around with it in the hopes that it would help
> me get some VTs (and VT switching) on seat1. So far, no luck on that
> front.

The funny thing there is that the kernel, where the VT is implemented,
has no idea of any seat assignments. Seat management is completely a
userspace invention.

This can have some wild (security) consequences:
https://gitlab.freedesktop.org/wayland/weston/-/issues/434
IOW, if seat0 is running only VT, you might have keyboards from *any*
seat type into that VT *in addition* to any session running on that
other seat.

It's also common to assume, that only the default seat (seat0) can even
have VTs. I don't see how you could have VTs on multiple seats, when
the kernel simply has no concept of a seat. There is only one VT
system, and that either takes input or does not (there is an ioctl for
that). Individual input devices can only be excluded from the VT by
opening and grabbing them, meaning nothing else can get them either.

It would be best to forget the kernel VTs completely, and implement the
equivalent in userspace, which can then be seat-aware and much more
featureful (fonts, input methods) than the in-kernel VT can ever be.

E.g. kmscon: https://wiki.archlinux.org/title/KMSCON

Unfortunately looks like the original repository has been untouched for
a decade now. Arch seems to be using this instead:
https://github.com/Aetf/kmscon/

You might even want to aim for CONFIG_VT=n, in which case
https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/?rdt=37727
might be interesting.


Thanks,
pq


pgpBqMGXEm3d4.pgp
Description: OpenPGP digital signature

Re: [systemd-devel] Attaching virtual session (e.g. SSH) to seat

[Pekka Paalanen]

On Sat, 1 Oct 2022 16:18:43 +0300
Andrei Borzenkov  wrote:

> On 01.10.2022 15:46, Nils Kattenbeck wrote:
> > I am logging in on a PC using SSH and need to access some peripherals
> > which are attached to seat0.
> > loginctl shows that my session is not attached to any seat:
> > 
> > SESSION  UID USER  SEAT TTY
> >  50 1000 septatrix  pts/0
> > 
> > The devices are added to the seat using udev rules
> > and I explicitly want to avoid making the device world read-/writeable
> > or adding it to a group.
> > Reading through the man pages for systemd-logind, pam_systemd etc
> > did not lead me anywhere helpful but only confirmed the fact
> > that virtual sessions are not assigned any seat by default.
> > However I was unable to find information on how it is determined
> > if a session is "virtual" or whether it can be configured for 
> > pam/logind/udev...  
> 
> pam_systemd first seat preference is XDG_SEAT environment variable so
> you probably can somehow force it. But logind assumes seat0 has ttys and
> session runs on specific ttyN so there could be unexpected issues with
> session management (like activation/deactivation).
> 
> logind sets device permissions for the currently active session on
> seat0. Normally there is just one such session - session that is
> attached to foreground tty. If you manage to force (multiple) ssh
> sessions to also belong to seat0 and multiple users are logged in
> concurrently - which session should logind use to set permissions?
> 
> Also I am not sure logind can manage two multiple active sessions on the
> same seat in the first place.

I'm pretty sure logind can handle multiple sessions on the same seat
just fine. The d-bus API has things like ActivateSession:
https://www.freedesktop.org/software/systemd/man/org.freedesktop.login1.html

That's how it is supposed to work on seats other than seat0, they won't
have VTs to begin with.

However, I would tend to share your scepticism on whether one can
make it reasonably work on seat0 when VTs exist. The need to manage VTs
on seat0 might be ingrained in logind. Theoretically, one might have
better luck if VTs are disabled in the kernel, but of course lots of
local console stuff is probably depending on kernel VTs and would break
then - not give local access to the machine.

A couple years ago I was looking at pretty much the same problem to
help people who want to run Weston (a Wayland display server) via SSH
and present to the machine's own monitor. I did not find any solution
that would just work, aside from running everything as root and
bypassing logind completely which I won't recommend to anyone, or using
a systemd unit to start Weston which also requires root but doesn't run
Weston as root.

Nowadays libseat and seatd exist, which could be leveraged instead of
logind, avoiding the policy checks that logind has. 

https://git.sr.ht/~kennylevinsen/seatd

Of course, running two seat managers at the same time to control the
same seat is perhaps not a good idea.

I don't know how to solve the problem, but maybe these are some leads.


Thanks,
pq


pgpThTGNDwcyK.pgp
Description: OpenPGP digital signature

Re: [systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators

[Pekka Paalanen]

On Thu, 27 May 2021 17:33:35 +0200
Lennart Poettering  wrote:

> On Sa, 22.05.21 13:50, Pekka Paalanen (ppaala...@gmail.com) wrote:
> 
> > All in all, this stack would replace the usual stack where
> > /bin/login runs directly on the TTY of a VT, allowing to use a more
> > featureful terminal, custom display modes, multi-output support,
> > maybe multiple parallel sessions for different users a la fast user
> > switching, and more.  
> 
> When you say /bin/login do actually intend to say "getty"? what is
> /bin/login good for here? it's a stub that expects you already give it
> a user and it then only asks for a pw. It's the second part of a getty
> pretty much.

Yes, sorry. I'm not clear what any of them actually do. Hence, please
replace everything I've called "the login program" or similar with
yours above.


Thanks,
pq


> We have multiple services that you can instantiate on ttys, for
> example getty@.service (for true VTs), serial-getty@.service (for
> serial ports), container-getty.service (for /dev/console),
> container-getty@.service (for gettys on pseudo TTYs, pretty much).
> 
> It appears to me that the right approach for your case is to do what
> container-getty@.service effectively does and instantiate an
> appropriate instance of a template service modelled after it for the
> "other" side of the pty your terminal app allocates.
> 
> Instantiating -getty@.service requires privs, but you can use
> polkit to grant that to your terminal app's user. THe polkit auth
> request carries the unit name as additional metadata, hence that
> should be pretty easily done with some minimal polkit JS.
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin



pgpvov3lCxPQY.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators

[Pekka Paalanen]

On Sat, 22 May 2021 16:18:35 -0400
nerdopolis  wrote:

> On Saturday, May 22, 2021 3:14:27 PM EDT Pekka Paalanen wrote:
> > On Sat, 22 May 2021 09:04:42 -0400
> > nerdopolis  wrote:
> >   
> > > On Saturday, May 22, 2021 6:50:09 AM EDT Pekka Paalanen wrote:  
> > > > On Fri, 21 May 2021 21:29:09 -0400
> > > > nerdopolis  wrote:
> > > > 
> > > > > Sorry, I got the terminology mixed up again. I am still using TTYs to 
> > > > > run the
> > > > > instances of `cage`. It's the kernel mode VT emulators I am replacing 
> > > > > with the
> > > > > user mode terminal emulators (running under a fullscreen Wayland 
> > > > > compositor)
> > > > 
> > > > Hi,
> > > > 
> > > > I'm trying to clarify things for everyone here, since I think I can
> > > > guess what you want to achieve, but you have a hard time explaining
> > > > your original goal. I hope you don't mind.
> > > > 
> > > > 
> > > That's fine. Thanks!  
> > > > Starting from the outermost "layer" and going inwards:
> > > > 
> > > > 1.a Have a system service, that takes over VT 1, changes user to
> > > > 'vtty', and runs 'cage' which is a Wayland compositor, mostly
> > > > unprivileged.
> > > > 
> > > > OR
> > > > 
> > > > 1.b Have a system service, that takes over a seat directly, as the
> > > > kernel has the VT system disabled (or the seat is not seat0).
> > > > Changes user to 'vtty' and runs 'cage' mostly unprivileged.
> > > > 
> > > > 
> > > > 2. Inside cage, you run a Wayland terminal emulator as user 'vtty',
> > > >so mostly unprivileged. The terminal emulator creates a PTY.
> > > > 
> > > > 3. Inside that terminal emulator, that is, connecting to that PTY,
> > > >you want to be able log in with any user. Therefore the program
> > > >running on the PTY should present a login prompt and succeed
> > > >in logging a user in and setting up his session, and switching
> > > >to a shell running as that user.
> > > > 
> > > > All in all, this stack would replace the usual stack where
> > > > /bin/login runs directly on the TTY of a VT, allowing to use a more
> > > > featureful terminal, custom display modes, multi-output support,
> > > > maybe multiple parallel sessions for different users a la fast user
> > > > switching, and more.
> > > > 
> > > 
> > > Not to mention, getting Shift+PgUp back, (and now on multiseat systems,
> > > keyboard input from non-seat0 seats will no longer bleed into seat0 when 
> > > VT 1-6
> > > are active) :)  
> > > > Am I guessing right?
> > > 
> > > You are guessing correct. Thanks!  
> > > > 
> > > > Then the question is, how to organize all this so that it works,
> > > > and what program(s) should be used in step 3, and how?
> > > > 
> > > > 
> > > > My own proposal for this would be to run everything as systemd
> > > > system services:
> > > > 
> > > > 1. Cage runs as a system service, as user 'vtty'. Cage will require
> > > >systemd integration so that it can tell systemd when it is ready
> > > >to accept Wayland clients.
> > > > 
> > > > 2. The Wayland terminal runs as another systemd system service,
> > > >depending on the cage service, as user 'vtty'.
> > > > 
> > > That's close to what I was trying, but cage is pretty cool in this 
> > > regard, you
> > > can start
> > > cage -- vte
> > > and cage starts VTE as its only client, so the complexity of starting the
> > > wayland client externally, don't have to worry about that.  
> > 
> > But if cage starts the terminal, then systemd does not know when
> > the terminal is ready to accept a login program, or is there a way
> > to watch PTYs?
> > 
> > Ideally the terminal too would integrate with systemd start-up
> > notification IPC. Perhaps let systemd control which PTY to use, so
> > the login program/service knows to connect to the right one.
> > 
> > There's also auto-respawn, shutdown, cgroups, and more that systemd
> > can do.
> >   
> > > > 3. The login program runs as a third systemd system service,
> >

Re: [systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators

[Pekka Paalanen]

On Sat, 22 May 2021 09:04:42 -0400
nerdopolis  wrote:

> On Saturday, May 22, 2021 6:50:09 AM EDT Pekka Paalanen wrote:
> > On Fri, 21 May 2021 21:29:09 -0400
> > nerdopolis  wrote:
> >   
> > > Sorry, I got the terminology mixed up again. I am still using TTYs to run 
> > > the
> > > instances of `cage`. It's the kernel mode VT emulators I am replacing 
> > > with the
> > > user mode terminal emulators (running under a fullscreen Wayland 
> > > compositor)  
> > 
> > Hi,
> > 
> > I'm trying to clarify things for everyone here, since I think I can
> > guess what you want to achieve, but you have a hard time explaining
> > your original goal. I hope you don't mind.
> > 
> >   
> That's fine. Thanks!
> > Starting from the outermost "layer" and going inwards:
> > 
> > 1.a Have a system service, that takes over VT 1, changes user to
> > 'vtty', and runs 'cage' which is a Wayland compositor, mostly
> > unprivileged.
> > 
> > OR
> > 
> > 1.b Have a system service, that takes over a seat directly, as the
> > kernel has the VT system disabled (or the seat is not seat0).
> > Changes user to 'vtty' and runs 'cage' mostly unprivileged.
> > 
> > 
> > 2. Inside cage, you run a Wayland terminal emulator as user 'vtty',
> >so mostly unprivileged. The terminal emulator creates a PTY.
> > 
> > 3. Inside that terminal emulator, that is, connecting to that PTY,
> >you want to be able log in with any user. Therefore the program
> >running on the PTY should present a login prompt and succeed
> >in logging a user in and setting up his session, and switching
> >to a shell running as that user.
> > 
> > All in all, this stack would replace the usual stack where
> > /bin/login runs directly on the TTY of a VT, allowing to use a more
> > featureful terminal, custom display modes, multi-output support,
> > maybe multiple parallel sessions for different users a la fast user
> > switching, and more.
> >   
> 
> Not to mention, getting Shift+PgUp back, (and now on multiseat systems,
> keyboard input from non-seat0 seats will no longer bleed into seat0 when VT 
> 1-6
> are active) :)
> > Am I guessing right?  
> 
> You are guessing correct. Thanks!
> > 
> > Then the question is, how to organize all this so that it works,
> > and what program(s) should be used in step 3, and how?
> > 
> > 
> > My own proposal for this would be to run everything as systemd
> > system services:
> > 
> > 1. Cage runs as a system service, as user 'vtty'. Cage will require
> >systemd integration so that it can tell systemd when it is ready
> >to accept Wayland clients.
> > 
> > 2. The Wayland terminal runs as another systemd system service,
> >depending on the cage service, as user 'vtty'.
> >   
> That's close to what I was trying, but cage is pretty cool in this regard, you
> can start
> cage -- vte
> and cage starts VTE as its only client, so the complexity of starting the
> wayland client externally, don't have to worry about that.

But if cage starts the terminal, then systemd does not know when
the terminal is ready to accept a login program, or is there a way
to watch PTYs?

Ideally the terminal too would integrate with systemd start-up
notification IPC. Perhaps let systemd control which PTY to use, so
the login program/service knows to connect to the right one.

There's also auto-respawn, shutdown, cgroups, and more that systemd
can do.

> > 3. The login program runs as a third systemd system service,
> >depending on the terminal service, as user 'root' because it
> >needs to be able log in a user and set up a session for them.
> > 
> > That would solve the problem of how to get the necessary privileges
> > to log in a user, but all the other details I'm not sure.
> >   
> That's what I was aiming to do, wasn't sure how to connect to the service 
> until
> I found I can do that with socat a few days after I sent that first email to 
> the list, but I still feel I should still clarify here.

The socat thing for "connection" sounds quite wild to me. Instead,
I would expect to start a login program with the PTY as its std
in/out/err, just like it works with normal VT TTY logins.

But then you do need to know which PTY it is. I think it would be
best to configure that as the parameter for templatated systemd
units: the terminal unit gets the PTY to listen on, and the login
unit gets the PTY to use as its controlling terminal and std
in/out/err. And the dependency between the two.

One problem here 

Re: [systemd-devel] Running pam-enabled /bin/login sessions in unprivileged terminal emulators

[Pekka Paalanen]

On Fri, 21 May 2021 21:29:09 -0400
nerdopolis  wrote:

> Sorry, I got the terminology mixed up again. I am still using TTYs to run the
> instances of `cage`. It's the kernel mode VT emulators I am replacing with the
> user mode terminal emulators (running under a fullscreen Wayland compositor)

Hi,

I'm trying to clarify things for everyone here, since I think I can
guess what you want to achieve, but you have a hard time explaining
your original goal. I hope you don't mind.


Starting from the outermost "layer" and going inwards:

1.a Have a system service, that takes over VT 1, changes user to
'vtty', and runs 'cage' which is a Wayland compositor, mostly
unprivileged.

OR

1.b Have a system service, that takes over a seat directly, as the
kernel has the VT system disabled (or the seat is not seat0).
Changes user to 'vtty' and runs 'cage' mostly unprivileged.


2. Inside cage, you run a Wayland terminal emulator as user 'vtty',
   so mostly unprivileged. The terminal emulator creates a PTY.

3. Inside that terminal emulator, that is, connecting to that PTY,
   you want to be able log in with any user. Therefore the program
   running on the PTY should present a login prompt and succeed
   in logging a user in and setting up his session, and switching
   to a shell running as that user.

All in all, this stack would replace the usual stack where
/bin/login runs directly on the TTY of a VT, allowing to use a more
featureful terminal, custom display modes, multi-output support,
maybe multiple parallel sessions for different users a la fast user
switching, and more.

Am I guessing right?

Then the question is, how to organize all this so that it works,
and what program(s) should be used in step 3, and how?


My own proposal for this would be to run everything as systemd
system services:

1. Cage runs as a system service, as user 'vtty'. Cage will require
   systemd integration so that it can tell systemd when it is ready
   to accept Wayland clients.

2. The Wayland terminal runs as another systemd system service,
   depending on the cage service, as user 'vtty'.

3. The login program runs as a third systemd system service,
   depending on the terminal service, as user 'root' because it
   needs to be able log in a user and set up a session for them.

That would solve the problem of how to get the necessary privileges
to log in a user, but all the other details I'm not sure.

So the main idea here is to not run /bin/login *under* the terminal
emulator or cage, but as a system service which just connects to the
right PTY. I guess it would be like running /bin/login for a serial
terminal, it just connects to ttyS1 or whatever instead of tty1.

Would that work?


Thanks,
pq


pgp164ZX8Vn0X.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Design patterns for privilege separating systemd services?

[Pekka Paalanen]

On Thu, 18 Feb 2021 17:01:10 -0500
"Colin Walters"  wrote:

> The thing I mainly like about socketpair() is that I know it's *only*
> accessible via the fd - it's
> https://en.wikipedia.org/wiki/Capability-based_security - except
> Linux has kind of broken that by creating /proc/N/fd anyways.  So
> relying on unlinking the socket seems fine, it's easy code to write
> and verify.

Hi,

I don't think the /proc breaks this aspect of security, because looking
at a process that uses sockets, those symlinks are broken. For Weston:

$ ls -lh /proc/31229/fd
total 0
lrwx-- 1 pq pq 64 Feb 19 09:49 0 -> /dev/pts/5
lrwx-- 1 pq pq 64 Feb 19 09:49 1 -> /dev/pts/5
lrwx-- 1 pq pq 64 Feb 19 09:49 10 -> 'socket:[49705213]'
lrwx-- 1 pq pq 64 Feb 19 09:49 11 -> /dev/dri/card0
lrwx-- 1 pq pq 64 Feb 19 09:49 12 -> /dev/dri/card0
lrwx-- 1 pq pq 64 Feb 19 09:49 13 -> '/memfd:weston-shared (deleted)'
lrwx-- 1 pq pq 64 Feb 19 09:49 14 -> 'socket:[49705213]'
lrwx-- 1 pq pq 64 Feb 19 09:49 15 -> /run/user/1000/wayland-1.lock
lrwx-- 1 pq pq 64 Feb 19 09:49 16 -> 'socket:[49705227]'
lrwx-- 1 pq pq 64 Feb 19 09:49 17 -> 'socket:[49705227]'
lrwx-- 1 pq pq 64 Feb 19 09:49 18 -> 'socket:[49705229]'
lrwx-- 1 pq pq 64 Feb 19 09:49 19 -> 'socket:[49705229]'
lrwx-- 1 pq pq 64 Feb 19 09:49 2 -> /dev/pts/5
lrwx-- 1 pq pq 64 Feb 19 09:49 20 -> 'socket:[49703721]'
lrwx-- 1 pq pq 64 Feb 19 09:49 21 -> 'socket:[49703722]'
lrwx-- 1 pq pq 64 Feb 19 09:49 22 -> 'socket:[49703721]'
lrwx-- 1 pq pq 64 Feb 19 09:49 23 -> 'socket:[49703722]'
lrwx-- 1 pq pq 64 Feb 19 09:49 24 -> 'anon_inode:[signalfd]'
lrwx-- 1 pq pq 64 Feb 19 09:49 25 -> 'socket:[49703723]'
lrwx-- 1 pq pq 64 Feb 19 09:49 26 -> 'socket:[49703723]'
lr-x-- 1 pq pq 64 Feb 19 09:49 27 -> anon_inode:sync_file
lr-x-- 1 pq pq 64 Feb 19 09:49 28 -> anon_inode:sync_file
l-wx-- 1 pq pq 64 Feb 19 09:49 3 -> /home/pq/.fluxbox/fluxbox.log
lrwx-- 1 pq pq 64 Feb 19 09:49 4 -> 'anon_inode:[eventpoll]'
lrwx-- 1 pq pq 64 Feb 19 09:49 5 -> 'anon_inode:[signalfd]'
lrwx-- 1 pq pq 64 Feb 19 09:49 6 -> 'anon_inode:[signalfd]'

$ cat /proc/31229/fd/16
cat: /proc/31229/fd/16: No such device or address

Or is there some trick one can use to actually open the fds listed
instead of opening what the link points to (which may not exist in the
file system, hence fails)?


Thanks,
pq


pgpWFWZrBHrpM.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] What exactly is multi-seat? -- questions about logind

[Pekka Paalanen]

On Tue, 26 Jan 2021 11:40:31 -0800
Kian Kasad  wrote:

> On 21/01/26 02:06PM, Pekka Paalanen wrote:
> > On Tue, 26 Jan 2021 01:43:43 -0800
> > Kian Kasad  wrote:
> >   
> > > Hi all,
> > > 
> > > After reading the documentation on logind and multi-seat (specifically
> > > sd-login(3) and "Multi-Seat on Linux"), I still have some questions.
> > > 
> > > First of all, what exactly is multi-seat? Does it just mean allowing
> > > multiple sessions to be running at once, like for multiple users to be
> > > logged into the same desktop, even though only one will be in use at a
> > > time?
> > > 
> > > Second, why is logind needed for this? Is it not possible to do without
> > > logind? I've run Xorg perfectly fine on systems without logind/systemd,
> > > so is logind only needed for multiple sessions at once? Is it just to
> > > handle the graphical device(s)?
> > > 
> > > Third, is multi-seat possible at all without logind? 
> > > 
> > > Most of these questions arose because my main OS, Artix Linux, requires
> > > logind (in the form of elogind) for Xorg, but I know that Xorg runs just
> > > fine on Alpine Linux, which does not use logind at all.  
> > 
> > Hi,
> > 
> > I've heard good words of https://sr.ht/~kennylevinsen/seatd/ although I
> > haven't tried to use it myself. One more way to handle multiseat - to
> > bind them all.  
> 
> I'll write this one down. I'm not looking for alternatives currently, I
> was just confused about the purpose.
> 
> > IOW, there are many ways to achieve coordination between multiple
> > sessions and one or multiple physical seats, like the Linux virtual
> > terminal system that requires root permissions, ioctl and signal magic
> > to let things cooperate (and if things do not explicitly cooperate
> > correctly, it fails horribly) and does not support multiseat. But if
> > you want your program to not need root permissions, have a graceful
> > failure if it crashes, not accidentally hijack the seat by mistake, or
> > just support multiseat, you kind of need to have a system daemon
> > orchestrating things.
> > 
> > Logind is one of those possible system daemons. It tells your program
> > when it is active. It grants access to graphics and input devices
> > without your program needing root permissions. It also takes graphics
> > and input devices away from your program when deactivated, so you can't
> > e.g. spy on other programs' input. It takes care of the arcane magic of
> > setting up the VT and tty and restoring them. And more.
> > 
> > "Your program" here is Xorg, for instance. Or one of the Wayland
> > compositors.  
> 
> Thank you! This is exactly the explanation I was looking for. I didn't
> get why a daemon was needed if programs (like Xorg) can handle the
> devices on their own, but now I see it's to allow multiple Xorg/Wayland
> sessions to run, all without needing SUID.

I would like to underline the crash handling too. Getting the VT
switching dance right is really tricky and depends on *both* programs,
the one switching out and the one switching in. If something goes wrong
with the VT switching dance, or the program currently active on the
default seat crashes, the chances are really high that the user is
staring at a frozen screen with his keyboard doing seemingly nothing.
The realistic end user options at that point are pressing the power
button or logging in via ssh to reboot the machine.

If all the tricky things are delegated to a system daemon that is
shared by all VT using sessions, getting the VT magic right is both
easier and needs to be implemented in just one place. The daemon can
also restore the VT in case the program using the VT crashes, or it can
switch to the graphical login manager *successfully*. The kernel does
not automatically restore the VT so that the user could regain control
of his machine.


Thanks,
pq


pgp92sDOzqsXz.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] What exactly is multi-seat? -- questions about logind

[Pekka Paalanen]

On Tue, 26 Jan 2021 01:43:43 -0800
Kian Kasad  wrote:

> Hi all,
> 
> After reading the documentation on logind and multi-seat (specifically
> sd-login(3) and "Multi-Seat on Linux"), I still have some questions.
> 
> First of all, what exactly is multi-seat? Does it just mean allowing
> multiple sessions to be running at once, like for multiple users to be
> logged into the same desktop, even though only one will be in use at a
> time?
> 
> Second, why is logind needed for this? Is it not possible to do without
> logind? I've run Xorg perfectly fine on systems without logind/systemd,
> so is logind only needed for multiple sessions at once? Is it just to
> handle the graphical device(s)?
> 
> Third, is multi-seat possible at all without logind? 
> 
> Most of these questions arose because my main OS, Artix Linux, requires
> logind (in the form of elogind) for Xorg, but I know that Xorg runs just
> fine on Alpine Linux, which does not use logind at all.

Hi,

I've heard good words of https://sr.ht/~kennylevinsen/seatd/ although I
haven't tried to use it myself. One more way to handle multiseat - to
bind them all.

IOW, there are many ways to achieve coordination between multiple
sessions and one or multiple physical seats, like the Linux virtual
terminal system that requires root permissions, ioctl and signal magic
to let things cooperate (and if things do not explicitly cooperate
correctly, it fails horribly) and does not support multiseat. But if
you want your program to not need root permissions, have a graceful
failure if it crashes, not accidentally hijack the seat by mistake, or
just support multiseat, you kind of need to have a system daemon
orchestrating things.

Logind is one of those possible system daemons. It tells your program
when it is active. It grants access to graphics and input devices
without your program needing root permissions. It also takes graphics
and input devices away from your program when deactivated, so you can't
e.g. spy on other programs' input. It takes care of the arcane magic of
setting up the VT and tty and restoring them. And more.

"Your program" here is Xorg, for instance. Or one of the Wayland
compositors.


Thanks,
pq


pgpcp0meN_LBT.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] DisplayPort display non-persistent device naming

[Pekka Paalanen]

On Thu, 29 Oct 2020 21:53:34 +0100
Marcin Kocur  wrote:

> Hello,
> 
> this is the output of turning off and on my display (using power button):

...

> The monitor was visible in xrandr as DP-2, after power off and on it's 
> visible as DP-3 (DP-2 is still there "disconnected").
> 
> It's troublesome for:
> 
> - GUI display configurators
> 
> - scripting
> 
> - for Xorg configuration which stops to work:
> 
> Section "Monitor"
>      Identifier  "DP-2"
>      Option  "Primary" "true"
> EndSection
> 
> Is this a bug or a feature?

Hi,

this is how the kernel DRM sub-system works. The connector names are
not persistent in general, just like you can't expect that the same gfx
card appears always at the same /dev/dri/cardN node if you have
several. By default, cardN nodes are assigned in the order of which
driver instance happens to initialize first and it can be random.

Usually hard-wired (in hardware) connectors just happen to always be
discovered in the same order, and if you only have a single gfx card in
your machine, the connector naming is practically persistent. This is
an accident. It is not guaranteed if you have multiple cards or you
have MST connectors.

MST connectors can appear and disappear dynamically. There is a KMS
property that attempts to reflect something about the MST topology so
that you might have some hope to match a "connector", but this is not
in the connector name. The concept of a persistent connector is
problematic if the connector is in a MST monitor for daisy-chaining
more monitors - you can always unplug the first monitor making the
connector disappear (not just become disconnected).

If you want reliable monitor matching, monitor serial number (if
present) would be a more reliable method. I'm not sure Xorg config has
matching rules for that though, but I suppose RandR based configuration
utilities could do it.

If you want to discuss this further, dri-devel mailing list is the
place - Cc'd. Nothing to do with systemd here, nor even with udev.


Thanks,
pq


pgpYUUGGI7_IT.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Which udev action is run on boot for my device?

[Pekka Paalanen]

On Sun, 25 Oct 2020 18:36:42 +0100
Marcin Kocur  wrote:

> Hello,
> 
> as the topic states, I want to know which action(s) from "add", 
> "remove", "change", "move", "online", "offline", "bind", and "unbind" 
> were triggered on my device. Is there any way to check that?
> 
> At the beginning of  /usr/lib/udev/rules.d/49-sane.rules there is:
> 
> ACTION!="add", GOTO="libsane_rules_end"
> 
> Udevadm info doesn't show libsane_matched property for my scanner.
> 
> If I trigger the device manually with action "change", the variable is 
> still not there, as per the rule.
> 
> But if I trigger it with "add", the variable is there and also uaccess 
> rule gets executed.
> 
> So the ultimate quesiton is: what kind of trigger was executed on my 
> device on boot time?
> 

Hi,

FWIW, I was totally baffled by a similar problem with a DRM device. My
rule was doing the same thing: match to "add" and skip otherwise. My
rule did not appear to take effect at boot.

The problem was not that "add" was not emitted - it was and processed
with my rule. The problem was that the DRM driver then shortly after
emitted also "changed" (this is how DRM communicates monitor hotplug
events). Because my rule did not match "change", the udev property I
was adding was effectively *removed*. IOW, any monitor hotplug would
cause my udev setting to disappear.

Therefore I concluded that if you want your rule to apply always (e.g.
set a property that you expect to always find on the device), do not
filter it with ACTION at all. New actions could be added any time, and
then your rule breaks. At most, maybe it is safe to skip if
ACTION=="remove", but I'm not sure about even that.

The way I figured this out was adding udev.log_priority=debug to the
kernel command line and looking at the resulting flood in the system
log.


Thanks,
pq


pgpdifiZYTX1J.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Logind: how to access a device when you're not the session controller

[Pekka Paalanen]

On Mon, 7 Sep 2020 17:53:46 +0200
Lennart Poettering  wrote:

> On Mo, 07.09.20 11:47, Pekka Paalanen (ppaala...@gmail.com) wrote:
> 
> > > I am not aware of any.
> > >  
> > > > Any suggestions on what might work?  
> > >
> > > Other than patching logind with some new concept, no suggestion. Or
> > > simply bypassing logind and opening the devices directly with root
> > > privs? or test this in virtualization?  
> >
> > Thanks for the reply!
> >
> > That's a little inconvenient. I was hoping there might be a way
> > somehow, perhaps even create a new session and become its controller
> > without elevated privileges if the the seat in question is not "in
> > use". I could configure the extra DRM device into a non-default seat,
> > then try taking over that seat.  
> 
> You could open a new PAM session with "systemd-run -p PAMName=", and
> configure the seat for it via the XDG_SEAT env var. pam_systemd picks
> up the seat to use via XDG_SEAT env var.
> 
> (but it will require privs to run systemd-run)

Thanks, I'll keep that in mind. Going through logind will exercise the
logind-only code in Weston, and sometimes that is good to test. OTOH, I
can VT-switch to an unused tty and run Weston like normal. It's all
about convenience, particularly with 'git rebase -i --exec' to run
tests every commit.

> > Is that really not possible without some kind of elevated privileges my
> > normal desktop user doesn't usually have? Could it be allowed via
> > polkit configuration or something?
> >
> > Or maybe I indeed need to forget about logind and open the DRM device
> > as a normal user. After all, the first one to open a DRM device should
> > automatically gain DRM master status, and there have been recent kernel
> > patches to even allow dropping and re-gaining DRM master status without
> > being root/CAP_SYS_ADMIN IIUC. That won't help with input devices if I
> > wanted to test anything interactive... but maybe I could allow some
> > dedicated input devices to be opened by my normal user and make sure I
> > don't use those for my desktop.
> >
> > Right, maybe I can hack it up after forgetting about logind. Put all
> > those devices into a non-default seat, override their file permissions,
> > and assume they are untrusted (can be eavesdropped).  
> 
> Note that I myself never worked on a wayland compositor or suchlike, I
> have no experience with your perspective on these things: we look at
> this from the other side...

Appreciated. My use cases are all about developer testing, so they may
be fine as hacks. There are more use cases:
https://gitlab.freedesktop.org/wayland/weston/-/issues/132
https://gitlab.freedesktop.org/wayland/weston/-/issues/401
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/438

Starting Weston via ssh is something developers use for testing on
embedded boards. Sounds like starting Weston in a container is also a
new developer use case. There exists curiosity towards CONFIG_VT=n
systems too.

This is for your information just in case you or someone might find it
interesting. If not, no worries.


Thanks,
pq


pgpMbczLgPWmA.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Logind: how to access a device when you're not the session controller

[Pekka Paalanen]

On Fri, 4 Sep 2020 16:40:00 +0200
Lennart Poettering  wrote:

> On Di, 26.05.20 16:55, Pekka Paalanen (ppaala...@gmail.com) wrote:
> 
> > Hi,
> >
> > I'm looking at letting Weston's 'meson test' run DRM-backend tests
> > automatically and without the need of root privileges. I have a spare
> > DRM device in my machine that is dedicated for this purpose, so I make
> > my normal desktop environment not touch it. My problem is, is there any
> > way to set up things so that logind would give Weston access to that
> > DRM device while my normal desktop is active?  
> 
> I am not aware of any.
> 
> > Any suggestions on what might work?  
> 
> Other than patching logind with some new concept, no suggestion. Or
> simply bypassing logind and opening the devices directly with root
> privs? or test this in virtualization?

Thanks for the reply!

That's a little inconvenient. I was hoping there might be a way
somehow, perhaps even create a new session and become its controller
without elevated privileges if the the seat in question is not "in
use". I could configure the extra DRM device into a non-default seat,
then try taking over that seat.

Is that really not possible without some kind of elevated privileges my
normal desktop user doesn't usually have? Could it be allowed via
polkit configuration or something?

Or maybe I indeed need to forget about logind and open the DRM device
as a normal user. After all, the first one to open a DRM device should
automatically gain DRM master status, and there have been recent kernel
patches to even allow dropping and re-gaining DRM master status without
being root/CAP_SYS_ADMIN IIUC. That won't help with input devices if I
wanted to test anything interactive... but maybe I could allow some
dedicated input devices to be opened by my normal user and make sure I
don't use those for my desktop.

Right, maybe I can hack it up after forgetting about logind. Put all
those devices into a non-default seat, override their file permissions,
and assume they are untrusted (can be eavesdropped).


Thanks,
pq


pgpOfuaHcpqmP.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Journal message timestamps

[Pekka Paalanen]

On Thu, 27 Aug 2020 11:33:04 +0100
Mark Corbin  wrote:

> Hello
> 
> I am working on time synchronisation issues at boot for systems without 
> an RTC (using balenaOS on a Raspberry Pi 3) and have some questions 
> about how journald assigns timestamps to log messages.
> 
> When I boot my system and look at the journal I see an initial date/time 
> for kernel messages, e.g. '1 June 2020 10:00:00' followed by messages 
> with the 'correct' date/time once the system time has been set from 
> another source, e.g. build time, NTP, etc. This means that over several 
> reboots I have lots of sets of log messages from 1 June 2020 which 
> understandably confuses the 'journalctl --list-boots' command. I found 
> an issue that describes the problem here 
> https://github.com/systemd/systemd/issues/662 and had assumed that there 
> wasn't anything I could do about this.

...

> Any general details about how journald applies timestamps would also be 
> greatly appreciated.

Hi,

I'm not sure if this is relevant to you, but I have encountered a
different issue that causes journald to lose track of boots and
therefore the message ordering becomes useless: boot_id not
changing on reboot. More info at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963977

The messages still show up with the right wall-clock time (once
the clock is set), they are just ordered badly: it is as if the
wall-clock time would be jumping forward and backward days, weeks or
months randomly.


Thanks,
pq


pgpW_pXCb2ewh.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Logind: how to access a device when you're not the session controller

[Pekka Paalanen]

On Tue, 26 May 2020 16:55:19 +0300
Pekka Paalanen  wrote:

> Hi,
> 
> I'm looking at letting Weston's 'meson test' run DRM-backend tests
> automatically and without the need of root privileges. I have a spare
> DRM device in my machine that is dedicated for this purpose, so I make
> my normal desktop environment not touch it. My problem is, is there any
> way to set up things so that logind would give Weston access to that
> DRM device while my normal desktop is active?

Hi,

is there a more appropriate forum for logind questions?


Thanks,
pq


pgpTPPBg4t1m9.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Logind: how to access a device when you're not the session controller

[Pekka Paalanen]

Hi,

I'm looking at letting Weston's 'meson test' run DRM-backend tests
automatically and without the need of root privileges. I have a spare
DRM device in my machine that is dedicated for this purpose, so I make
my normal desktop environment not touch it. My problem is, is there any
way to set up things so that logind would give Weston access to that
DRM device while my normal desktop is active?

I can keep the spare DRM device in the default seat, or I can assign it
to a seat of its own.

If I assign it to a seat of its own, I don't know how to tell logind
that, from within my current session on the default seat, I would like
to take over the other seat as well, but from a different process.

If I keep the spare DRM device on the default seat, I think logind
wouldn't give Weston access, because it is not the session controller.
My normal desktop environment has the session control.

I have a feeling that I'm trying to do things backwards: that seats
spawn sessions on them, and not sessions taking over seats.

Any suggestions on what might work?

I thought that assigning the spare DRM device to a non-default seat
would implicitly make everything work: my normal desktop automatically
ignores it, the Weston test won't attempt to open my input devices
since those are all in the default seat, I don't have to point weston
to a specific device but just the seat, using non-default seat implies
not touching anything about VTs so no special-casing those, and logind
would let me run as a normal user. Too good to be true?

If I can't make logind work, my fallback plan is to use Weston's
launcher-direct, which will attempt to open the DRM device directly.
For that, I need to change the device node permissions, and modify
launcher-direct to work as non-root, without touching any VT stuff, and
never get/drop DRM master.


Thanks,
pq


pgprvlOe0Ud4z.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] All non-seat0 input devices leak into VT if no display server on seat0

[Pekka Paalanen]

On Thu, 9 Apr 2020 13:01:56 +0200
Michał Zegan  wrote:

> W dniu 09.04.2020 o 10:23, Pekka Paalanen pisze:
> > On Thu, 9 Apr 2020 09:46:08 +0200
> > Lennart Poettering  wrote:
> >   
> >> On Fr, 03.04.20 10:28, Pekka Paalanen (ppaala...@gmail.com) wrote:
> >>  
> >>>> My (maybe bad) guess is that it would need to be addressed in the kernel 
> >>>> though
> >>>> And the CanMultiSession attribute on non-seat0 doesn't matter when the 
> >>>> problem
> >>>> is all input from all devices gets sent to seat0 when seat0 is in a text 
> >>>> mode
> >>>> TTY
> >>>>
> >>>> ..and even if you have some kmscon like thing installed, there could 
> >>>> still be
> >>>> text mode TTYs
> >>>
> >>> Hi,
> >>>
> >>> that is both an excellent and horrifying observation. And it makes
> >>> perfect sense to me why that happens, just like you think: seat
> >>> assignments happen in userspace as udev properties. Someone would have
> >>> to explicitly tell the kernel about it too to fix this, e.g. remove
> >>> non-seat0 devices from the VT machinery.
> >>>
> >>> I wonder if such kernel interface even exists?
> >>
> >> There are ioctls for that in the input layer if iirc, but i don't
> >> remember how precisely this works. You are hacking on a compositor, you
> >> should know ;-)  
> > 
> > Hi,
> > 
> > while hacking on a compositor, I have never needed to stop specific
> > input devices from being routed to the VT system while allowing others.
> > If a compositor runs on seat0, it will disable the whole VT input side
> > (among other things) with one VT ioctl IIRC. In this case that is not
> > wanted, because seat0 is intended to be used with the VT text mode and
> > VT input, so disabling all VT input would stop also the wanted input.  
> Not sure if it's related and I don't know details, but some software
> like brltty or a fenrir console screenreader are routinely taking
> control over single input devices in text mode. The whole point is that
> they take control over all real keyboards, and have some uinput device
> that is still wired to vt, so that I can send keypresses not supported
> by terminals like insert+something, and these that do not map to
> screenreader would be injected to the uinput and appear on vt.
> I thought display servers also take exclusive control over specific
> input devices... hmm. If they do then this behavior should likely not be
> happening as they still are in control of the devices.

Hi,

I have heard of the evdev grab ioctl, which does pretty much what you
describe. I seem to recall there to be a reason why display servers
should not use it, but I have forgot. Maybe it is exactly because of
the kind of use cases you describe though: some special software that
wants to intercept some very specific input devices. If the display
server itself used that same mechanism, then the special software
cannot do its job.

Peter, would you know?


Thanks,
pq

> > 
> > Also a display server that runs on non-seat0 seat should never touch
> > anything about VTs AFAIU. I would expect it to not have the permissions
> > to do that even if it wanted to.
> > 
> > Like you said it being a kernel or logind bug, this is something that
> > needs to be taken care of below the compositor, automatically keyed by
> > the input device seat assignments.
> > 
> > 
> > Thanks,
> > pq


pgpSiq4hogvC5.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] The meaning of CanMultiSession=no on non-seat0

[Pekka Paalanen]

On Thu, 9 Apr 2020 09:46:08 +0200
Lennart Poettering  wrote:

> On Fr, 03.04.20 10:28, Pekka Paalanen (ppaala...@gmail.com) wrote:
> 
> > > My (maybe bad) guess is that it would need to be addressed in the kernel 
> > > though
> > > And the CanMultiSession attribute on non-seat0 doesn't matter when the 
> > > problem
> > > is all input from all devices gets sent to seat0 when seat0 is in a text 
> > > mode
> > > TTY
> > >
> > > ..and even if you have some kmscon like thing installed, there could 
> > > still be
> > > text mode TTYs  
> >
> > Hi,
> >
> > that is both an excellent and horrifying observation. And it makes
> > perfect sense to me why that happens, just like you think: seat
> > assignments happen in userspace as udev properties. Someone would have
> > to explicitly tell the kernel about it too to fix this, e.g. remove
> > non-seat0 devices from the VT machinery.
> >
> > I wonder if such kernel interface even exists?  
> 
> There are ioctls for that in the input layer if iirc, but i don't
> remember how precisely this works. You are hacking on a compositor, you
> should know ;-)

Hi,

while hacking on a compositor, I have never needed to stop specific
input devices from being routed to the VT system while allowing others.
If a compositor runs on seat0, it will disable the whole VT input side
(among other things) with one VT ioctl IIRC. In this case that is not
wanted, because seat0 is intended to be used with the VT text mode and
VT input, so disabling all VT input would stop also the wanted input.

Also a display server that runs on non-seat0 seat should never touch
anything about VTs AFAIU. I would expect it to not have the permissions
to do that even if it wanted to.

Like you said it being a kernel or logind bug, this is something that
needs to be taken care of below the compositor, automatically keyed by
the input device seat assignments.


Thanks,
pq


pgpuxzIOa4N0o.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] All non-seat0 input devices leak into VT if no display server on seat0

[Pekka Paalanen]

On Tue, 07 Apr 2020 23:03:52 -0400
nerdopolis  wrote:

> On Friday, April 3, 2020 3:28:52 AM EDT Pekka Paalanen wrote:
> > On Thu, 02 Apr 2020 22:59:25 -0400
> > nerdopolis  wrote:
> >   

...

> > > One thing I did notice though is that (as far as leaking input)
> > > 
> > > - if run Display Servers on the secondary seat (one, or more than one)
> > > - On seat0, I chvt to a text-mode TTY
> > > - Continuing to use the secondary seat, all keyboard and mouse (gpm) input
> > >   gets sent to the TTY (and the actual display server)
> > > - Switching back to a TTY with a display server, and the seats behave 
> > > separate
> > >   again
> > > 
> > > 
> > > My (maybe bad) guess is that it would need to be addressed in the kernel 
> > > though
> > > And the CanMultiSession attribute on non-seat0 doesn't matter when the 
> > > problem 
> > > is all input from all devices gets sent to seat0 when seat0 is in a text 
> > > mode
> > > TTY
> > > 
> > > ..and even if you have some kmscon like thing installed, there could 
> > > still be 
> > > text mode TTYs  
> > 
> > Hi,
> > 
> > that is both an excellent and horrifying observation. And it makes
> > perfect sense to me why that happens, just like you think: seat
> > assignments happen in userspace as udev properties. Someone would have
> > to explicitly tell the kernel about it too to fix this, e.g. remove
> > non-seat0 devices from the VT machinery.
> > 
> > I wonder if such kernel interface even exists?
> > 
> > The reason why display servers do not cross their input streams like
> > that is that display servers do not use the VT for input. But VT gets
> > its input assigned directly inside the kernel.
> > 
> > 
> > Thanks,
> > pq  
> Hi
> 
> I'm not sure, but I am not an expert there. haha. However, I am just 
> remembering as far as gpm goes,that one runs in userspace, as root so it's 
> also not obeying seats, but THAT part is not the fault of the kernel. 

Yeah, a program running as root can do whatever it chooses to. So that
part is a GPM bug or lack of configuration, I don't know which.

> Maybe a utility could be made like gpm that grabs the keyboard input, but only
> forwards the keys to the TTY, if the device is in seat0. But like, I am
> guessing here, and I guess it would be a possibility for the hypothetical
> utility to crash, and then all input would get sent to the TTY anyway.

That would seem like strange architecture as the VT is implemented in
the kernel, but you would route the input events through userspace.

Instead of that, I'd promote CONFIG_VT=n and run something like kmscon
to replace the VTs. I expect that to need effort to make work though,
since I haven't heard anything from that direction in years. That is,
disable the kernel VT sub-system completely, and use userspace programs
to offer similar functionality while leveraging logind and other modern
technologies.

But if people want to keep CONFIG_VT=y, then I don't see any other way
than telling the kernel which input devices belong with the VT and
which do not. Perhaps logind should do that.

> So I'm not sure, also should we change the name of the thread since I think my
> original question is answered now?

Done. I hope this attracts more attention.


Thanks,
pq


pgpwLK1k0q3xt.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] The meaning of CanMultiSession=no on non-seat0

[Pekka Paalanen]

On Thu, 02 Apr 2020 22:59:25 -0400
nerdopolis  wrote:

> On Tuesday, March 31, 2020 8:59:30 AM EDT Lennart Poettering wrote:
> > On Di, 28.01.20 22:48, nerdopolis (bluescreen_aven...@verizon.net) wrote:
> >   
> > > Hi
> > >
> > > Sorry if this is the wrong place for this. I can't seem to find a 
> > > system-user
> > > mailing list for this purpose on freedesktop.
> > >
> > > So I am curious about what CanMultiSession=no means, as I am able to 
> > > start a
> > > Weston session on a secondary seat (eg seat1 if I set up the hardware 
> > > with udev
> > > or seat-pci-pci-_xx_xx_x if I use pci-bridge-seat devices on QEMU.
> > >
> > > These seats, since they don't have TTYs I guess say CanMultiSession=no 
> > > which is
> > > my understanding, however, I can start a second instance of Weston, and 
> > > switch
> > > in between them fine, and Weston seems to respond to the sessions 
> > > switching, so
> > > I am not quite sure what is missing? Is it something else related to 
> > > security?
> > > Or the kernel?
> > >
> > > Because as far as I can tell, I can start multiple sessions on these 
> > > seats.  
> > 
> > Hmm, so it currently just lets you know if the seat has VTs (which
> > only seat0 has effectively, if the VT subsys is enabled in the
> > kernel).
> > 
> > In the old days we only supported session switching on seat0, since it
> > was based exclusively on VTs. Later on David Hermann added support for
> > session switching without VTs, at which point the boolean was wired to
> > mean "has VTs". Maybe that was a mistake, dunno, and it should just
> > have returned true for all seats at that point...
> > 
> > Lennart
> > 
> > --
> > Lennart Poettering, Berlin
> >   
> Thanks. I was wondering if there was some security thing that depended on TTYs
> for the two Display Servers running on the same seat to truly be secure or 
> not.
> (like reading /dev/input/* )
> 
> If you don't need TTYs to prevent the non-seat0 session from reading input 
> from
> the other non-seat0 session, the same as on seat0, then yeah, as I've been 
> able
> to run and switch between two sessions on non-seat0 since I first tried it in 
> 2017...
> 
> 
> 
> One thing I did notice though is that (as far as leaking input)
> 
> - if run Display Servers on the secondary seat (one, or more than one)
> - On seat0, I chvt to a text-mode TTY
> - Continuing to use the secondary seat, all keyboard and mouse (gpm) input
>   gets sent to the TTY (and the actual display server)
> - Switching back to a TTY with a display server, and the seats behave separate
>   again
> 
> 
> My (maybe bad) guess is that it would need to be addressed in the kernel 
> though
> And the CanMultiSession attribute on non-seat0 doesn't matter when the 
> problem 
> is all input from all devices gets sent to seat0 when seat0 is in a text mode
> TTY
> 
> ..and even if you have some kmscon like thing installed, there could still be 
> text mode TTYs

Hi,

that is both an excellent and horrifying observation. And it makes
perfect sense to me why that happens, just like you think: seat
assignments happen in userspace as udev properties. Someone would have
to explicitly tell the kernel about it too to fix this, e.g. remove
non-seat0 devices from the VT machinery.

I wonder if such kernel interface even exists?

The reason why display servers do not cross their input streams like
that is that display servers do not use the VT for input. But VT gets
its input assigned directly inside the kernel.


Thanks,
pq


pgpmubB9uXJ6V.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

[Pekka Paalanen]

On Thu, 2 Apr 2020 10:08:06 +0200
Lennart Poettering  wrote:

> On Do, 02.04.20 10:35, Pekka Paalanen (ppaala...@gmail.com) wrote:
> 
> > > I don't think you need to wait for CanGraphical. I mean, the value of
> > > that field just reflects whether at least one DRM or other graphical
> > > device was discovered associated with the seat.  
> >
> > Hi,
> >
> > what other graphical devices than DRM devices? Or is that for the
> > sysadmin to decide somehow?  
> 
> All devices with the udev tag "master-of-seat" are
> considered. In our default udev rules file that's some select fb
> devices (hyperv, efifb, uvesafb), DRM, parallels
> PCI graphics device. Also any PCI graphics card when the system is
> booted with nomodeset. See 71-seat.rules.
> 
> > > with, and match against the seat id specified. All video/input devices
> > > that make sense to be associated to a seat have ID_SEAT= set to the
> > > seat name, except for those associated with the primary seat (seat0),
> > > which may have the property absent.  
> >
> > That is implemented in Weston already, for both input and DRM
> > devices.  
> 
> Excellent!
> 
> > What is CanGraphical useful for then? I've never really read about it,
> > I only saw the GNOME Mutter MR and assumed it was a good idea.  
> 
> It's more interesting for display managers than for
> compositors. i.e. the idea is "gdm" and such start "gnome-shell" (or
> weston) and such on all seats as soon as CanGraphical is turned on for
> them. gdm should not have understanding about devices, unlike
> gnome-shell/weston. hence we hide the basic understanding in logind
> there.
> 
> Thinking about this: it might make sense to revisit this
> eventually... for example maybe instead of having gdm run all the time
> and just listening to SeatAdded/SeatRemoved and CanGraphical property
> changes and then spawn off a login UI for that seat, maybe we should
> just add this behaviour to logind itself that it can spawn
> compositor@$SEAT.service whenever this happens. That should be easy to
> do and might be interesting for weston-like setups: i.e. you'd just
> symlink the compositor@.service template to weston@.service and then
> weston would get started automatically whenever a graphical seat shows
> up. does that make sense? i kinda like the idea. it would solve all
> your problems too, right?)

Hi,

yeah, that sounds attractive, but it has one problem: the idea of a
usable graphics device might be different between logind and the
compositor, like you explained.

Currently in Weston's case, you have to pick the backend before
launching weston. DRM-backend handles only DRM devices, fbdev-backend
handles only fbdev, and nothing else exists for bare hardware. We would
need to add some detection logic in the Weston frontend for choosing
the right backend. There already is some, but it only applies to
running Weston nested on X11 or Wayland. Not impossible.

It would work for auto-login cases I guess, but I'm not sure about how
well it would serve login managers. Wouldn't a login manager like GDM
be still needed, but instead of listening to SeatAdded/SeatRemoved it
would have to listen to login-UI actions? I'm really not the right
person to evaluate that.


Thanks,
pq


pgpy2WpiAVmhf.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

[Pekka Paalanen]

On Thu, 2 Apr 2020 10:35:49 +0300
Pekka Paalanen  wrote:

> On Wed, 1 Apr 2020 17:09:59 +0200
> Lennart Poettering  wrote:
> 
> > On Mi, 01.04.20 11:34, Pekka Paalanen (ppaala...@gmail.com) wrote:
> >   
> > > > > Is there a way to order a service in such a way, that it’s guaranteed 
> > > > > that
> > > > > udev rules to devices were applied?
> > > > >
> > > > > A small script applying permissions and ownership manually in
> > > > > `ExecStartPre=` seems to work around the (graphics) issue.
> > > > >
> > > > > If it cannot be solved with ordering, what would you suggest?
> > > > >
> > > > > [1]: https://gitlab.freedesktop.org/wayland/weston/issues/382
> > > > > [2]: 
> > > > > https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/kms.c#L741
> > > > > 
> > > >
> > > > Ideally Weston would just wait for devices assigned to the seat it
> > > > shall run on to appear to make this all safe.
> > >
> > > Hi,
> > >
> > > there is an issue open about something like that:
> > > https://gitlab.freedesktop.org/wayland/weston/-/issues/173
> > >
> > > If I understand it right, waiting for CanGraphical allows Weston's
> > > DRM-backend to wait for any DRM device to appear on the seat, so that
> > > you don't need to hardcode in advance which DRM device to depend on.
> > 
> > I don't think you need to wait for CanGraphical. I mean, the value of
> > that field just reflects whether at least one DRM or other graphical
> > device was discovered associated with the seat.  
> 
> Hi,
> 
> what other graphical devices than DRM devices? Or is that for the
> sysadmin to decide somehow?

Actually, seems like using CanGraphical was your idea:
https://gitlab.gnome.org/GNOME/gdm/issues/103

I guess things have changed in 7 years.

> What is CanGraphical useful for then? I've never really read about it,
> I only saw the GNOME Mutter MR and assumed it was a good idea.


Thanks,
pq


pgphYVZQClxYp.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

[Pekka Paalanen]

On Wed, 1 Apr 2020 17:09:59 +0200
Lennart Poettering  wrote:

> On Mi, 01.04.20 11:34, Pekka Paalanen (ppaala...@gmail.com) wrote:
> 
> > > > Is there a way to order a service in such a way, that it’s guaranteed 
> > > > that
> > > > udev rules to devices were applied?
> > > >
> > > > A small script applying permissions and ownership manually in
> > > > `ExecStartPre=` seems to work around the (graphics) issue.
> > > >
> > > > If it cannot be solved with ordering, what would you suggest?
> > > >
> > > > [1]: https://gitlab.freedesktop.org/wayland/weston/issues/382
> > > > [2]: 
> > > > https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/kms.c#L741
> > > >   
> > >
> > > Ideally Weston would just wait for devices assigned to the seat it
> > > shall run on to appear to make this all safe.  
> >
> > Hi,
> >
> > there is an issue open about something like that:
> > https://gitlab.freedesktop.org/wayland/weston/-/issues/173
> >
> > If I understand it right, waiting for CanGraphical allows Weston's
> > DRM-backend to wait for any DRM device to appear on the seat, so that
> > you don't need to hardcode in advance which DRM device to depend on.  
> 
> I don't think you need to wait for CanGraphical. I mean, the value of
> that field just reflects whether at least one DRM or other graphical
> device was discovered associated with the seat.

Hi,

what other graphical devices than DRM devices? Or is that for the
sysadmin to decide somehow?

> But Weston should know
> better what kind of devices it can deal with, hence I'd just subscribe
> to udev events and watch for all drm/fb/… devices Weston can deal

Right. Weston's DRM-backend only works with DRM devices. True, there
exists a fbdev-backend, but it already does not use logind to open the
fbdev device, and is a second class citizen anyway, intentionally left
to rot.

> with, and match against the seat id specified. All video/input devices
> that make sense to be associated to a seat have ID_SEAT= set to the
> seat name, except for those associated with the primary seat (seat0),
> which may have the property absent.

That is implemented in Weston already, for both input and DRM devices.

> Hence, instead of watch CanGraphical, just watch udev, with a match
> for SUBSYSTEM=drm, SUBSYSTEM=input and so on, and then ignoring all
> devices that have ID_SEAT != the seat you are started for, except if
> you are started for seat0 in which case you also use all devices that
> have no ID_SEAT set.

For input devices it already works like this.

> This means that weston might run before any suitable graphics device
> popped up, in which case it should probably just hang in there and
> wait. It might also mean that more than one suitable graphics devices
> show up, in which case it might make sense to merge them somehow,
> either mirroring or expanding the desktop, you probably know better
> what would make sense there...

Sure, although there is no support written to use more than one DRM
device yet. So the first one to appear on a seat is the one whose
outputs will be driven and which is used for GPU compositing.

Once Weston picks a GPU for compositing, it cannot really change that
ever again, because clients (apps) may have started to depend on the
exact choice already. That is a bit unfortunate for any automatic
choosing in a multi-GPU system, I'm not sure what the best way to solve
that would be... Weston can switch from software compositing to GPU
compositing in flight though, so maybe Weston should be made to always
start with software compositing, wait for N seconds, and then switch to
the "best" GPU there is, if any. But then that means that apps started
before the switch are stuck with software rendering, since none of them
handle the GPU support appearing dynamically. Hmm...

> > Weston itself does not know which device it should wait for appearing
> > either, otherwise it could watch udev for it. Or, I guess Weston could
> > wait for any DRM device assigned to the seat, so essentially what
> > CanGraphical does.  
> 
> Exactly, that's what I would find best. I mean it already watches for
> input devices, right? so watching for graphics devices is just a small
> step further.

A small step probably, but not exactly the same, because the compositor
as a whole with DRM-backend cannot initialize without a DRM device.
Yet, at least. Once we implement multi-DRM-KMS-device support, starting
without a KMS device should be ok.

Thanks for the suggestion, I'll change the plans.

What is CanGraphical useful for then? I've never really read about it,
I only saw the GNOME Mutter MR and assumed it was a good idea.


Thanks,
pq


pgppbf6jvOcva.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

[Pekka Paalanen]

On Tue, 31 Mar 2020 17:08:49 +0200
Lennart Poettering  wrote:

> On Do, 19.03.20 17:47, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) 
> wrote:
> 
> > Dear systemd folks,
> >
> >
> > I am using Debian Sid/unstable with systemd 245.2 and Weston 8.0.0.
> >
> > I amtrying to start a graphical desktop as soon as possible. Currently, I
> > use Weston, but unfortunately accessing `/dev/dri/card0` it gets a
> > permission denied error. The Weston service unit is ordered after
> > `systemd-logind.service`.
> >
> > Weston now fails to start, because it gets a permission denied error
> > accessing `/dev/dri/card0` [1][2].
> >
> > drmModeSetCrtc(backend->drm.fd, output->crtc_id,
> > scanout_state->fb->fb_id, 0, 0, connectors, n_conn, >mode_info);
> >
> > Right before Weston starts, the permission and ownership are like below.
> >
> > $ ls -l /dev/dri:
> > insgesamt 0
> > crw--- 1 root root 226,   0 Mär 19 17:29 card0
> > crw--- 1 root root 226, 128 Mär 19 17:29 renderD128
> >
> > After udev applied the rules, it looks like below, meaning users in group
> > `video` are allowed to access the device.
> >
> > $ ls -l /dev/dri
> > insgesamt 0
> > drwxr-xr-x  2 root root 80 Mär 19 17:29 by-path
> > crw-rw+ 1 root video  226,   0 Mär 19 17:29 card0
> > crw-rw+ 1 root render 226, 128 Mär 19 17:29 renderD128
> >
> > Is there a way to order a service in such a way, that it’s guaranteed that
> > udev rules to devices were applied?
> >
> > A small script applying permissions and ownership manually in
> > `ExecStartPre=` seems to work around the (graphics) issue.
> >
> > If it cannot be solved with ordering, what would you suggest?
> >
> > [1]: https://gitlab.freedesktop.org/wayland/weston/issues/382
> > [2]: 
> > https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/kms.c#L741
> >   
> 
> Ideally Weston would just wait for devices assigned to the seat it
> shall run on to appear to make this all safe.

Hi,

there is an issue open about something like that:
https://gitlab.freedesktop.org/wayland/weston/-/issues/173

If I understand it right, waiting for CanGraphical allows Weston's
DRM-backend to wait for any DRM device to appear on the seat, so that
you don't need to hardcode in advance which DRM device to depend on.

Weston itself does not know which device it should wait for appearing
either, otherwise it could watch udev for it. Or, I guess Weston could
wait for any DRM device assigned to the seat, so essentially what
CanGraphical does.

> The thing is that we
> don't know if a DRM device will show up or not. on some systems DRM
> might show up, but on others (servers, containers, embedded devices,
> …) it might never, since they have no actual graphics hw that can do
> DRM. hence ordering a service after a device appearing means your
> system will only boot up on machines that actually have a DRM device,
> and not those anymore that do not...

Yeah, that's a problem. In Weston's case, if Weston is started with
DRM-backend, then that can be taken to mean that there will be a DRM
device and it's ok to wait for it indefinitely. If not, the user should
use another backend, like headless-backend.

> What you could do is write a udev rule for your drm device that uses
> the SYSTEMD_WANTS property to pull in has-drm.target, and then hook
> your weston service into that with a Requisite=multi-user.target or
> so. That way weston gets pulled in only if DRM shows up and when DRM
> shows up, but not before and not on systems that do not have it, and
> boot is not delayed for it...

That sounds nice to me.


Thanks,
pq

> If you develop your stuff for a very specific device only, and do not
> attempt to build an OS that can boot on generic systems, then you
> could also just change your weston service to do
> "Wants=dev-dri-card0.device" + "After=dev-dri-card0.device". and thus
> leave weston in the initial transaction and time out if DRM never
> shows up...
> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



pgp66VJRk0SYE.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`

[Pekka Paalanen]

On Thu, 19 Mar 2020 17:47:30 +0100
Paul Menzel  wrote:

> Dear systemd folks,
> 
> 
> I am using Debian Sid/unstable with systemd 245.2 and Weston 8.0.0.
> 
> I amtrying to start a graphical desktop as soon as possible. Currently, 
> I use Weston, but unfortunately accessing `/dev/dri/card0` it gets a 
> permission denied error. The Weston service unit is ordered after 
> `systemd-logind.service`.
> 
> Weston now fails to start, because it gets a permission denied error 
> accessing `/dev/dri/card0` [1][2].
> 
>  drmModeSetCrtc(backend->drm.fd, output->crtc_id, 
> scanout_state->fb->fb_id, 0, 0, connectors, n_conn, >mode_info);

Hi,

if you get permission error from drmModeSetCrtc() call, then it has
nothing to do with file system permissions. The device node was already
opened successfully. Most likely the open DRM device file description
does not have the DRM master status.

> 
> Right before Weston starts, the permission and ownership are like below.
> 
>  $ ls -l /dev/dri:
>  insgesamt 0
>  crw--- 1 root root 226,   0 Mär 19 17:29 card0
>  crw--- 1 root root 226, 128 Mär 19 17:29 renderD128
> 
> After udev applied the rules, it looks like below, meaning users in 
> group `video` are allowed to access the device.
> 
>  $ ls -l /dev/dri
>  insgesamt 0
>  drwxr-xr-x  2 root root 80 Mär 19 17:29 by-path
>  crw-rw+ 1 root video  226,   0 Mär 19 17:29 card0
>  crw-rw+ 1 root render 226, 128 Mär 19 17:29 renderD128

If you use logind, then logind runs as root and is used to open the DRM
device node on behalf of weston, so these file system permissions
should be irrelevant.

However, logind can revoke DRM master status from weston, and possibly
even open the device without granting the DRM master status I guess.

Not having DRM master status will cause drmModeSetCrtc() and any other
KMS state change to fail, quite likely with a permission error.

> 
> Is there a way to order a service in such a way, that it’s guaranteed 
> that udev rules to devices were applied?

However, udev rules can affect which DRM device node Weston attempts to
use. But since it already opens the right(?) one, I don't think udev
rules change anything.

> A small script applying permissions and ownership manually in 
> `ExecStartPre=` seems to work around the (graphics) issue.

I'm guessing this just causes enough of a delay to hide the race
somewhere else.


Thanks,
pq

> 
> If it cannot be solved with ordering, what would you suggest?
> 
> [1]: https://gitlab.freedesktop.org/wayland/weston/issues/382
> [2]: 
> https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/backend-drm/kms.c#L741
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



pgpzEXfptaQFw.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] is the watchdog useful?

[Pekka Paalanen]

On Tue, 22 Oct 2019 09:17:42 +
Zbigniew Jędrzejewski-Szmek  wrote:

> On Tue, Oct 22, 2019 at 09:54:31AM +0300, Pekka Paalanen wrote:
> > On Mon, 21 Oct 2019 17:50:44 +
> > Zbigniew Jędrzejewski-Szmek  wrote:
> >   
> > > In principle, the watchdog for services is nice. But in practice it seems
> > > be bring only grief. The Fedora bugtracker is full of automated reports 
> > > of ABRTs,
> > > and of those that were fired by the watchdog, pretty much 100% are bogus, 
> > > in 
> > > the sense that the machine was resource starved and the watchdog fired.  
> > 
> > Hi,
> > 
> > just curious, is that resource starvation caused by something big, e.g.
> > a browser, using too much memory which leads to the kernel reclaiming
> > also pages of program text sections because they can be reloaded from
> > disk at any time, however those pages are needed again immediately
> > after when some CPU core switches process context, leading to something
> > that looks like a hard freeze to a user, while the kernel is furiously
> > loading pages from disk just to drop them again, and can take from
> > minutes to hours before any progress is visible?  
> 
> I don't really know. Unfortunately, abrt in Fedora does not collect log
> messages. In the old syslog days, a snippet of /var/log/messages for the
> last 20 minutes or something like that before a crash would be copied
> into the bug report, and this would include kernel messages about disk
> errors, or kernel stalls, or other interesting hints. Unfortunately
> nowadays, because of privacy concerns (?) and an effort to make things
> more efficient (?), just some heavily-filtered journalctl output is
> attached. In practice, usually this is at most a few lines and
> completely useless. In particular, it does not give any hints to the
> overall state of the system.
> 
> I have spoken to abrt maintainers about this, but it seems that this
> problem is specific to systemd, and for most other applications it is
> OK to get a backtrace without any system-wide context. So I don't see
> this changing any time soon ;(
> 
> Sometimes I ask people for logs, and sometimes I get them, and in those
> cases it seems that both hardware issues (e.g. a failing disk), or memory
> exhaustion are often involved. In some cases there is no clear reason.
> And since in the great majority we don't have any logs, it is hard to
> say anything.
> 
> > It has happened to me on Fedora in the past. I could probably dig up
> > discussions about the problem in general if you want, they explain it
> > better than I ever could.
> > 
> > Does Fedora prevent that situation by tuning some kernel knobs nowadays
> > for desktops?  
> 
> I don't think so.

For the case I described, I don't think there are really any error
messages produced, unless OOM killer finally manages to kill something.
That may take half an hour to finally kick in, or even longer. The
kernel is running just fine but userspace makes little to no progress.

Personally I was just lucky to reproduce the issue while iotop was
running and I saw 100% disk I/O used for purely reading, soon after
everything just ground to halt.

Maybe that could explain some of the reports.


Thanks,
pq


pgpfOWpjVSfQw.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] is the watchdog useful?

[Pekka Paalanen]

On Mon, 21 Oct 2019 17:50:44 +
Zbigniew Jędrzejewski-Szmek  wrote:

> In principle, the watchdog for services is nice. But in practice it seems
> be bring only grief. The Fedora bugtracker is full of automated reports of 
> ABRTs,
> and of those that were fired by the watchdog, pretty much 100% are bogus, in 
> the sense that the machine was resource starved and the watchdog fired.

Hi,

just curious, is that resource starvation caused by something big, e.g.
a browser, using too much memory which leads to the kernel reclaiming
also pages of program text sections because they can be reloaded from
disk at any time, however those pages are needed again immediately
after when some CPU core switches process context, leading to something
that looks like a hard freeze to a user, while the kernel is furiously
loading pages from disk just to drop them again, and can take from
minutes to hours before any progress is visible?

It has happened to me on Fedora in the past. I could probably dig up
discussions about the problem in general if you want, they explain it
better than I ever could.

Does Fedora prevent that situation by tuning some kernel knobs nowadays
for desktops?


Thanks,
pq


pgp5LISA40kDi.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] In unit files of systemd version 234 Type=notify not working

[Pekka Paalanen]

On Fri, 24 May 2019 05:38:28 +
Rajshekhar Sanda  wrote:

> Hi all,
> 
> 
> We are building Genivi 14 in which we are trying to launch weston at boot 
> time with service file.
> 
> 
> service file is as follows:
> 
> 
> 
> [Unit]
> Description= launch weston
> Requires=  dbus-session.service dbus.service systemd-user-sessions.service
> After= dbus-session.socket dbus.service  dbus-session.service 
> systemd-user-sessions.service  session-c1.scope
> ConditionPathExists=/dev/tty0
> 
> [Service]
> Type=notify
> User=root
> Restart=on-failure
> ExecStart=/usr/bin/weston
> NotifyAccess=all
> PAMName=login
> StandardInput=tty-fail
> TTYPath=/dev/tty7
> TTYReset=yes
> TTYVHangup=yes
> TTYVTDisallocate=yes
> UtmpIdentifier=tty7
> UtmpMode=root
> TimeoutStartSec=60
> WatchdogSec=20
> #ExecStart=/usr/bin/weston
> 
> [Install]
> WantedBy=basic.target
> 
> ---
> 
> 
> Here Type=notify is not supporting.
> 
> I observed other types are working fine.

Hi,

you asked the same already:
https://lists.freedesktop.org/archives/systemd-devel/2019-May/042657.html

I replied asking for more information:
https://lists.freedesktop.org/archives/systemd-devel/2019-May/042658.html

Also the system logs you presented seem to be lacking any specific
error for the weston service unit. I can't say if that is for real, or
if you just trimmed it out of the logs.

Are you familiar with
https://gitlab.freedesktop.org/wayland/weston/merge_requests/39 which
attempts to document how exactly to launch weston from a systemd system
unit?

I never intended that to be used with the root user though. I have no
idea what running it as root would imply, but I would avoid it if at
all possible.

Since it looks like Weston gets killed by SIGTERM, I would think that
something outside of Weston is killing it deliberately.

Is /usr/bin/weston the actual weston executable or some wrapper script?

Does enabling session lingering work around the problem?


Thanks,
pq


pgpdLxhDFd0ZI.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Weston not launching Via Service file.

[Pekka Paalanen]

On Fri, 17 May 2019 04:36:52 +
Rajshekhar Sanda  wrote:

> Hello,
> 
> 
> We are working on Genivi14, in which we are trying to launch weston
> via service file. It is not working if iam giving Type=notify in
> service file.
> 

Hi,

could you attach the stderr and stdout output of Weston as well, please?

You should be able to find that in your system journal I guess. That
should help diagnose if it is a problem with Weston or with the systemd
unit file.


Thanks,
pq


pgpmRXRbjS0SD.pgp
Description: OpenPGP digital signature
___
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

[Pekka Paalanen]

On Tue, 28 Nov 2017 12:14:29 +0200
Pekka Paalanen  wrote:

> From: Pekka Paalanen 
> 
> There are many bad and even worse attempts to make Weston run as a
> systemd service, and very few good ones. Let's add a good one as an
> example in upstream: does not use weston-launch, does not run weston as
> root, does not need wrapper scripts, and relies on logind and PAM.
> 
> This example has been composed from a couple of real-world Weston unit
> files used in production. It has not been used verbatim, but it has been
> briefly tested on one Yocto-based system.
> 
> The service file is not installed by the build. It would likely need
> small adjustments for each distribution or system to be deplyed on.
> 
> The session-c1.scope workaround refers to a systemd bug that has been
> said to be hard to reproduce, but the details have been lost in time.
> 
> Fixes: https://phabricator.freedesktop.org/T63
> 
> Cc: martyn.we...@collabora.co.uk
> Cc: fabien.lahoud...@collabora.co.uk
> Cc: matt.hoos...@gmail.com
> Cc: sjoerd.sim...@collabora.co.uk
> Signed-off-by: Pekka Paalanen 
> 
> ---
> 
> Hi all,
> 
> I have cross-posted this patch to systemd-devel with the hope that
> someone would recall details about the systemd or PAM plugin race that
> prompted the session-c1.scope workaround. I belive Martyn spoke about it
> in person with Lennart, but as far as Martyn recalls, there is no record
> of the issue. Enabling session lingering was mentioned as another
> workaround.

Hi all,

I was recently contacted asking about what happened to this patch. It
still hasn't landed in Weston in any form, because this good discussion
around November 2017 - January 2018 had suggestions I have not had the
time to integrate. I did do a few changes, and the latest is currently
tracked at:

https://gitlab.freedesktop.org/wayland/weston/merge_requests/39

The lacking bits are those particularly around PAM and the old system
specific workaround that is still present.

I would be happy if someone wants to take over this, as it is unlikely
I can push it forward or test meaningfully myself.


Thanks,
pq


> ---
>  doc/systemd/README | 45 +++
>  doc/systemd/weston.service | 66 
> ++
>  2 files changed, 111 insertions(+)
>  create mode 100644 doc/systemd/README
>  create mode 100644 doc/systemd/weston.service
> 
> diff --git a/doc/systemd/README b/doc/systemd/README
> new file mode 100644
> index ..2aa3aa9a
> --- /dev/null
> +++ b/doc/systemd/README
> @@ -0,0 +1,45 @@
> + Systemd integration examples
> +
> +These examples rely on Weston's logind and systemd support. Weston needs to 
> be
> +built with options: --enable-dbus --enable-systemd-login 
> --enable-systemd-notify
> +
> +Furthermore, Weston needs to be configured to load systemd-notify.so plugin.
> +This can be done on the Weston command line:
> +
> +$ weston --modules=systemd-notify.so
> +
> +or in weston.ini:
> +
> +[core]
> +modules=systemd-notify.so
> +
> +The plugin implements the systemd service notification protocol, watchdog
> +protocol, and also allows socket activation and configuring listening sockets
> +via systemd.
> +
> +
> + weston.service
> +
> +An example on how to run Weston as a system service. It starts a full user
> +session of the named user on the given virtual terminal.
> +
> +This is useful for running a login manager or for dedicated systems that do 
> not
> +have personal user accounts and do not need the user to log in.
> +
> +You should very least customize the user, but likely also the tty and
> +and the weston command line. See 'systemctl edit' command for an easy way to
> +do that per-system if you don't edit the service file before installing it.
> +
> +This approach has an issue that in one system was worked around with the
> +"After=session-c1.scope" directive. The details have been forgotten, but
> +enabling session lingering was mentioned as another workaround. It might
> +perhaps have something to do with multiple system units triggering the setup
> +of a user session. It would be much better to start Weston as a systemd user
> +service instead to avoid the issue completely.
> +
> +
> +TODO: add an example of socket activation and defining sockets with systemd
> +
> +TODO: talk about starting Weston as a systemd user service, as that would
> +often be more appropriate than as a system service. The user can still be
> +automatically logged in. Presumably the auto-login service can allocate the 
> VT.
> diff --git a/doc/systemd/weston.service b/doc/systemd/weston.service
> new file mode 100644
> index ..80d242a6
> --- /dev/null

Re: [systemd-devel] Not able to start Weston dependent application

[Pekka Paalanen]

On Wed, 31 Oct 2018 11:51:47 +0100
Jérémy Rosen  wrote:

> Pekka : is the notify plugin already upstreamed ? if yes, loading it and 
> setting Type=notify might work...

Yes, it's upstream. The only thing not upstream is the documentation on
how to actually use that stuff with systemd units. :-P


Thanks,
pq

> On 31/10/2018 11:45, Lennart Poettering wrote:
> > On Mi, 31.10.18 15:26, deepan muthusamy (deepan.m2...@gmail.com) wrote:
> >  
> >> I added both after and requires.What you meant by security feature?@rosan
> >>
> >> Type I made as simple.@ Lennart  
> > That's not going to work. If you use Type=simple, then system will
> > consider the service to be up as soon as systemd called fork(). Unless
> > weston uses socket activation this is definitely not the point in time
> > where its IPC APIs are usable yet.
> >
> > Lennart
> >  
> 



pgpN6LwBsrLPN.pgp
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Not able to start Weston dependent application

[Pekka Paalanen]

On Wed, 31 Oct 2018 11:32:45 +0100
Jérémy Rosen  wrote:

> socket-activated weston ?
> 
> nice :)
> 
> Why does weston require logind ? I work in the embedded world and we 
> usually disable logind entirely (no users in the "human user" meaning of 
> the term)

That's when you run Weston as a normal user: logind grants access to
DRM and input devices and revokes access as well when appropriate.

Of course, you can work around that by fiddling with device permissions
or using some other service that sets those up, and there is
weston-launch as well, but logind is really the easy and recommended
way to let it work especially on desktop systems.

logind is not a hard requirement. That option has usually been
called for by people who don't have systemd at all. I'm not sure Weston
has ever been tested on systemd but without logind. Or maybe it works
and no-one told upstream. :-)

Weston actually has three "launchers": one uses logind, one uses
weston-launch (a setuid-root helper), and one uses neither. The last
one is usually used as root for developer testing, I believe.


Thanks,
pq


pgplvdZ9LobqL.pgp
Description: OpenPGP digital signature
___
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

[Pekka Paalanen]

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.

> 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


pgpo9S0QUKRyq.pgp
Description: OpenPGP digital signature
___
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

[Pekka Paalanen]

On Fri, 1 Dec 2017 18:25:35 +0100
Lennart Poettering <lenn...@poettering.net> 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 th

Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

[Pekka Paalanen]

On Thu, 30 Nov 2017 11:16:19 +
Martyn Welch <martyn.we...@collabora.co.uk> wrote:

> On Thu, 2017-11-30 at 12:09 +0200, Pekka Paalanen wrote:
> > On Wed, 29 Nov 2017 19:05:07 +0100
> > Lennart Poettering <lenn...@poettering.net> wrote:
> >   
> > > On Di, 28.11.17 12:14, Pekka Paalanen (ppaala...@gmail.com) wrote:
> > >   
> > > > +
> > > > +[Unit]
> > > > +Description=Weston, a Wayland compositor, as a system service
> > > > +Documentation=man:weston(1) man:weston.ini(5)
> > > > +Documentation=http://wayland.freedesktop.org/
> > > > +
> > > > +# Make sure we are started after logins are permitted.
> > > > +After=systemd-user-sessions.service
> > > > +
> > > > +# If Plymouth is used, we want to start when it is on its way out.
> > > > +After=plymouth-quit-wait.service
> > > > +
> > > > +# D-Bus is necessary for contacting logind. Logind is required.
> > > > +Wants=dbus.socket
> > > > +After=dbus.socket
> > > > +
> > > > +# This scope is created by pam_systemd when logging in as the user.
> > > > +# This directive is a workaround to a systemd bug, where the setup of 
> > > > the
> > > > +# user session by PAM has some race condition, possibly leading to a 
> > > > failure.
> > > > +# See README for more details.
> > > > +After=session-c1.scope
> > > 
> > > Hmm, what is this about?
> > > 
> > > 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

- access to DRM and input devices via logind

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.

> 
> First off, apologies if I explained this badly when I attempted to
> explain the issue at FOSDEM, I'm still not convinced I truly understand
> what's happening here, but let's give it another go...
> 
> Testing of the product in the project mentioned by Pekka revealed that
> we would sometimes see Weston fail to boot. IIRC, in the order of 2 in
> 10 times when switching from an initial charging state (that the device
> would boot into when power was applied to the device without the power
> button being pressed) and the normal running state (when the power
> button was then pressed). The charging state is pretty much a small
> subset of the normal running state. From memory, the "xuser" session is
> not created in that state. The filtered logs that I was given:
> 
> 2017-01-05T14:08:19.41+00:00 XXX systemd-logind[315]: New seat
> seat0.
> 2017-01-05T14:08:19.672756+00:00 XXX systemd-logind[315]: Watching
> system buttons on /dev/input/event0 (power-gpio-keys)
> 2017-01-05T14:08:20.176354+00:00 XXX systemd[1]: Starting User Manager
> for UID 1000...
> 2017-01-05T14:08:20.394955+00:00 XXX systemd[1]: Starting Weston...
> 2017-01-05T14:08:21.867999+00:00 XXX systemd-logind[315]: New session c1
> of user xuser.
> 2017-01-05T14:08:21.915400+00:00 XXX systemd-logind[315]: Watching
> system buttons on /dev/input/event0 (power-gpio-keys)
> 2017-01-05T14:08:46.279480+00:00 XXX weston[403]: [14:08:46.157] fatal:
> environment variable XDG_RUNTIME_DIR is not set.
> 2017-01-05T14:08:46.421821+00:00 XXX systemd[1]: Failed to start Weston.
> 2017-01-05T14:08:46.471701+00:00 XXX systemd-logind[315]: Removed
> session c1.
> 2017-01-05T14:08:47.424030+00:00 XXX systemd[1]: Started User Manager
> for UID 1000.
> 2017-01-05T14:08:47.469949+00:00 XXX systemd-logind[315]: Failed to stop
> user service: Transaction is destructive.
> 2017-01-05T14:08:47.540518+00:00 XXX systemd-logind[315]: Failed to stop
> user slice: Transaction is destructive.
> 
> Debugging suggested that XDG_RUNTIME_DIR was not being created when it
>

Re: [systemd-devel] [PATCH weston] doc/systemd: system service example

[Pekka Paalanen]

On Thu, 30 Nov 2017 13:29:22 +0100
Lennart Poettering <lenn...@poettering.net> wrote:

> On Do, 30.11.17 12:09, Pekka Paalanen (ppaala...@gmail.com) wrote:
> 
> > > Hmm, what is this about?
> > > 
> > > 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.  
> > 
> > Hi Lennart,
> > 
> > this is the bit Martyn talked you in person some time ago, maybe Martyn
> > could refresh your memory?  
> 
> Oh, did we? I don't remember, sorry!

Hi Lennart,

no worries. I don't remember what I did early this week...

> > > 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.  
> > 
> > Ok. Is there any guide or example I could point people to, so that they
> > can write their own stuff correctly? Any example I could put into
> > Weston docs?  
> 
> Unfortunately PAM is awful and highly distro-specific. It's not really
> possible to write PAM snippets that work generically on all
> distros. Sorry. The distros even patch PAM differently, so that
> slightly difference constructs are available...

That's the feeling I already got. Following Mantas' suggestion and
commenting it line by line like I did for the service unit is probably
the best we could do then.


Thanks,
pq


pgp731wB5Aclo.pgp
Description: OpenPGP digital signature
___
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

[Pekka Paalanen]

On Wed, 29 Nov 2017 19:05:07 +0100
Lennart Poettering <lenn...@poettering.net> wrote:

> On Di, 28.11.17 12:14, Pekka Paalanen (ppaala...@gmail.com) wrote:
> 
> > +
> > +[Unit]
> > +Description=Weston, a Wayland compositor, as a system service
> > +Documentation=man:weston(1) man:weston.ini(5)
> > +Documentation=http://wayland.freedesktop.org/
> > +
> > +# Make sure we are started after logins are permitted.
> > +After=systemd-user-sessions.service
> > +
> > +# If Plymouth is used, we want to start when it is on its way out.
> > +After=plymouth-quit-wait.service
> > +
> > +# D-Bus is necessary for contacting logind. Logind is required.
> > +Wants=dbus.socket
> > +After=dbus.socket
> > +
> > +# This scope is created by pam_systemd when logging in as the user.
> > +# This directive is a workaround to a systemd bug, where the setup of the
> > +# user session by PAM has some race condition, possibly leading to a 
> > failure.
> > +# See README for more details.
> > +After=session-c1.scope  
> 
> Hmm, what is this about?
> 
> 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.

Hi Lennart,

this is the bit Martyn talked you in person some time ago, maybe Martyn
could refresh your memory?

Yes, I am definitely not happy about this directive, but it serves as
the reminder of the issue Martyn was debugging a long time ago, and
this was the workaround chosen for the particular project at that time.
I guessed it's not portable.

I have it here so it would trigger the discussion, in the hopes that
someone could recall the details of the fundamental problem. I heard it
was deemed to be a hard-to-reproduce systemd bug, but I have no other
details.

If we could determine the bug doesn't exist anymore, that would be
awesome and I could just drop this.

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

Ok. Is there any guide or example I could point people to, so that they
can write their own stuff correctly? Any example I could put into
Weston docs?

Personally I have no understanding of what PAM does. I just copied
weston-launch (setuid-root helper for non-systemd systems) that also
uses "login" for PAM name if it was asked to create a new session(?).


Thanks,
pq


pgpb72BBsFTNa.pgp
Description: OpenPGP digital signature
___
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

[Pekka Paalanen]

On Wed, 29 Nov 2017 14:06:25 +0200
Mantas Mikulėnas  wrote:

> On Wed, Nov 29, 2017 at 10:32 AM, Jérémy Rosen 
> wrote:
> 
> > I had a quick glance but didn't actually test...
> >
> > 1) please open a pull request on github, you will have more feedback that
> > way
> >  
> 
> I think it's supposed to be a patch for Weston on fd.o and only cc'd here
> to systemd-devel...
> 

Hi,

yes, it's a Weston patch, not a systemd patch. Sorry for the confusion,
I was just looking for feedback.


Thanks,
pq


pgpb2i0B3eMl_.pgp
Description: OpenPGP digital signature
___
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

[Pekka Paalanen]

On Wed, 29 Nov 2017 09:32:02 +0100
Jérémy Rosen <jeremy.ro...@smile.fr> wrote:

> I had a quick glance but didn't actually test...

> 2) you probably want to add Alias=display-manager.service, so it can 
> pull it other graphical services

Hi,

that sounds like a good idea.


Thanks,
pq

(adding back all the CCs)

> On 28/11/2017 11:14, Pekka Paalanen wrote:
> > From: Pekka Paalanen <pekka.paala...@collabora.co.uk>
> >
> > There are many bad and even worse attempts to make Weston run as a
> > systemd service, and very few good ones. Let's add a good one as an
> > example in upstream: does not use weston-launch, does not run weston as
> > root, does not need wrapper scripts, and relies on logind and PAM.
> >
> > This example has been composed from a couple of real-world Weston unit
> > files used in production. It has not been used verbatim, but it has been
> > briefly tested on one Yocto-based system.
> >
> > The service file is not installed by the build. It would likely need
> > small adjustments for each distribution or system to be deplyed on.
> >
> > The session-c1.scope workaround refers to a systemd bug that has been
> > said to be hard to reproduce, but the details have been lost in time.
> >
> > Fixes: https://phabricator.freedesktop.org/T63
> >
> > Cc: martyn.we...@collabora.co.uk
> > Cc: fabien.lahoud...@collabora.co.uk
> > Cc: matt.hoos...@gmail.com
> > Cc: sjoerd.sim...@collabora.co.uk
> > Signed-off-by: Pekka Paalanen <pekka.paala...@collabora.co.uk>
> >
> > ---
> >
> > Hi all,
> >
> > I have cross-posted this patch to systemd-devel with the hope that
> > someone would recall details about the systemd or PAM plugin race that
> > prompted the session-c1.scope workaround. I belive Martyn spoke about it
> > in person with Lennart, but as far as Martyn recalls, there is no record
> > of the issue. Enabling session lingering was mentioned as another
> > workaround.
> > ---
> >   doc/systemd/README | 45 +++
> >   doc/systemd/weston.service | 66 
> > ++
> >   2 files changed, 111 insertions(+)
> >   create mode 100644 doc/systemd/README
> >   create mode 100644 doc/systemd/weston.service
> >
> > diff --git a/doc/systemd/README b/doc/systemd/README
> > new file mode 100644
> > index ..2aa3aa9a
> > --- /dev/null
> > +++ b/doc/systemd/README
> > @@ -0,0 +1,45 @@
> > +   Systemd integration examples
> > +
> > +These examples rely on Weston's logind and systemd support. Weston needs 
> > to be
> > +built with options: --enable-dbus --enable-systemd-login 
> > --enable-systemd-notify
> > +
> > +Furthermore, Weston needs to be configured to load systemd-notify.so 
> > plugin.
> > +This can be done on the Weston command line:
> > +
> > +$ weston --modules=systemd-notify.so
> > +
> > +or in weston.ini:
> > +
> > +[core]
> > +modules=systemd-notify.so
> > +
> > +The plugin implements the systemd service notification protocol, watchdog
> > +protocol, and also allows socket activation and configuring listening 
> > sockets
> > +via systemd.
> > +
> > +
> > +   weston.service
> > +
> > +An example on how to run Weston as a system service. It starts a full user
> > +session of the named user on the given virtual terminal.
> > +
> > +This is useful for running a login manager or for dedicated systems that 
> > do not
> > +have personal user accounts and do not need the user to log in.
> > +
> > +You should very least customize the user, but likely also the tty and
> > +and the weston command line. See 'systemctl edit' command for an easy way 
> > to
> > +do that per-system if you don't edit the service file before installing it.
> > +
> > +This approach has an issue that in one system was worked around with the
> > +"After=session-c1.scope" directive. The details have been forgotten, but
> > +enabling session lingering was mentioned as another workaround. It might
> > +perhaps have something to do with multiple system units triggering the 
> > setup
> > +of a user session. It would be much better to start Weston as a systemd 
> > user
> > +service instead to avoid the issue completely.
> > +
> > +
> > +TODO: add an example of socket activation and defining sockets with systemd
> > +
> > +TODO: talk about starting Weston as a systemd user service, as that would
> > +often be m

[systemd-devel] [PATCH weston] doc/systemd: system service example

[Pekka Paalanen]

From: Pekka Paalanen <pekka.paala...@collabora.co.uk>

There are many bad and even worse attempts to make Weston run as a
systemd service, and very few good ones. Let's add a good one as an
example in upstream: does not use weston-launch, does not run weston as
root, does not need wrapper scripts, and relies on logind and PAM.

This example has been composed from a couple of real-world Weston unit
files used in production. It has not been used verbatim, but it has been
briefly tested on one Yocto-based system.

The service file is not installed by the build. It would likely need
small adjustments for each distribution or system to be deplyed on.

The session-c1.scope workaround refers to a systemd bug that has been
said to be hard to reproduce, but the details have been lost in time.

Fixes: https://phabricator.freedesktop.org/T63

Cc: martyn.we...@collabora.co.uk
Cc: fabien.lahoud...@collabora.co.uk
Cc: matt.hoos...@gmail.com
Cc: sjoerd.sim...@collabora.co.uk
Signed-off-by: Pekka Paalanen <pekka.paala...@collabora.co.uk>

---

Hi all,

I have cross-posted this patch to systemd-devel with the hope that
someone would recall details about the systemd or PAM plugin race that
prompted the session-c1.scope workaround. I belive Martyn spoke about it
in person with Lennart, but as far as Martyn recalls, there is no record
of the issue. Enabling session lingering was mentioned as another
workaround.
---
 doc/systemd/README | 45 +++
 doc/systemd/weston.service | 66 ++
 2 files changed, 111 insertions(+)
 create mode 100644 doc/systemd/README
 create mode 100644 doc/systemd/weston.service

diff --git a/doc/systemd/README b/doc/systemd/README
new file mode 100644
index ..2aa3aa9a
--- /dev/null
+++ b/doc/systemd/README
@@ -0,0 +1,45 @@
+   Systemd integration examples
+
+These examples rely on Weston's logind and systemd support. Weston needs to be
+built with options: --enable-dbus --enable-systemd-login 
--enable-systemd-notify
+
+Furthermore, Weston needs to be configured to load systemd-notify.so plugin.
+This can be done on the Weston command line:
+
+$ weston --modules=systemd-notify.so
+
+or in weston.ini:
+
+[core]
+modules=systemd-notify.so
+
+The plugin implements the systemd service notification protocol, watchdog
+protocol, and also allows socket activation and configuring listening sockets
+via systemd.
+
+
+   weston.service
+
+An example on how to run Weston as a system service. It starts a full user
+session of the named user on the given virtual terminal.
+
+This is useful for running a login manager or for dedicated systems that do not
+have personal user accounts and do not need the user to log in.
+
+You should very least customize the user, but likely also the tty and
+and the weston command line. See 'systemctl edit' command for an easy way to
+do that per-system if you don't edit the service file before installing it.
+
+This approach has an issue that in one system was worked around with the
+"After=session-c1.scope" directive. The details have been forgotten, but
+enabling session lingering was mentioned as another workaround. It might
+perhaps have something to do with multiple system units triggering the setup
+of a user session. It would be much better to start Weston as a systemd user
+service instead to avoid the issue completely.
+
+
+TODO: add an example of socket activation and defining sockets with systemd
+
+TODO: talk about starting Weston as a systemd user service, as that would
+often be more appropriate than as a system service. The user can still be
+automatically logged in. Presumably the auto-login service can allocate the VT.
diff --git a/doc/systemd/weston.service b/doc/systemd/weston.service
new file mode 100644
index ..80d242a6
--- /dev/null
+++ b/doc/systemd/weston.service
@@ -0,0 +1,66 @@
+# This is a system unit for launching Weston with auto-login as the
+# user configured here.
+#
+# Weston must be built with systemd support, and your weston.ini must load
+# the plugin systemd-notify.so.
+
+[Unit]
+Description=Weston, a Wayland compositor, as a system service
+Documentation=man:weston(1) man:weston.ini(5)
+Documentation=http://wayland.freedesktop.org/
+
+# Make sure we are started after logins are permitted.
+After=systemd-user-sessions.service
+
+# If Plymouth is used, we want to start when it is on its way out.
+After=plymouth-quit-wait.service
+
+# D-Bus is necessary for contacting logind. Logind is required.
+Wants=dbus.socket
+After=dbus.socket
+
+# This scope is created by pam_systemd when logging in as the user.
+# This directive is a workaround to a systemd bug, where the setup of the
+# user session by PAM has some race condition, possibly leading to a failure.
+# See README for more details.
+After=session-c1.scope
+
+# Since we are part of the graphical session, make sure we are started before
+# it is complete.
+B