Re: [systemd-devel] Using *.path units without races?
On Fri, 20 Mar 2020, Uwe Geuder wrote: [...] > > PathChanged= and PathModified= each map down to a set of inotify > > events. It's the kernel's inotify system that determines whether the > > file changed or modified, not systemd. > > My understanding is that since > https://github.com/systemd/systemd/pull/13509/commits/06582e42de65a61d0238a18720a12b6353edb7cd > there are 2 states > > 1. While the path unit is waiting and the triggered service unit is dead > its indead all inotify's business. When a change happens the kernel will > notify systemd. > > 2. However, while the triggered service unit is running also the path > unit is running and the inotify fd is closed. So the kernel will not > report any changes to systemd at all during that time. Yes, I agree, this does seem like a regression to me. I'm actually a bit lost with all the changes that have happened to path units over the last year. It looks like this issue: https://github.com/systemd/systemd/issues/12801 is significant, since the reporter had a similar problem to the one you had: that is, a file created while the triggered service was active would not be picked up by PathExists=. But that issue was closed with a commit that fixed a side-issue -- that reloading or restarting the daemon would cause the service to be triggered -- and not the issue that the reporter had! And worse yet, I'm not even sure that side-issue is actually an issue. If these predicates are supposed to be level-triggered, and the predicate passes (e.g. the monitored path exist), then it shouldn't matter whether daemon-reload causes a retrigger, since the retriggered unit should already be active. "Retriggering" it would be a no-op. So... yeah, I'm really confused too. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using *.path units without races?
Hi! On Fri, 20 Mar 2020 at 00:31, Michael Chapman wrote: > > On Fri, 20 Mar 2020, Uwe Geuder wrote: > [...] > > The manual page is not very specific about how that is supposed to work > > IMHO, but I could imagine the following distinction: > > > > PathExists=, PathExistsGlob=, and DirectoryNotEmpty= are absolute > > predicates. When setting the path unit to waiting one can just check > > whether they are true or not. (After arming inotify of course.) With > > your patch my limited testing was successful. > > > > However, PathChanged= and PathModified= are relative predicates. You > > cannot just check whether they are true or not. Wouldn't the correct > > implementation > > > > 1. need to store the applicable timestamp of the path involved when the > >path unit is set to started and > > > > 2. when the path unit is set to waiting again it would need to compare > >the stored timestamp with the current timestamp (again after arming > >inotify) to catch modifications that happened while the unit was > >running/inotify not armed > > > > I don't think I see the timestamps stored at all. So how was this > > supposed to work? Was the intended semantics different? > > PathChanged= and PathModified= each map down to a set of inotify > events. It's the kernel's inotify system that determines whether the > file changed or modified, not systemd. My understanding is that since https://github.com/systemd/systemd/pull/13509/commits/06582e42de65a61d0238a18720a12b6353edb7cd there are 2 states 1. While the path unit is waiting and the triggered service unit is dead its indead all inotify's business. When a change happens the kernel will notify systemd. 2. However, while the triggered service unit is running also the path unit is running and the inotify fd is closed. So the kernel will not report any changes to systemd at all during that time. When thereafter the path unit enters waiting again it will add the required inotify watches again. However, to find out whether anything has changed, i. e. been missed while inotify was not watching, it would need to do it's own checking in user space. In the case of "absolute" predicates it's a straight-forward check whether such path exists and obviously that's what the code does with your patch. However, for the "relative" predicates I don't see another way than comparing timestamps. How else could it fulfill the promise of the man page of "checking immediately again". Inotify will report only potential future changes, not report anything that has already happened while it was inactive / the path unit running > When a service unit triggered by a path unit terminates (regardless > whether it exited successfully or failed), monitored paths are checked > immediately again, and the service accordingly restarted instantly I did a quick $ strace -e inotify_init,inotify_init1,inotify_add_watch,inotify_rm_watch,close -p and got something like this ... inotify_init1(IN_NONBLOCK|IN_CLOEXEC) = 12 inotify_add_watch(12, "/", IN_ATTRIB|IN_MOVED_TO|IN_CREATE|IN_DELETE_SELF|IN_MOVE_SELF) = 1 inotify_add_watch(12, "/tmp", IN_ATTRIB|IN_MOVED_TO|IN_CREATE|IN_DELETE_SELF|IN_MOVE_SELF) = 2 inotify_add_watch(12, "/", IN_MOVE_SELF) = 1 inotify_add_watch(12, "/tmp/systemd-path-test", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF) = 3 inotify_add_watch(12, "/tmp", IN_MOVE_SELF) = 2 close(12) ... for every "wait period" of the path unit. We see that the inotify fd gets closed when the units enter running state and there is a new inotify_init1() when the path unit enters watching again. Instead of timestamps the code does have a bool previous_exists For the "absolute" predicates that could "nearly" be used to implement different semantics. If the path has triggered once (previous_exists == true), don't trigger again on any extra changes unless the predicate was false (previous_exists == false) in the meantime. But a.) I don't see any such behaviour really described in the man page b.) the code doesn't seem to work like that at all, and c.) it could still not work if the predicate got false for a short period while the notify is not watching, because nobody could update the boolean appropriately. So even that variant would only "nearly" work. And for the "relative" predicates such a boolean would never be enough. Modification can have happened in the meantime even if the file existed before. So what's the purpose of the boolean? Regards, Uwe Uwe Geuder Neuro Event Labs Oy Tampere, Finland uwe.gxu...@neuroeventlabs.com (bot check: fix 1 obvious typo) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using *.path units without races?
On Fri, 20 Mar 2020, Uwe Geuder wrote: [...] > The manual page is not very specific about how that is supposed to work > IMHO, but I could imagine the following distinction: > > PathExists=, PathExistsGlob=, and DirectoryNotEmpty= are absolute > predicates. When setting the path unit to waiting one can just check > whether they are true or not. (After arming inotify of course.) With > your patch my limited testing was successful. > > However, PathChanged= and PathModified= are relative predicates. You > cannot just check whether they are true or not. Wouldn't the correct > implementation > > 1. need to store the applicable timestamp of the path involved when the >path unit is set to started and > > 2. when the path unit is set to waiting again it would need to compare >the stored timestamp with the current timestamp (again after arming >inotify) to catch modifications that happened while the unit was >running/inotify not armed > > I don't think I see the timestamps stored at all. So how was this > supposed to work? Was the intended semantics different? PathChanged= and PathModified= each map down to a set of inotify events. It's the kernel's inotify system that determines whether the file changed or modified, not systemd. For example, consider the IN_MODIFY event. This is the only event that distinguishes PathModified= from PathChanged=. inotify generates this event on any kind of "data write" operation to the file. See the inotify(7) manpage for details. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] location of user-1000.journal
Hi, I'm wondering if user journals are better being located in ~/.var by default? In particular in a systemd-homed context when ~/ is encrypted. -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using *.path units without races?
Hi again, On Thu, 19 Mar 2020 at 00:20, Uwe Geuder wrote: > > Hi! > > On Tue, 17 Mar 2020 at 23:52, Michael Chapman wrote: > > > > On Wed, 18 Mar 2020, Uwe Geuder wrote: > > > Hi! > > > > > > I have wondered for a while how I can use *.path units without (too bad) > > > races. > > > > > > Since > > > https://github.com/systemd/systemd/pull/13509/commits/06582e42de65a61d0238a18720a12b6353edb7cd > > > the behaviour has been become much clearer, but I must admit I still > > > don't get it. > > > > That commit does look incomplete to me. > > > > As a quick test, are you able to try out the patch below? This makes > > systemd always check the filesystem when the service stops, rather than > > just relying on the (as of that commit nonexistent) inotify event. ... > I built that change and quickly tested it. It seems to work fine! ... > As expected the service gets now invoked 3 times. Without your patch the > second touch command/file is missed and only "handled" together with the > third touch command/file. I tested a bit more. Yesterday I tested using DirectoryNotEmpty= Today I tested PathModified= and there your patch does not improve the situation. The manual page is not very specific about how that is supposed to work IMHO, but I could imagine the following distinction: PathExists=, PathExistsGlob=, and DirectoryNotEmpty= are absolute predicates. When setting the path unit to waiting one can just check whether they are true or not. (After arming inotify of course.) With your patch my limited testing was successful. However, PathChanged= and PathModified= are relative predicates. You cannot just check whether they are true or not. Wouldn't the correct implementation 1. need to store the applicable timestamp of the path involved when the path unit is set to started and 2. when the path unit is set to waiting again it would need to compare the stored timestamp with the current timestamp (again after arming inotify) to catch modifications that happened while the unit was running/inotify not armed I don't think I see the timestamps stored at all. So how was this supposed to work? Was the intended semantics different? Regards, Uwe Uwe Geuder Neuro Event Labs Oy Tampere, Finland uwe.gxu...@neuroeventlabs.com (bot check: fix 1 obvious typo) ___ 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`
19.03.2020 19:47, Paul Menzel пишет: > 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? > After=device should work. udev announces device after all rules have been processed. > 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 > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Ordering after udev applied rules to `/dev/dri/card0`
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
