Re: [systemd-devel] systemd user sessions?
Jon Stanley wrote: > I'd like a systemd unit (and only that unit) to be controlled by a > specific user. The unit runs as this user, so I thought about user > instances of systemd. This service should be started when the system > starts, so you'd have to enable linger in systemd-logind for that to > work. > > The question is how to make the systemd user *service* start at boot? [Install] WantedBy=default.target $ systemctl --user enable foo.service Created symlink from /home/user/.config/systemd/user/default.target.wants/foo.service to /home/user/.config/systemd/user/foo.service. $ That's pretty much it. -- pocek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)
David Herrmann wrote: > Krzysztof Kotlenga wrote: >> David Herrmann wrote: >>> Krzysztof Kotlenga wrote: >> >> Some more or less minor points still stand though: >> >> - errored/disabled bus-inputs are never freed, even after client >> disconnect (!) > > What's a "bus-input"? sd_bus.input_io_event_source sd_event_sources have a description set to "bus-input" to aid debugging: https://github.com/systemd/systemd/blob/v226/src/libsystemd/sd-bus/sd-bus.c#L3180 For example this return path: https://github.com/systemd/systemd/blob/v226/src/libsystemd/sd-bus/sd-bus.c#L2782 It's easy to "exercise" it with netcat (generate -EIO there), as I wrote before. Such sd_event_source gets disabled but it doesn't go anywhere, even after client disconnect. -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What's mounting this partition?
Paul D. DeRocco wrote: > I have a Yocto-built x86 system (...) Do you have udev-extraconf package installed? It contains such a gem: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/udev/udev-extraconf/automount.rules HTH. -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)
David Herrmann wrote: > Krzysztof Kotlenga wrote: >> Krzysztof Kotlenga wrote: >> >>> 2. Maybe I don't get something right - please enlighten me if >>> that's the case - but prioq_put or rather shuffle_up function is >>> buggy. >>> >>> (...) >>> >>> Am I wrong to believe that it should have swapped 2 and 1, not 2 >>> and 0? >> >> OK, I've finally realised that I'm a moron iterating over a >> heap-like structure... > > For the archives: Is this fixed with the prioq-compare fix? The point quoted above was bogus, but otherwise yes - the main issue here is fixed with the said fix. Some more or less minor points still stand though: - errored/disabled bus-inputs are never freed, even after client disconnect (!) - data pointer comparison instead of index comparison for prioq stability. Is this _really_ correct? Anyway, I made a pull request... -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)
Krzysztof Kotlenga wrote: > 2. Maybe I don't get something right - please enlighten me if that's > the case - but prioq_put or rather shuffle_up function is buggy. > > (...) > > Am I wrong to believe that it should have swapped 2 and 1, not 2 and > 0? OK, I've finally realised that I'm a moron iterating over a heap-like structure... -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)
Krzysztof Kotlenga wrote: > Two things: > (...) One more. Prioq compare functions in sd-event.c contain this: /* Stability for the rest */ if (x < y) return -1; if (x > y) return 1; How comparing prioq_item.data pointers is going to ensure stability? Shouldn't it be: if (x->prepare_index < y->prepare_index) ... and so on? -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)
Krzysztof Kotlenga wrote: > I recommend the following gdb script, because it provides some > possibly interesting output: Slightly fixed version: https://gist.github.com/pocek/709d8c098d632ed1f21e The first one was incorrectly printing pending_iteration instead of prepare_iteration field. Nothing major. > What's going on with order in that "prepare" Prioq? I've debugged this a bit more. Two things: 1. I think prepare_prioq_compare function is wrong: "enabled" field should be the first one to compare. 2. Maybe I don't get something right - please enlighten me if that's the case - but prioq_put or rather shuffle_up function is buggy. Let's start with prepare Prioq like this: bus-input e=1 pri=0 pi=8 fd=12 bus-input e=1 pri=0 pi=9 fd=18 <- netcat Now we enter some garbage in netcat: bus-input e=1 pri=0 pi=9 fd=12 bus-input e=0 pri=0 pi=9 fd=18 <- netcat BTW, some loop iterations later it is still OK if we have fixed the order in prepare_prioq_compare (see 1): bus-input e=1 pri=0 pi=10 fd=12 bus-input e=0 pri=0 pi=9 fd=18 <- netcat Good! Now let's make another connection. We have a breakpoint in prepare_prioq_compare. bus-input e=1 pri=0 pi=11 fd=12 bus-input e=0 pri=0 pi=9 fd=18 (null) e=1 pri=0 pi=0 fd=19 <- new connection, it doesn't have a description set yet. Backtrace for some context (shortened): #0 prepare_prioq_compare (a=0x81466e18, b=0x81477490) #1 shuffle_up (q=0x81466ee8, idx=2) #2 prioq_put (q=0x81466ee8, data=0x81477490, idx=0x814774b8) #3 sd_event_source_set_prepare (s=0x81477490, callback=0x80181f81 ) #4 attach_io_events (bus=0x81476d20) #5 sd_bus_attach_event (bus=0x81476d20, event=0x8140e6e0, priority=0) #6 bus_on_connection (s=0x81471680, fd=14, revents=1, userdata=0x8140e318) #7 source_dispatch (s=0x81471680) #8 sd_event_dispatch (e=0x8140e6e0) #9 sd_event_run (e=0x8140e6e0, timeout=18446744073709551615) #10 manager_loop (m=0x8140e318) #11 main (argc=4, argv=0xbfb1b254) OK, let's see what we have got here: (gdb) p x->prepare_index $2 = 0 (gdb) p y->prepare_index $3 = 2 So we are comparing the new sd_event_source with the first one in the queue. This is bad. Let's move to shuffle_up first. (gdb) frame 1 (gdb) p k $4 = 0 Right. So shuffle_up doesn't iterate more than once here. It has only swapped item 0 and 2. The prepare queue looks like this now: (null) e=1 pri=0 pi=0 fd=19 bus-input e=0 pri=0 pi=9 fd=18 bus-input e=1 pri=0 pi=11 fd=12 It doesn't look like a correct order judging by how prepare_event (sd-event.c) works. The last bus-input above is pretty much broken because s->prepare callback won't be called anymore. Am I wrong to believe that it should have swapped 2 and 1, not 2 and 0? Lennart, can you fix Prioq or correct me if I'm wrong, please? > This has been debugged on v225, but AFAICS master has the same issues. I'm debugging this now on v226 now. -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)
Hi. There were many reports of "Looping too fast. Throttling execution a little" behavior but they never got anywhere. Not this time. At least for this particular case. Initially I was able to reproduce this issue just by calling `systemctl restart some_specific_service` - then most of further `systemctl` actions (except status) caused systemd to enter an infinite event loop. Long story short, I found out that entering some garbage on /run/systemd/private with netcat breaks systemd equally well. `systemctl daemon-reexec` fixes it. But before you decide to break yours PID 1 event loop, I recommend the following gdb script, because it provides some possibly interesting output: #v+ b event_prepare commands 1 set $size = e->prepare->n_items set $enabled_after_disabled = 0 set $i = 0 while $i < $size set $s = (sd_event_source*)e->prepare->items[$i].data if $s->type == SOURCE_IO printf "%s e=%d pri=%d pi=%u fd=%d\n", \ $s->description, $s->enabled, $s->priority, \ $s->pending_iteration, $s->io.fd else printf "%s e=%d\n", $s->description, $s->enabled end if $i++ > 0 if $s->enabled == SD_EVENT_ON && $previous->enabled == SD_EVENT_OFF set $enabled_after_disabled = 1 end end set $previous = $s end if $enabled_after_disabled print "XXX shouldn't happen?" else continue end end #v- Now let's follow this. Output shortened for brevity. 1. Attach to systemd and let it run. You will most likely see some event source, not of particular interest, like this: bus-input e=1 pri=0 pi=0 fd=12 2. All is good. Run `nc -U /run/systemd/private` bus-input e=1 pri=0 pi=0 fd=18 bus-input e=1 pri=0 pi=0 fd=12 3. We are here too. Enter a newline. bus-input e=1 pri=0 pi=0 fd=12 bus-input e=0 pri=0 pi=15 fd=18 4. This bus-input event source got disabled by source_dispatch, because bus_socket_auth_verify_server returned -EIO. Now wait, hit Ctrl+C, generate some events with systemctl - whatever. bus-input e=0 pri=0 pi=15 fd=18 bus-input e=1 pri=0 pi=0 fd=12 $1 = "XXX shouldn't happen?" 5. The event loop is broken now. It haven't entered an infinite loop *yet* but calls like `systemctl restart whatever` will cause it. The reason is that prepare callbacks in event_prepare (sd-event.c) aren't called anymore - the for loop there breaks on the first disabled source. The prepare callback of the bus that systemctl talks on (most importantly sd_bus_get_events) is called only once and sets POLLIN|POLLOUT flags. That POLLOUT is left there as long as the client is on the bus and causes an infinite event loop. When we exit that hanging systemctl, systemd quits looping but the event loop is still broken. That disabled bus-input from point 4 is left there forever and prevents prepare callbacks of the enabled event sources to run. So, how many bugs are here? It seems that there are other errors than can happen in sd-bus / bus-socket, which bus_process_internal (sd-bus.c) doesn't handle and leaves the disabled event source sitting there forever. Those disabled event sources are: - a memory leak? - very good at breaking event_prepare (sd-event.c). What's going on with order in that "prepare" Prioq? This has been debugged on v225, but AFAICS master has the same issues. -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
Lennart Poettering wrote: > On Fri, 24.07.15 11:07, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote: > >> Unfortunately one cannot specify ConsistsOf in a unit file, which >> is a really annoying limitation. > > That limitation exists for a reason: systemd loads unit files lazily: > only units that are referenced by some other unit are loaded. By reference you mean a reference that causes a unit file to be loaded like Wants? I understand that ConsistsOf is not (would not be) such a reference, but TBH I don't quite understand why. Is this something to do with "positive" and "inverse" dependencies and PartOf being already a positive one? (I'm staring at the UnitDependency enum). I kinda understand it was made this way mainly or even only with instance units in mind. Correct? > Thus, just sticking a unit file somewhere, and writing ConsistsOf= > into it, would generally not work, since the dep would never be > considered unless you also have a dep from something else on it. To > avoid this confusion we simply don't support it at all. What I've actually tried after learning about PartOf some time ago: # foo.target [Unit] Wants=a.service b.service c.service ConsistsOf=a.service b.service c.service so I can start/stop/restart a bunch of services with systemctl. Both lists in one place, so it would be hard to forget about something while making changes. Single file to edit - neat. Just perfect - that's what I thought until a moment later. > (Only way to make this work would be by allowing ConsistsOf= deps via > .consistsof subdirs with symlinks like we support it for .wants, and > then have ConsistsOf= in the [Install] section, if you follow what I > mean). .consistsof and [Install]/PartOf would sound reasonable, just like .wants and [Install]/WantedBy. [Install]/ConsistsOf seems wrong. But how will this solve anything? Is .wants different from Wants? -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
Lennart Poettering wrote: > Daurnimator wrote: >> Lennart Poettering wrote: >> >>> Maybe we can change the manager core to propagate Reload() calls >>> for unit type that do not support it natively to other units >>> listed in PropagateReloadsTo= and then become a NOP. >>> >>> Or in other words: invoking reload on a target that knows no >>> PropagateReloadsTo= should continue to return an error. But if >>> such deps are defined, it should become a silent NOP and >>> propagate the event. >>> >>> Could you file an RFP issue on github asking for this? [or even >>> better, send a PR with a patch... ;-) ] >> >> ReloadPropagatedFrom= would seem to be more useful here. > > Well, ReloadPropagateFrom= is the inverse of PropagateReloadsTo=. If > there is a dep of the first kind from A to B, there's always a dep of > the second kind from B to A, and vice versa. > >> Why should reloading a target error in the first place? ==> why not >> just a NOP? > > Hides bugs? reloading a target makes no sense, unless you use it for > reload propagation. But stopping and restarting a target already makes sense if you use PartOf=foo.target. Unfortunately one cannot specify ConsistsOf in a unit file, which is a really annoying limitation. -- kjk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Notification socket and chroot vs PrivateNetwork conflict (abstract vs file-system)
On Tue, 2014-12-09 at 17:28 +0100, Lennart Poettering wrote: > On Tue, 09.12.14 16:24, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote: > >> Currently notify socket is unavailable in chrooted services (again) >> unless you bind mount it there. Is there perhaps another, less >> cumbersome way? >> >> So far notify socket was: >> [snip change history] >> >> So... would it be acceptable to have two notify sockets, one >> abstract and one normal, the latter only set for services with >> PrivateNetwork or - better maybe - explicitly selectable? Any other >> ideas? > > Hmm, but what would you do for a service that has both > PrivateNetwork and chroot enabled? Well, PrivateNetwork is clearly asking for trouble... A socket doesn't really look like a right tool for the job in this case. I know Unix signals were previously discarded in https://bugzilla.redhat.com/show_bug.cgi?id=833105 Dunno what's left. > Ideas? > > I figure we could open a new mount namespace and mount the file > system socket into the chroot, but not sure I like the idea... I don't know what else is possible, sorry. Anyone? -- K. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Notification socket and chroot vs PrivateNetwork conflict (abstract vs file-system)
Hi. Currently notify socket is unavailable in chrooted services (again) unless you bind mount it there. Is there perhaps another, less cumbersome way? So far notify socket was: 1. abstract socket commit 8c47c7325fa1ab72febf807f8831ff24c75fbf45 notify: add minimal readiness/status protocol for spawned daemons 2. file-system socket commit 91b22f21f3824c1766d34f622c5bbb70cbe881a8 core: move abstract namespace sockets to /dev/.run Now that we have /dev/.run there's no need to use abstract namespace sockets. So, let's move things to /dev/.run, to make things more easily discoverable and improve compat with chroot() and fs namespacing. 3. abstract socket again commit 29252e9e5bad3b0bcfc45d9bc761aee4b0ece1da manager: turn notify socket into abstract namespace socket again sd_notify() should work for daemons that chroot() as part of their initilization, hence it's a good idea to use an abstract namespace socket which is not affected by chroot. 4. file-system socket again commit 7181dbdb2e3112858d62bdaea4f0ad2ed685ccba core: move notify sockets to /run and $XDG_RUNTIME_DIR A service with PrivateNetwork= cannot access abstract namespace sockets of the host anymore, hence let's better not use abstract namespace sockets for this, since we want to make sure that PrivateNetwork= is useful and doesn't break sd_notify(). So... would it be acceptable to have two notify sockets, one abstract and one normal, the latter only set for services with PrivateNetwork or - better maybe - explicitly selectable? Any other ideas? -- K. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
