Re: [systemd-devel] user service not starting on login
On Fri, May 10, 2019 at 7:57 AM Mantas Mikulėnas wrote: > A direct conversion of jackdbus to a systemd service would look like this > – because of the way jackdbus is written, it always needs that extra > command to be sent over D-Bus (either by running `jack_control start` or by > using the manual tools): > > (~/.config/systemd/user/jack.service) > [Service] > Type=dbus > BusName=org.jackaudio.service > ExecStart=/usr/bin/jackdbus auto > #ExecStartPost=/usr/bin/jack_control start > #ExecStartPost=/usr/bin/gdbus call -e -d org.jackaudio.service -o > /org/jackaudio/Controller -m org.jackaudio.JackControl.StartServer > ExecStartPost=/usr/bin/busctl call --user org.jackaudio.service > /org/jackaudio/Controller org.jackaudio.JackControl StartServer > > ...and KillSignal=SIGKILL, I guess. I wonder why it needs that. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user service not starting on login
On Fri, May 10, 2019 at 5:22 AM Matt Zagrabelny wrote: > Greetings, > > I am attempting to get a user service running on my session login. > > The unit is called jack. I've enabled it via: > > $ systemctl --user enable jack > > When I boot up the system and log in I see that it is inactive. I can > start it manually without issue: > > $ systemctl --user status jack > ● jack.service - JACK 2 >Loaded: loaded (/home/theophilus/.config/systemd/user/jack.service; > enabled; vendor preset: enabled) >Active: inactive (dead) > > $ journalctl --user -u jack -b > -- Logs begin at Thu 2019-05-09 20:54:31 CDT, end at Thu 2019-05-09 > 21:13:53 CDT. -- > -- No entries -- > > $ systemctl --user cat jack > # /home/theophilus/.config/systemd/user/jack.service > [Unit] > Description=JACK 2 > Before=sound.target > Before=pulseaudio.service > Requires=dbus.socket > > [Service] > Type=dbus > BusName=org.jackaudio.Controller > Among other things, the bus name seems to be incorrect. In jack2-dbus the only claimed name appears to be "org.jackaudio.service". > ExecStart=/usr/bin/jack_control start > The jack_control program does not spawn nor directly execute the actual jackd daemon. Instead it *remotely* activates org.jackaudio.service through D-Bus (you'll see jackdbus under the dbus.service cgroup), then sends it a single method call and exits. In other words, jack_control is not a Type=dbus service, it's a oneshot script that controls another Type=dbus service. You can imagine that it's just a wrapper around `dbus-send` or `gdbus call`, and is something you'd instead use in JACK's *ExecStartPost=*. A direct conversion of jackdbus to a systemd service would look like this – because of the way jackdbus is written, it always needs that extra command to be sent over D-Bus (either by running `jack_control start` or by using the manual tools): (~/.config/systemd/user/jack.service) [Service] Type=dbus BusName=org.jackaudio.service ExecStart=/usr/bin/jackdbus auto #ExecStartPost=/usr/bin/jack_control start #ExecStartPost=/usr/bin/gdbus call -e -d org.jackaudio.service -o /org/jackaudio/Controller -m org.jackaudio.JackControl.StartServer ExecStartPost=/usr/bin/busctl call --user org.jackaudio.service /org/jackaudio/Controller org.jackaudio.JackControl StartServer I think you can even make manual jack_control invocations start your systemd service using this: (~/.local/share/dbus-1/services/org.jackaudio.service) [D-BUS Service] Name=org.jackaudio.service Exec=/bin/false SystemdService=jackservice (Side note: The filename of the latter file should actually be dbus-1/services/org.jackaudio.service.service [sic], but because JACK already used the incorrect one in /usr/share, let's stick to it.) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] user service not starting on login
Greetings, I am attempting to get a user service running on my session login. The unit is called jack. I've enabled it via: $ systemctl --user enable jack When I boot up the system and log in I see that it is inactive. I can start it manually without issue: $ systemctl --user status jack ● jack.service - JACK 2 Loaded: loaded (/home/theophilus/.config/systemd/user/jack.service; enabled; vendor preset: enabled) Active: inactive (dead) $ journalctl --user -u jack -b -- Logs begin at Thu 2019-05-09 20:54:31 CDT, end at Thu 2019-05-09 21:13:53 CDT. -- -- No entries -- $ systemctl --user cat jack # /home/theophilus/.config/systemd/user/jack.service [Unit] Description=JACK 2 Before=sound.target Before=pulseaudio.service Requires=dbus.socket [Service] Type=dbus BusName=org.jackaudio.Controller ExecStart=/usr/bin/jack_control start ExecStop=/usr/bin/jack_control stop ExecStopPost=/usr/bin/pkill -9 jackdbus SuccessExitStatus=0 RemainAfterExit=true #Restart=always #RestartSec=5 [Install] WantedBy=default.target WantedBy=sound.target $ systemctl --user start jack $ systemctl --user status jack ● jack.service - JACK 2 Loaded: loaded (/home/theophilus/.config/systemd/user/jack.service; enabled; vendor preset: enabled) Active: active (exited) since Thu 2019-05-09 21:15:29 CDT; 4s ago Process: 1079 ExecStart=/usr/bin/jack_control start (code=exited, status=0/SUCCESS) Main PID: 1079 (code=exited, status=0/SUCCESS) May 09 21:15:29 calvary systemd[672]: Starting JACK 2... May 09 21:15:29 calvary jack_control[1079]: --- start May 09 21:15:29 calvary systemd[672]: Started JACK 2. What am I missing? Thanks for the help! -m ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] EFI loader partition unknown
On Wed, May 8, 2019 at 3:52 AM Lennart Poettering wrote: > > eOn Mo, 06.05.19 10:26, Chris Murphy (li...@colorremedies.com) wrote: > > > Waiting for device (parent + 2 partitions) to appear... > > Found writable 'root' partition (UUID > > 87d5a92987174be9ad216482074d1409) of type xfs without verity on > > partition #2 (/dev/vda2) > > Found writable 'esp' partition (UUID b5aa8c29b4ab4021b2b22326860bda97) > > of type vfat on partition #1 (/dev/vda1) > > [Detaching after fork from child process 8612] > > Successfully forked off '(sd-dissect)' as PID 8612. > > Mounting xfs on /tmp/dissect-h21Wp5 (MS_RDONLY|MS_NODEV "")... > > Failed to mount /dev/vda2 (type xfs) on /tmp/dissect-h21Wp5 > > (MS_RDONLY|MS_NODEV ""): Device or resource busy > > Failed to mount dissected image: Device or resource busy > > Failed to read /etc/hostname: No such file or directory > > /etc/machine-id file is empty. > > (sd-dissect) failed with exit status 1. > > Failed to acquire image metadata: Protocol error > > [Inferior 1 (process 8608) exited with code 01] > > (gdb) quit > > > > > > Looks like it wants to mount root, but it's already mounted and hence > > busy. Btrfs lets you do that, ext4 and XFS don't, they need to be bind > > mounted instead. Just a guess. > > OK, so this is misleading. "systemd-dissect" does two things: first it > tries to make sense of the partition table and what to do with > it. Then it tries to extract OS metadata from the file systems itself > (i.e. read /etc/machine-id + /etc/os-release). The latter part fails > for some reason (probably because the mount options are different than > what is already mounted, some file systems are more allergic to that > than others), but that shouldn't really matter, as that is > not used by systemd-gpt-generator. > > Hmm, one question, which boot loader are you using? Note that the ESP GRUB which I think is mainly as a bootmanager and to support Secure Boot, and EFI STUB as the actual bootloader. > mounting logic only works if the boot loader tells us which partition > it was booted from. This is an extra check to ensure that we only > mount the correct ESP, the one that was actually used. In other words, > this only works with a boot loader that implements the relevant part > of https://systemd.io/BOOT_LOADER_INTERFACE.html i.e. the I'm willing to bet 99% of the world's computers have one ESP. In fact I'd be surprised if it's even 1% that have 2 or more. I'm not convinced the UEFI spec really sanctions 2 or more ESPs even if it's not outright proscribed. The language of the spec consistently says there's one. > LoaderDevicePartUUID efi var. We probably should document that better > in systemd-gpt-generator(8) though, could you please file a bug about > that? > > In other words: use sd-boot, and all that stuff just works. With grub > it doesn't, it doesn't let us know any of the bits we want to know. OK requiring a specific bootloader really isn't consistent with the language used in the discoverable partitions specification. If in reality what's needed to automatically mount to /efi is not only a partition type GUID but some bootloader specific metadata inserted into memory at boot time, that's not a generic solution like the other discoverable partition types. https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Explain status "Loaded: not-found (Reason: No such file or directory)"
Am 09.05.19 um 12:25 schrieb Ulrich Windl: > I'm developing a service and getting the status of my target gives: > ● iotwatch.target >Loaded: not-found (Reason: No such file or directory) >Active: active since Thu 2019-05-09 12:00:56 CEST; 18min ago > > I guess it's not a file named "Reason" that's missing. Despite of my > recommendation to create helpful error messages, can you explain what it > means? > Even after an strace I could not find out what is missing. iotwatch.target and the large amount of posts about abolsute basics with no information like contents of unit files is annoying and frankly starting your conversations with "Cause of the trouble (and possible reason for systemd's unpopularity) seems to be rather arbitrary restrictions without reasoning (which is completely against the GNU spirit of seeking for limitless software)" won't get you far when you state that you lived under a stone for nearly a decade and now are starting by zero with systemd ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] refcount of bus returned from sd_bus_default_system
Thank you Lennart for detailed explanation. I realized a few things in sd-bus behavior (and in my wrong approach to default bus -- yes I forgot about hello message) when I debugged the thing earlier today, and now your explanation cleared that up pretty nicely to me. I see again that sd-bus design is well thought-out, I'm glad to work with it, and I hope to keep up to high design quality in c++ binding on top of it (the quality is also increasing the more I understand some details of sd-bus). Perhaps more detailed docs on sd-bus would help a lot.. I will fix the approach to default busses on my side. This is a very special corner case in sdbus-c++ used in order to be able to create plain empty messages, which are then used as storage of Variant class, without user having to provide an existing bus connection themselves. Perhaps that could be refactored in future -- but disadvantage is that users won't be able to create self-contained Variants (they will have to provide their bus connection explicitly to create a Variant). Thanks a lot! Take care. On Thu, May 9, 2019, 17:02 Lennart Poettering wrote: > On Mi, 08.05.19 22:50, Stanislav Angelovič (angelovi...@gmail.com) wrote: > > > Heya, > > > > when writing sdbus-c++, we've observed that sd_bus_default_system > function > > called in a fresh new thread returns a bus with initial ref count 2. We > > built our code upon that assumption -- we had to unref the bus twice when > > the thread local storage got freed, otherwise we'd have gotten > > memory leaks. > > Uh, no, this was never the right thing to do. > > > Now it broke, however, because in systemd v242, the initial ref count is > 1. > > Is that a conscious change? Can we build upon the guarantee that it will > > always be 1? (1 actually seems reasonable, unlike 2). > > Originally, in sd-bus each bus message (i.e. each sd_bus_message > object) keeps a ref on the bus connection (i.e. each sd_bus object) it > belongs to. Moreover, if a message is queued into a bus connection it > is referenced by it. Thus you have a ref cycle, as long as a mesage is > queued into a bus and not processed yet. The intention then was that > whenever you want to get rid of a bus at the end of your > thread/process you'd flush out the bus anyway (because otherwise you > lose queued but unwritten messages), at which point the cycle would be > cleared up as soon as all messages are written. > > Also note, that when a bus connection is set up a "Hello" message is > immediately enqueued into it (this is required by the spec). Thus, by > default there'd be two references onto the bus connection object: the > one you own yourself as the caller, and the one from the Hello bus > message queued onto it. > > To flush out messages you should use the sd_bus_flush() call. it's > blocking, and all it does is force out all queued outgoing messages > that are not written yet, thus emptying the write queue. Then, call > sd_bus_close(), to explicitly terminate the connection. This will > empty the read queue too. At this point there are no messages queued > anymore, i.e. all refs on the bus object must be held by you and not > internally. Finally, get rid of the whole thing by doing > sd_bus_unref(). Since these three calls are often combined, there's > sd_bus_flush_close_unref() to combine them into one. > > Calling sd_bus_flush() is entirely optional btw, it's sufficient to just > call sd_bus_close(). However in that case and pending unwritten > messages are just forgotten, and not written to the connection socket, > and never seen by the receiving side. > > Now you might wonder, why doesn't sd_bus_unref() always implicitly > call sd_bus_flush()? Reffing/unreffing should not be blocking, that's > why. Moreover, the concept of "default" busses of a thread is that > various bits and pieces running in the thread could quickly ask for > the default bus connection, do some stuff with it, enqueue a message > or two, then unref it again. Other code might then pick it up again, > enqueue some more messages on them, unref it again, and so on. Then, > when the thread is about to end, there might be a number of messages > queued: before exiting from the thread they should be flushed out, but > only then, there's no need to do so earlier. Thus, in the earlier > uses of the bus connection your'd just unref the bus at the end, but > when you are finally done with the default connection altogether youd' > use the more powerful sd_bus_flush_close_unref() instead, and do all > the work synchronously, that the earlier users didn't bother to wait > for. > > Note that when an sd_bus connection is attached to an sd_event event > loop, the sd_bus_flush() + sd_bus_close() is done automatically when > the "exit" phase of the event loop is entered. > > Now, as it turns out, many users of sd-bus didn't get all of the above > right: they simply unreffed the bus after use, and enver bothered to > flush out any queued messages not written yet, and thus leaked >
Re: [systemd-devel] Wtrlt: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)
On Do, 09.05.19 15:52, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > (Sorry, I didn't sent to the list before) > >>> Ulrich Windl schrieb am 09.05.2019 um > >>> 14:25 > in Nachricht <5cd44c9a.ed38.00a...@rz.uni-regensburg.de>: > Michael Biebl schrieb am 09.05.2019 um 12:26 in > Nachricht > > : > > > Hi > > > > > > Am Do., 9. Mai 2019 um 12:22 Uhr schrieb Ulrich Windl > > > : > > > > > >> Despite of that I'm missing a "systemctl validate ..." command. That way > > >> I > > > wouldn't need to execute start, status, stop, just to find out that some > > > settings are rejected. > > > > > > There is "systemd-analyze verify". > > > That sounds interesting, but it seems I'll have to be root to use > > it, and These limitations where lifted a long time ago. Please update. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can I enable/disable a target?
On Do, 09.05.19 12:27, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > Hi! > > Whenever I try to enable or disable a target (that exists), I get > "Failed to execute operation: No such file or directory". What file > or directory, please? Or what is the command trying to say? Well, "systemctl enable" could not find the target unit file in the directories it searches for them. Where did you place the unit file? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Arbitrary restrictions (e.g. for RuntimeDirectory)
On Do, 09.05.19 12:22, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > Hi! > > I had to subscribe to this list, even though I'm no systemd > fan. Still I'll have to deal with it as the distribution we use > switched to systemd... Fantastic lead-in. This is a perfect intro if you are asking for help, it creates the outmost desire in everyone who could help you to do so right-away. > I'm porting my LSB code to systemd, and I'm having some > trouble. Cause of the trouble (and possible reason for systemd's > unpopularity) seems to be rather arbitrary restrictions without > reasoning (which is completely against the GNU spirit of seeking for > limitless software). Hmm, the second paragaph even manages to improve upon the first. Your reader is now as enthusiastic as they could be to help your ASAP! > To be concrete: Why isn't it allowed to use an absolute path for > RuntimeDirectory, and wy isn't even a relative path allowed? In my > case I have a multi-instance daemon, where the instances can be zero > to many. To avoid namespace conflicts, I created a /var/run/ > directroy where all the instances put their stuff (in separate > directories each) The "Runtime" in "RuntimeDirectory" should clarify that /run is where such dirs are created, hence we don't accept absolute dirs: the prefix must be /run, hence why specify it. If you want systemd to create a dir elsewhere, use StateDirectory= (which creates it in /var/lib) or CacheDirectory= (which creates it in /var/cache) or ConfigurationDirectory= which creates it in /etc. These four options map to the four main locations to place service data resources in. Well organized services only use those four places, since they come with clear life-cycle and semantical definitions, and get first class support via the four settings. It's a gentle push that the various services follow established standards and place their stuff there and don't make up entirely random dirs outside of the typical hierarchy. Before systemd v235 the RuntimeDirectory= setting did not support relative paths with "/" included. Starting with 235 it will accept them. Hence, please consider updating, you apparently run an older systemd version. Note that "/var/run" is a legacy alias for "/run". It's highly recommended not to use the former anymore. > Despite of that I'm missing a "systemctl validate ..." command. That > way I wouldn't need to execute start, status, stop, just to find out > that some settings are rejected. "systemd-analyze verify" exists. Since a long long time. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Explain status "Loaded: not-found (Reason: No such file or directory)"
On Do, 09.05.19 12:25, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > Hi! > > I'm developing a service and getting the status of my target gives: > ● iotwatch.target >Loaded: not-found (Reason: No such file or directory) >Active: active since Thu 2019-05-09 12:00:56 CEST; 18min ago > > I guess it's not a file named "Reason" that's missing. Despite of my > recommendation to create helpful error messages, can you explain what it > means? > Even after an strace I could not find out what is missing. "Loaded" is a field that indicates whether the unit definition was properly loaded from the unit file. Here, it's shown as "not-found", which is the value indicating that no unit file by the name "iotwatch.target" could be found. Then, in brackets you get some additional information: here "Reason:" is the field that indicates the reason why the unit file wasn't found, and this usually gives you a UNIX error code, i.e. the text string associated with an "errno" code. "No such file or directory" is the string for ENOENT, i.e. it's the simplest of cases here: there really just was no file found by the name you requested. Typically, when you see "not-found" as "Loaded" value, you'll also see "No such file or directory" as "Reason" value, but there are some other cases, since units are not always synthesized from unit files on disk, but from other concepts too. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] refcount of bus returned from sd_bus_default_system
On Mi, 08.05.19 22:50, Stanislav Angelovič (angelovi...@gmail.com) wrote: > Heya, > > when writing sdbus-c++, we've observed that sd_bus_default_system function > called in a fresh new thread returns a bus with initial ref count 2. We > built our code upon that assumption -- we had to unref the bus twice when > the thread local storage got freed, otherwise we'd have gotten > memory leaks. Uh, no, this was never the right thing to do. > Now it broke, however, because in systemd v242, the initial ref count is 1. > Is that a conscious change? Can we build upon the guarantee that it will > always be 1? (1 actually seems reasonable, unlike 2). Originally, in sd-bus each bus message (i.e. each sd_bus_message object) keeps a ref on the bus connection (i.e. each sd_bus object) it belongs to. Moreover, if a message is queued into a bus connection it is referenced by it. Thus you have a ref cycle, as long as a mesage is queued into a bus and not processed yet. The intention then was that whenever you want to get rid of a bus at the end of your thread/process you'd flush out the bus anyway (because otherwise you lose queued but unwritten messages), at which point the cycle would be cleared up as soon as all messages are written. Also note, that when a bus connection is set up a "Hello" message is immediately enqueued into it (this is required by the spec). Thus, by default there'd be two references onto the bus connection object: the one you own yourself as the caller, and the one from the Hello bus message queued onto it. To flush out messages you should use the sd_bus_flush() call. it's blocking, and all it does is force out all queued outgoing messages that are not written yet, thus emptying the write queue. Then, call sd_bus_close(), to explicitly terminate the connection. This will empty the read queue too. At this point there are no messages queued anymore, i.e. all refs on the bus object must be held by you and not internally. Finally, get rid of the whole thing by doing sd_bus_unref(). Since these three calls are often combined, there's sd_bus_flush_close_unref() to combine them into one. Calling sd_bus_flush() is entirely optional btw, it's sufficient to just call sd_bus_close(). However in that case and pending unwritten messages are just forgotten, and not written to the connection socket, and never seen by the receiving side. Now you might wonder, why doesn't sd_bus_unref() always implicitly call sd_bus_flush()? Reffing/unreffing should not be blocking, that's why. Moreover, the concept of "default" busses of a thread is that various bits and pieces running in the thread could quickly ask for the default bus connection, do some stuff with it, enqueue a message or two, then unref it again. Other code might then pick it up again, enqueue some more messages on them, unref it again, and so on. Then, when the thread is about to end, there might be a number of messages queued: before exiting from the thread they should be flushed out, but only then, there's no need to do so earlier. Thus, in the earlier uses of the bus connection your'd just unref the bus at the end, but when you are finally done with the default connection altogether youd' use the more powerful sd_bus_flush_close_unref() instead, and do all the work synchronously, that the earlier users didn't bother to wait for. Note that when an sd_bus connection is attached to an sd_event event loop, the sd_bus_flush() + sd_bus_close() is done automatically when the "exit" phase of the event loop is entered. Now, as it turns out, many users of sd-bus didn't get all of the above right: they simply unreffed the bus after use, and enver bothered to flush out any queued messages not written yet, and thus leaked memory. With 1b3f9dd759ca0ea215e7b89f8ce66d1b724497b9 that was addressed: now sd-bus tries to be a bit smarter than before: if it notices, that a bus connection is only referenced by a message queued into it but nothing else, and that there's no chance that it can be referenced again, we'll detect this and release the entire object automatically, knowing that it could never correctly be flushed out anyway, since noone owns a ref to it anymore. Or in other words: the ref cycles are now detected, and dealt with. What does this mean for users? Well, if you are using sd-bus correctly not much changes: make sure you flush/close your connections at the end of each thread, to make sure you don't lose messages you enqueued but that were never written out. If you don't do that correctly though it's not a memory leak anymore as before if you forget to do that. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Wtrlt: Antw: Re: Can I enable/disable a target?
Am Do., 9. Mai 2019 um 15:52 Uhr schrieb Ulrich Windl : > > (Sorry, I didn't send to the list before) > >>> Ulrich Windl schrieb am 09.05.2019 um > >>> 14:28 > in Nachricht <5cd44cae.ed38.00a...@rz.uni-regensburg.de>: > Michael Biebl schrieb am 09.05.2019 um 12:29 in > Nachricht > > : > > > Am Do., 9. Mai 2019 um 12:27 Uhr schrieb Ulrich Windl > > > : > > >> > > >> Hi! > > >> > > >> Whenever I try to enable or disable a target (that exists), I get > > >> "Failed to > > > > > execute operation: No such file or directory". What file or directory, > > > please? Or what is the command trying to say? > > > > > > Can you share the target unit please. > > > Into what location have you installed the unit file? > > > > This is after fixing obvious errors: > > # systemctl enable iotwatch.target > > Failed to execute operation: No such file or directory > > # cat /run/systemd/generator.late/iotwatch.target > > [Unit] > > Description=iotwatch I/O performance monitor > > Documentation=man:iotwatch@.service(8) man:iotwatch-generator(8) > > After=nss-lookup.target time-sync.target paths.target > > Wants=iotwatch@VAR.service > > > > [Install] > > WantedBy=multi-user.target This doesn't make sense. You generate an ephemeral runtime unit in /run but you then try to enable it in /etc. To make it easier to help, you should give us an idea/overview what you are trying to achieve. What you did so far (and why), what environment you are using etc. It's really hard to give you a good answer when we don't even tell us the systemd version and distro you are using. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Arbitrary restrictions (e.g. for RuntimeDirectory)
09.05.2019 13:22, Ulrich Windl пишет: > Hi! > > I had to subscribe to this list, even though I'm no systemd fan. Still I'll > have to deal with it as the distribution we use switched to systemd... > > I'm porting my LSB code to systemd, and I'm having some trouble. Cause of the > trouble (and possible reason for systemd's unpopularity) seems to be rather > arbitrary restrictions without reasoning (which is completely against the GNU > spirit of seeking for limitless software). > > To be concrete: Why isn't it allowed to use an absolute path for > RuntimeDirectory, Wild guess - RuntimeDirectory is about security and permitting arbitrary path here rather contradicts this goal. > and wy isn't even a relative path allowed? In my case I have a multi-instance > daemon, where the instances can be zero to many. To avoid namespace > conflicts, I created a /var/run/ directroy systemd does it for you. > where all the instances put their stuff (in separate directories each) > > Trying "RuntimeDirectory=/%i" inside @.service isn't > "accepted". Still the instances start, can be checked and stopped, but there > is a message when stopped saying > systemd[1]: [/usr/lib/systemd/system/@.service:12] Runtime directory > is not valid, ignoring assignment: /%i This works here; use of multilevel paths is even documented; granted, ability to use specifiers is not that obvious from manual page. > > As "mkdir -p" exists for at least 25 years, I wonder what this is all about. > I tentatively suspect that being less aggressive may actually help ... > Despite of that I'm missing a "systemctl validate ..." command. That way I > wouldn't need to execute start, status, stop, just to find out that some > settings are rejected. > > Regards, > Ulrich > > > > ___ > 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
Re: [systemd-devel] Explain status "Loaded: not-found (Reason: No such file or directory)"
09.05.2019 13:25, Ulrich Windl пишет: > Hi! > > I'm developing a service and getting the status of my target gives: > ● iotwatch.target >Loaded: not-found (Reason: No such file or directory) >Active: active since Thu 2019-05-09 12:00:56 CEST; 18min ago > > I guess it's not a file named "Reason" that's missing. Despite of my > recommendation to create helpful error messages, can you explain what it > means? > Even after an strace I could not find out what is missing. > It means that unit definition file (iotwatch.target) was not found in any directory where systemd looks for it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inherit MAC address for bridge from physical device
09.05.2019 12:49, Olaf Hering пишет: > With ifcfg or NetworkManager it is possible to have generic config files for > every system to configure a bridge on the one and only physical network > interface. See the examples below how such configuration looks like. > > With systemd-networkd it is apparently required to specify the MAC in the > configuration. Could you be more specific where exactly it is required? Example in manual page does not set any MAC; do you imply that this example is non-functioning? Example 3. A bridge with two enslaved links # /etc/systemd/network/25-bridge-static.network [Match] Name=bridge0 [Network] Address=192.168.0.15/24 Gateway=192.168.0.1 DNS=192.168.0.1 # /etc/systemd/network/25-bridge-slave-interface-1.network [Match] Name=enp2s0 [Network] Bridge=bridge0 # /etc/systemd/network/25-bridge-slave-interface-2.network [Match] Name=wlp3s0 [Network] Bridge=bridge0 This creates a bridge and attaches devices "enp2s0" and "wlp3s0" to it. The bridge will have the specified static address and network assigned, and a default route via the specified gateway will be added. The specified DNS server will be added to the global list of DNS resolvers. > As a result, such configuration is per host and not generic anymore. Is there > a knob I overlooked so that the bridge uses the MAC from the physical > interface? If not, are there plans to fix that? > > Olaf > > ==> /etc/sysconfig/network/ifcfg-br0 <== > BOOTPROTO='dhcp' > BRIDGE='yes' > BRIDGE_PORTS='eth0' > BRIDGE_STP='off' > STARTMODE='auto' > ==> /etc/sysconfig/network/ifcfg-eth0 <== > BOOTPROTO='none' > STARTMODE='auto' > > ==> /etc/NetworkManager/system-connections/eth <== > [connection] > id=eth > uuid=---- > type=ethernet > interface-name=eth0 > master=br0 > permissions= > slave-type=bridge > [ethernet] > mac-address-blacklist= > ==> /etc/NetworkManager/system-connections/br <== > [connection] > autoconnect-slaves=1 > id=br > interface-name=br0 > permissions= > type=bridge > uuid=---- > [bridge] > stp=false > [ipv4] > dhcp-timeout=2147483647 > dns-search= > method=auto > [ipv6] > addr-gen-mode=stable-privacy > dns-search= > ip6-privacy=0 > method=auto > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Any defined exit code for a generator?
On Do, 09.05.19 12:29, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > Hi! > > The manual page of generators does not talk about exit codes in case > of an error. Is there any handling of exit codes in systemd? We log about non-zero exit statusses from generator executables, but continue otherwise. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Wtrlt: Antw: Re: Any defined exit code for a generator?
(Sorry, I didn't send to the list before) >>> Ulrich Windl schrieb am 09.05.2019 um >>> 14:34 in Nachricht <5cd44ccd.ed38.00a...@rz.uni-regensburg.de>: Michael Biebl schrieb am 09.05.2019 um 12:43 in Nachricht > : > > Am Do., 9. Mai 2019 um 12:29 Uhr schrieb Ulrich Windl > > : > >> > >> Hi! > >> > >> The manual page of generators does not talk about exit codes in case of an > > error. Is there any handling of exit codes in systemd? > > > > exit codes > 0 returned by the generator are treated as errors and > > systemd will log about this when the generator is run. You'll get an > > error message like this in the journal: > > > > Mai 09 12:41:46 pluto systemd[1]: Reloading. > > Mai 09 12:41:47 pluto systemd[5481]: > > /lib/systemd/system-generators/test failed with exit status 1. > > OK, I see: I had missed those. Once you know what you are looking for, it's > easy to find. > > > > > Can you be more specific about you are trying to do? > > Write a generator ;-) > Actually my generator has a few problems it can detect and report through > exit codes, so I wondered what systemd does with those: > > I have: > * Success > * Failure (generic) > * Syntax error > * Permission problem > * Installation problem (e.g. missing files) > * Configuration problem (e.g. missing configuration files) > * Unexpected problem (most likely a programming error in the generator) > > Regards, > Ulrich > > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Wtrlt: Antw: Re: Can I enable/disable a target?
(Sorry, I didn't send to the list before) >>> Ulrich Windl schrieb am 09.05.2019 um >>> 14:28 in Nachricht <5cd44cae.ed38.00a...@rz.uni-regensburg.de>: Michael Biebl schrieb am 09.05.2019 um 12:29 in Nachricht > : > > Am Do., 9. Mai 2019 um 12:27 Uhr schrieb Ulrich Windl > > : > >> > >> Hi! > >> > >> Whenever I try to enable or disable a target (that exists), I get "Failed > >> to > > > execute operation: No such file or directory". What file or directory, > > please? Or what is the command trying to say? > > > > Can you share the target unit please. > > Into what location have you installed the unit file? > > This is after fixing obvious errors: > # systemctl enable iotwatch.target > Failed to execute operation: No such file or directory > # cat /run/systemd/generator.late/iotwatch.target > [Unit] > Description=iotwatch I/O performance monitor > Documentation=man:iotwatch@.service(8) man:iotwatch-generator(8) > After=nss-lookup.target time-sync.target paths.target > Wants=iotwatch@VAR.service > > [Install] > WantedBy=multi-user.target > > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Wtrlt: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)
(Sorry, I didn't sent to the list before) >>> Ulrich Windl schrieb am 09.05.2019 um >>> 14:25 in Nachricht <5cd44c9a.ed38.00a...@rz.uni-regensburg.de>: Michael Biebl schrieb am 09.05.2019 um 12:26 in Nachricht > : > > Hi > > > > Am Do., 9. Mai 2019 um 12:22 Uhr schrieb Ulrich Windl > > : > > > >> Despite of that I'm missing a "systemctl validate ..." command. That way I > > wouldn't need to execute start, status, stop, just to find out that some > > settings are rejected. > > > > There is "systemd-analyze verify". > > That sounds interesting, but it seems I'll have to be root to use it, and > the files have to be "installed" before they can be checked: > > systemd-analyze verify systemd/iotwatch.target.in > Failed to open /dev/tty0: Permission denied > Failed to load systemd/iotwatch.target.in: Invalid argument > > Maybe I just did not understand how to use it (this time as root): > # systemd-analyze verify /usr/lib/iotwatch/iotwatch.target.in > Failed to load /usr/lib/iotwatch/iotwatch.target.in: Invalid argument > # systemd-analyze verify /usr/lib/systemd/system/iotwatch@.service > Failed to load /usr/lib/systemd/system/iotwatch@.service: Invalid argument > # systemd-analyze verify iotwatch@.service > Failed to load iotwatch@.service: Invalid argument > > (I'm glad that my C-compiler provides better error messages) > > Regards, > Ulrich > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Wtrlt: Antw: Re: Can I enable/disable a target?
(Sorry, I didn't sent to the list before) >>> Ulrich Windl schrieb am 09.05.2019 um 13:22 in Nachricht <5cd44c66.ed38.00a...@rz.uni-regensburg.de>: Michael Biebl schrieb am 09.05.2019 um 12:29 in Nachricht > : > > Am Do., 9. Mai 2019 um 12:27 Uhr schrieb Ulrich Windl > > : > >> > >> Hi! > >> > >> Whenever I try to enable or disable a target (that exists), I get "Failed to > > > execute operation: No such file or directory". What file or directory, > > please? Or what is the command trying to say? > > > > Can you share the target unit please. > > Into what location have you installed the unit file? > > Good question: I should have been created by a generator, so the location > should be /run/systemd/generator*, but I could not find it. I have the > feeling that "systemctl daemon-reload" did not trigger the generator (which > is at /usr/lib/systemd/system-generators/iotwatch-generator). > > OK, trying to run the generator manually I found that it exits with 1, not > creating the target. Wouldn't it be nice if systemd would log failed > generators? > > So I fixed the generator (it can still exit with 1, but no longer in the > success-case). > > Now I have some "bad" state: > # systemctl status iotwatch.target >● iotwatch.target - iotwatch I/O performance monitor >Loaded: loaded (/run/systemd/generator.late/iotwatch.target; bad; vendor > preset: disabled) >Active: inactive (dead) since Thu 2019-05-09 12:39:45 CEST; 39min ago > ... > > What is that "bad" referring to? The target > /run/systemd/generator.late/iotwatch.target looks like this: > # cat /run/systemd/generator.late/iotwatch.target > [Unit] > Description=iotwatch I/O performance monitor > Documentation=man:iotwatch@.service(8) man:iotwatch-generator(8) > After=nss-lookup.target time-sync.target paths.target > Wants=iotwatch@VAR.service > > [Install] > WantedBy=multi-user.target > > Regards, > Ulrich > > > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can I enable/disable a target?
[Please do not send this message to me privately only] Am Do., 9. Mai 2019 um 13:22 Uhr schrieb Ulrich Windl : > > >>> Michael Biebl schrieb am 09.05.2019 um 12:29 in > Nachricht > : > > Am Do., 9. Mai 2019 um 12:27 Uhr schrieb Ulrich Windl > > : > >> > >> Hi! > >> > >> Whenever I try to enable or disable a target (that exists), I get "Failed > to > > execute operation: No such file or directory". What file or directory, > > please? Or what is the command trying to say? > > > > Can you share the target unit please. > > Into what location have you installed the unit file? > > Good question: I should have been created by a generator, so the location > should be /run/systemd/generator*, but I could not find it. I have the feeling > that "systemctl daemon-reload" did not trigger the generator (which is at > /usr/lib/systemd/system-generators/iotwatch-generator). > > OK, trying to run the generator manually I found that it exits with 1, not > creating the target. Wouldn't it be nice if systemd would log failed > generators? It does. You can find the log message in the journal. See my other email > So I fixed the generator (it can still exit with 1, but no longer in the > success-case). > > Now I have some "bad" state: > # systemctl status iotwatch.target > ● iotwatch.target - iotwatch I/O performance monitor >Loaded: loaded (/run/systemd/generator.late/iotwatch.target; bad; vendor > preset: disabled) >Active: inactive (dead) since Thu 2019-05-09 12:39:45 CEST; 39min ago > ... > > What is that "bad" referring to? The target > /run/systemd/generator.late/iotwatch.target looks like this: > # cat /run/systemd/generator.late/iotwatch.target > [Unit] > Description=iotwatch I/O performance monitor > Documentation=man:iotwatch@.service(8) man:iotwatch-generator(8) > After=nss-lookup.target time-sync.target paths.target > Wants=iotwatch@VAR.service > > [Install] > WantedBy=multi-user.target -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Any defined exit code for a generator?
Am Do., 9. Mai 2019 um 12:29 Uhr schrieb Ulrich Windl : > > Hi! > > The manual page of generators does not talk about exit codes in case of an > error. Is there any handling of exit codes in systemd? exit codes > 0 returned by the generator are treated as errors and systemd will log about this when the generator is run. You'll get an error message like this in the journal: Mai 09 12:41:46 pluto systemd[1]: Reloading. Mai 09 12:41:47 pluto systemd[5481]: /lib/systemd/system-generators/test failed with exit status 1. Can you be more specific about you are trying to do? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can I enable/disable a target?
Am Do., 9. Mai 2019 um 12:27 Uhr schrieb Ulrich Windl : > > Hi! > > Whenever I try to enable or disable a target (that exists), I get "Failed to > execute operation: No such file or directory". What file or directory, > please? Or what is the command trying to say? Can you share the target unit please. Into what location have you installed the unit file? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Any defined exit code for a generator?
Hi! The manual page of generators does not talk about exit codes in case of an error. Is there any handling of exit codes in systemd? Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Can I enable/disable a target?
Hi! Whenever I try to enable or disable a target (that exists), I get "Failed to execute operation: No such file or directory". What file or directory, please? Or what is the command trying to say? Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Arbitrary restrictions (e.g. for RuntimeDirectory)
Hi Am Do., 9. Mai 2019 um 12:22 Uhr schrieb Ulrich Windl : > Despite of that I'm missing a "systemctl validate ..." command. That way I > wouldn't need to execute start, status, stop, just to find out that some > settings are rejected. There is "systemd-analyze verify". -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Explain status "Loaded: not-found (Reason: No such file or directory)"
Hi! I'm developing a service and getting the status of my target gives: ● iotwatch.target Loaded: not-found (Reason: No such file or directory) Active: active since Thu 2019-05-09 12:00:56 CEST; 18min ago I guess it's not a file named "Reason" that's missing. Despite of my recommendation to create helpful error messages, can you explain what it means? Even after an strace I could not find out what is missing. Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Arbitrary restrictions (e.g. for RuntimeDirectory)
Hi! I had to subscribe to this list, even though I'm no systemd fan. Still I'll have to deal with it as the distribution we use switched to systemd... I'm porting my LSB code to systemd, and I'm having some trouble. Cause of the trouble (and possible reason for systemd's unpopularity) seems to be rather arbitrary restrictions without reasoning (which is completely against the GNU spirit of seeking for limitless software). To be concrete: Why isn't it allowed to use an absolute path for RuntimeDirectory, and wy isn't even a relative path allowed? In my case I have a multi-instance daemon, where the instances can be zero to many. To avoid namespace conflicts, I created a /var/run/ directroy where all the instances put their stuff (in separate directories each) Trying "RuntimeDirectory=/%i" inside @.service isn't "accepted". Still the instances start, can be checked and stopped, but there is a message when stopped saying systemd[1]: [/usr/lib/systemd/system/@.service:12] Runtime directory is not valid, ignoring assignment: /%i As "mkdir -p" exists for at least 25 years, I wonder what this is all about. Despite of that I'm missing a "systemctl validate ..." command. That way I wouldn't need to execute start, status, stop, just to find out that some settings are rejected. Regards, Ulrich ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Inherit MAC address for bridge from physical device
With ifcfg or NetworkManager it is possible to have generic config files for every system to configure a bridge on the one and only physical network interface. See the examples below how such configuration looks like. With systemd-networkd it is apparently required to specify the MAC in the configuration. As a result, such configuration is per host and not generic anymore. Is there a knob I overlooked so that the bridge uses the MAC from the physical interface? If not, are there plans to fix that? Olaf ==> /etc/sysconfig/network/ifcfg-br0 <== BOOTPROTO='dhcp' BRIDGE='yes' BRIDGE_PORTS='eth0' BRIDGE_STP='off' STARTMODE='auto' ==> /etc/sysconfig/network/ifcfg-eth0 <== BOOTPROTO='none' STARTMODE='auto' ==> /etc/NetworkManager/system-connections/eth <== [connection] id=eth uuid=---- type=ethernet interface-name=eth0 master=br0 permissions= slave-type=bridge [ethernet] mac-address-blacklist= ==> /etc/NetworkManager/system-connections/br <== [connection] autoconnect-slaves=1 id=br interface-name=br0 permissions= type=bridge uuid=---- [bridge] stp=false [ipv4] dhcp-timeout=2147483647 dns-search= method=auto [ipv6] addr-gen-mode=stable-privacy dns-search= ip6-privacy=0 method=auto pgpaHsfjiLPgq.pgp Description: Digitale Signatur von OpenPGP ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
