Re: [systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`
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] Read-only /etc, machine-id with an overlay - journald failing
On Tue, Mar 31, 2020 at 03:52:44PM +0200, Lennart Poettering wrote: > On Mi, 26.02.20 09:44, Andreas Kempe (andreas.ke...@actia.se) wrote: > > > Hello everyone, > > > > I'm working in a project with an embedded Linux system based on > > Openembedded using Systemd version 241 as our init process. We're > > using a read-only /etc. To facilitate development, we want to use a > > writeable overlay on /etc, but we ran into an issue. > > > > When we start, Systemd detects that there is no machine-id file > > present in /etc so it generates and mounts a /etc/machine-id. When our > > mount unit then applies the overlay on /etc, it hides the mounted > > file. Journald later fails to start because /etc/machine-id isn't > > visible through the overlay. > > So when you swap out /etc you really should so so atomically, and > ensure that at no point in time stuff (i.e. mounts) go missing while > you shift things around. In particular not the machine-id. > Yes, this is sound advice and of course the reasonable way to handling moving file systems around. We weren't counting on having anything extra mounted in /etc so it took us a bit by surprise. > Hence, the code that replaces /etc with an overlayfs, why doesn't it > bind mount /etc/machine-id into the new overlayfs before moving it > into place? i.e. first mount the overlayfs to some tmpdir, bind mount > /etc/machine-id into it, then use mount --move to move the fully > prepped overlayfs along with all submounts to /etc. That way noone > will notice anything changing. > The simple answer for not doing the above is that we didn't think of the idea. Personally, I don't have very much experience with overlays and I am used to simply mounting things at boot where they should be one thing at a time. One learns something new every day. Thank you for the advice! :) Cordially, Andreas Kempe ___ 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`
Dear Andrei, dear Lennart, Thank you very much for your answers. Am 31.03.20 um 17:09 schrieb Lennart Poettering: On Do, 19.03.20 20:24, Andrei Borzenkov (arvidj...@gmail.com) wrote: 19.03.2020 19:47, Paul Menzel пишет: 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? After=device should work. udev announces device after all rules have been processed. After= only orders, but this doesn't pull the device unit into the job queue. To do that, you need to add Wants= on the device unit as well. Trying this, After=dev-dri-card0.device Wants=dev-dri-card0.device the service times out waiting for the device. $ journalctl -a […] Apr 01 14:15:42.672430 kodi systemd[1]: Reached target Multi-User System. […] Apr 01 14:17:09.805001 kodi systemd[1]: dev-dri-card0.device: Job dev-dri-card0.device/start timed out. Apr 01 14:17:09.805839 kodi systemd[1]: Timed out waiting for device /dev/dri/card0. Apr 01 14:17:09.806464 kodi systemd[1]: dev-dri-card0.device: Job dev-dri-card0.device/start failed with result 'timeout'. Apr 01 14:17:09.809847 kodi systemd[1]: Starting Weston, a Wayland compositor, as a system service... […] $ ls -l /dev/dri/card0 crw-rw 1 root video 226, 0 Apr 1 14:15 /dev/dri/card0 Kind regards, Paul ___ 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`
On Mi, 01.04.20 14:23, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) wrote: > > > After=device should work. udev announces device after all rules have > > > been processed. > > > > After= only orders, but this doesn't pull the device unit into the job > > queue. To do that, you need to add Wants= on the device unit as well. > > Trying this, > > After=dev-dri-card0.device > Wants=dev-dri-card0.device > > the service times out waiting for the device. > > $ journalctl -a > […] > Apr 01 14:15:42.672430 kodi systemd[1]: Reached target Multi-User > System. > […] > Apr 01 14:17:09.805001 kodi systemd[1]: dev-dri-card0.device: Job > dev-dri-card0.device/start timed out. > Apr 01 14:17:09.805839 kodi systemd[1]: Timed out waiting for device > /dev/dri/card0. > Apr 01 14:17:09.806464 kodi systemd[1]: dev-dri-card0.device: Job > dev-dri-card0.device/start failed with result 'timeout'. > Apr 01 14:17:09.809847 kodi systemd[1]: Starting Weston, a Wayland > compositor, as a system service... > […] > $ ls -l /dev/dri/card0 > crw-rw 1 root video 226, 0 Apr 1 14:15 /dev/dri/card0 DRM devices are currently not tagged with "systemd", and thus no .device units are syntesized for them in systemd. Add a udev rule that matches against them and sets the "systemd" tag and they will appear in systemd, so that you can order your stuff against it. Lennart -- Lennart Poettering, Berlin ___ 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`
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. 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 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. 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. 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... > 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. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
