Re: [systemd-devel] systemd --user fails to start a user service at the first time
On Thu, Oct 28, 2021 at 10:25 PM Andrei Borzenkov wrote: > On 29.10.2021 04:54, Han wrote: > > Hi, > > > > I'm a newbie to systemd. I encountered a strange problem when using > > systemd user > > service in Debian 10 (hardware: Raspberry Pi 4), systemd version 241. > > > > I posted this question on stackoverflow but didn't get answers yet. Hence > > trying to ask here. My apologies if this is too basic. > > > >1. I created a new service unit file at here: > >/home/pi/.config/systemd/user/foo.service > > > > its content looks like this: > > > > [Service] > > ExecStart=/home/pi/test/foo > > WorkingDirectory=/home/pi/test > > > > > >1. I tried to start this service, but it failed: > > > > $ systemctl --user start foo > > Failed to start foo.service: Unit foo.se > > Does it work after > > systemctl --user daemon-reload > > ? > Yes, it worked after `daemon-reload`. Thank you so much! Han > > rvice not found. > > > > However, systemd can list this unit file when doing this: > > > > $systemctl --user list-unit-files --type service | grep foo > > foo.service static > > > > Moreover, when I added [Install] section in the unit file: > > > > [Install] > > WantedBy=multi-user.target > > > > User instance does not have this target. > > > and run $systemctl --user enable foo , it worked. > > > > Even more, after that I removed the unit file, and recreated the unit > file > > without the [Install] section, now I start the service and the original > > problem is no longer seen. > > > > So it seems like only when I try to create a new user service for the > first > > time on the system, without using [Install], it will fail to start. > > > > Any ideas why this is happening? (btw, I don't want to have [Install] for > > this service.) > > > > Or is this a known issue fixed in a later release? > > > > Thanks > > > > Han > > > >
Re: [systemd-devel] run only a single service at a time
On 28.10.2021 16:04, Olaf Hering wrote: > There is A.timer and its A.service, and B.timer and B.service. > Both A and B do not know about each other per default. > Both timers fire in their own cadence. > Both services have their unpredictable time until they finish. > So it may happen that A.service is started while B.service is still active. > > But, unfortunately both services may touch the same files while they run. > > Does systemd have a way to serialize execution of such units, so that > starting of A.service is delayed until B.service is done, and via versa? > Not that I am aware of. Similar questions (or requests) came up in the past. > Before=/After= may not apply, at least the docs say nothing about timer > driven units. > It has nothing to do with timer. After/Before are only effective if both start jobs are queued for execution. If one unit is already started, then After/Before becomes noop. If A has "After: B" and B has "After: A" and both are attempted to be started, it is a loop and systemd will drop one of conditions. How start of these units is triggered is irrelevant. > > I might be able to add some locking to A.service and B.service with some > creative ExecStartPre/Post= in A.service.d/lock.conf ... > > > Olaf >
Re: [systemd-devel] systemd --user fails to start a user service at the first time
On 29.10.2021 04:54, Han wrote: > Hi, > > I'm a newbie to systemd. I encountered a strange problem when using > systemd user > service in Debian 10 (hardware: Raspberry Pi 4), systemd version 241. > > I posted this question on stackoverflow but didn't get answers yet. Hence > trying to ask here. My apologies if this is too basic. > >1. I created a new service unit file at here: >/home/pi/.config/systemd/user/foo.service > > its content looks like this: > > [Service] > ExecStart=/home/pi/test/foo > WorkingDirectory=/home/pi/test > > >1. I tried to start this service, but it failed: > > $ systemctl --user start foo > Failed to start foo.service: Unit foo.se Does it work after systemctl --user daemon-reload ? rvice not found. > > However, systemd can list this unit file when doing this: > > $systemctl --user list-unit-files --type service | grep foo > foo.service static > > Moreover, when I added [Install] section in the unit file: > > [Install] > WantedBy=multi-user.target > User instance does not have this target. > and run $systemctl --user enable foo , it worked. > > Even more, after that I removed the unit file, and recreated the unit file > without the [Install] section, now I start the service and the original > problem is no longer seen. > > So it seems like only when I try to create a new user service for the first > time on the system, without using [Install], it will fail to start. > > Any ideas why this is happening? (btw, I don't want to have [Install] for > this service.) > > Or is this a known issue fixed in a later release? > > Thanks > > Han >
Re: [systemd-devel] [EXT] Re: Output from `tee' is not showing up in system journal consistently on some systems
On Thu, Oct 28, 2021 at 4:27 PM Mitchel Humpherys wrote: > > On Thu, Oct 28, 2021 at 3:18 PM Michael Biebl wrote: > > > > Might be another instance of > > https://github.com/systemd/systemd/issues/2913 > > > > You can verify by checking your whole journal, not just "-u > > tee_test.service". > > That's it!!! I'm also curious if anyone knows what system configuration Debian has that affects this? I can't reproduce this issue there (i.e. the race doesn't seem to exist).
[systemd-devel] systemd --user fails to start a user service at the first time
Hi, I'm a newbie to systemd. I encountered a strange problem when using systemd user service in Debian 10 (hardware: Raspberry Pi 4), systemd version 241. I posted this question on stackoverflow but didn't get answers yet. Hence trying to ask here. My apologies if this is too basic. 1. I created a new service unit file at here: /home/pi/.config/systemd/user/foo.service its content looks like this: [Service] ExecStart=/home/pi/test/foo WorkingDirectory=/home/pi/test 1. I tried to start this service, but it failed: $ systemctl --user start foo Failed to start foo.service: Unit foo.service not found. However, systemd can list this unit file when doing this: $systemctl --user list-unit-files --type service | grep foo foo.service static Moreover, when I added [Install] section in the unit file: [Install] WantedBy=multi-user.target and run $systemctl --user enable foo , it worked. Even more, after that I removed the unit file, and recreated the unit file without the [Install] section, now I start the service and the original problem is no longer seen. So it seems like only when I try to create a new user service for the first time on the system, without using [Install], it will fail to start. Any ideas why this is happening? (btw, I don't want to have [Install] for this service.) Or is this a known issue fixed in a later release? Thanks Han
Re: [systemd-devel] [EXT] Re: Output from `tee' is not showing up in system journal consistently on some systems
On Thu, Oct 28, 2021 at 3:18 PM Michael Biebl wrote: > > Might be another instance of > https://github.com/systemd/systemd/issues/2913 > > You can verify by checking your whole journal, not just "-u tee_test.service". That's it!!! Damn, the userspace workarounds are a little nasty... On the original bug report [1], Lennart wrote: > This is a race. We get the client PID with SCM_CREDENTIALS and then try to > read _CMDLINE/_COMM/_EXEC and the cgroupd ata from /proc quickly but at that > time the process might already have died. > > To fix this properly we need SCM_COMM or so, to get the process > cmdline/comm/exe, and SCM_CGROUPS to get the cgroup data in a race free > fashion. Until this is added to the kernel this will continue to be racy. > These items are listed on the plumbers wishlist, because we need this from > the kernel folks. > ... > The right fix is to get cgroup metadata sent along in the message. There > where even kernel patches to add that, but the submitter dropped the ball > unfortunately. Does anyone happen to have a link to the patches? [1] https://bugs.freedesktop.org/show_bug.cgi?id=50184 (also posted the above response to the github issue)
Re: [systemd-devel] [EXT] Re: Output from `tee' is not showing up in system journal consistently on some systems
Might be another instance of https://github.com/systemd/systemd/issues/2913 You can verify by checking your whole journal, not just "-u tee_test.service". Am Do., 28. Okt. 2021 um 21:54 Uhr schrieb Mitchel Humpherys : > > On Thu, Oct 28, 2021 at 12:35 AM Ulrich Windl > wrote: > > > > ANother random idea: Did you experiment with tee option > > "--output-error=..."? > > Just gave that a shot and didn't get any additional output :(
Re: [systemd-devel] [EXT] Re: Output from `tee' is not showing up in system journal consistently on some systems
On Thu, Oct 28, 2021 at 12:35 AM Ulrich Windl wrote: > > ANother random idea: Did you experiment with tee option "--output-error=..."? Just gave that a shot and didn't get any additional output :(
[systemd-devel] run only a single service at a time
There is A.timer and its A.service, and B.timer and B.service. Both A and B do not know about each other per default. Both timers fire in their own cadence. Both services have their unpredictable time until they finish. So it may happen that A.service is started while B.service is still active. But, unfortunately both services may touch the same files while they run. Does systemd have a way to serialize execution of such units, so that starting of A.service is delayed until B.service is done, and via versa? Before=/After= may not apply, at least the docs say nothing about timer driven units. I might be able to add some locking to A.service and B.service with some creative ExecStartPre/Post= in A.service.d/lock.conf ... Olaf pgpKSCG6u9LCV.pgp Description: Digitale Signatur von OpenPGP
Re: [systemd-devel] [EXT] Question about timestamps in the USER_RECORD spec
On Do, 28.10.21 11:46, Arian van Putten (arian.vanput...@gmail.com) wrote: > Indeed it mentions it; but after careful reading there is no normative > suggestion to actually adhere to it. (no SHOULD and definitely not a MUST, > not even a RECOMMENDED). > > They just say that to increase interoperability no more than 53 bits of > integer precision should be assumed without making a clear normative > decision about it. The only normative part in that section is that > numbers consist of an integer part and a fractional part. > > They also say that implementations are allowed to set any limits on the > range and precision of numbers accepted. > > So yeah Lennart seems to be technically correct. Even when reading the RFC > by the letter. BTW: https://github.com/systemd/systemd/pull/21168 Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] [EXT] Question about timestamps in the USER_RECORD spec
Indeed it mentions it; but after careful reading there is no normative suggestion to actually adhere to it. (no SHOULD and definitely not a MUST, not even a RECOMMENDED). They just say that to increase interoperability no more than 53 bits of integer precision should be assumed without making a clear normative decision about it. The only normative part in that section is that numbers consist of an integer part and a fractional part. They also say that implementations are allowed to set any limits on the range and precision of numbers accepted. So yeah Lennart seems to be technically correct. Even when reading the RFC by the letter. On Thu, Oct 28, 2021 at 9:21 AM Ulrich Windl < ulrich.wi...@rz.uni-regensburg.de> wrote: > >>> Arian van Putten schrieb am 26.10.2021 um > 10:41 in > Nachricht > : > > Hey list, > > > > I'm reading the https://systemd.io/USER_RECORD/ spec and I have a > question > > > > There are some fields in the USER_RECORD spec which are described as > > "unsigned 64 bit integer values". Specifically the fields describing > > time. > > > > However JSON lacks integers and only has doubles [0]; which would mean 53 > > That's nonsense: JSON _has_ integers, but they are restricted (See: 6. > Numbers in RFC 7159) > > int = zero / ( digit1-9 *DIGIT ) > > That was some stupid design decision IMHO. > > > bit integer precision is about the maximum we can reach. It's unclear to > > The RFC mentions "IEEE 754-2008 binary64 (double precision) numbers" > > > me from the spec whether I should use doubles to encode these fields or > use > > strings. Would it be possible to further clarify it? If it is indeed a > > number literal; this means the maximum date we can encode is > > 9007199254740991 which corresponds to Tuesday, June 5, 2255 . This > > honestly is too soon in the future for my comfort. I suggest encoding 64 > > bit integers as string literals instead to avoid the truncation problem. > > > > [0] https://datatracker.ietf.org/doc/html/rfc7159#section-6 > > > > >
[systemd-devel] Antw: [EXT] Re: Output from `tee' is not showing up in system journal consistently on some systems
ANother random idea: Did you experiment with tee option "--output-error=..."? >>> Mitchel Humpherys schrieb am 27.10.2021 um 18:50 in Nachricht : > On Wed, Oct 27, 2021 at 1:52 AM Colin Guthrie wrote: >> >> Mitchel Humpherys wrote on 26/10/2021 21:16: >> > On my Manjaro and Ubuntu systems I'm not seeing all of the "pizza" lines >> > (logs pasted here [3]). On Debian I see the "pizza" and "pie" lines >> > interleaved as expected. It also works as expected when I run the script >> > without systemd on Manjaro. >> > >> > Any ideas what's going on here? Why am I not seeing all of the output >> > from `tee' on some systems? >> > >> > [2] https://github.com/mgalgs/systemd-tee-output-issue >> >> Looking at the output there, the only thing I can see that's slightly >> odd is that the "pie" output comes from the service's main pid (as >> expected) but as tee is forked off the output there that *is* captured >> is from a different pid each time. >> >> So I wonder if this is some kind of cgroup race thing? i.e. the forked >> off process is not (always) detected as being part of the unit in >> question and thus isn't logged against the unit? If this is the case is >> the a bash trick you can use to buffer the output back to the parent >> process - e.g. just surrounding the command in parenthesis or something? >> (I'm not a bash expert so no idea if this would work as a workaround!). >> Appreciate any code change to work around this isn't ideal anyway, but >> just trying to help debug the underlying problem. >> >> This is just a random guess and might not at all be how the logging or >> cgroup handing works! > > Interesting thought! I think it's totally expected for `tee' to have a > different PID. Your comment got me curious about the cgroup situation > in the working vs. non-working scenarios, but it does appear that the > `tee' processes are appropriately cgroup'd. I'm pasting some mid-tee > `status' output below (captured with `while :; do systemctl --user > status tee_test.service; done > /tmp/statuses.txt' and some grepping). > > First, for reference, here's a mid-tee `status' from my Debian 11 > environment where logging is working as expected: > > ● tee_test.service - Test teeing under systemd > Loaded: loaded > (/home/mgalgs/.config/systemd/user/tee_test.service; disabled; vendor > preset: enabled) > Active: active (running) since Tue 2021-10-26 11:44:07 PDT; 21h ago >Main PID: 487 (tee_test.sh) > Tasks: 2 (limit: 4679) > Memory: 3.2M > CPU: 5min 49.049s > CGroup: > /user.slice/user-1000.slice/user@1000.service/app.slice/tee_test.service > ├─ 487 /bin/bash /usr/local/bin/tee_test.sh > └─229327 tee -a /tmp/testtee.log > > Oct 27 08:57:46 pi-hole-test tee_test.sh[229282]: i shall eat 75937 > slices of pizza > Oct 27 08:57:46 pi-hole-test tee_test.sh[487]: i shall eat 75937 slices of > pie > Oct 27 08:57:47 pi-hole-test tee_test.sh[229293]: i shall eat 75938 > slices of pizza > Oct 27 08:57:47 pi-hole-test tee_test.sh[487]: i shall eat 75938 slices of > pie > Oct 27 08:57:48 pi-hole-test tee_test.sh[229304]: i shall eat 75939 > slices of pizza > Oct 27 08:57:48 pi-hole-test tee_test.sh[487]: i shall eat 75939 slices of > pie > Oct 27 08:57:49 pi-hole-test tee_test.sh[229315]: i shall eat 75940 > slices of pizza > Oct 27 08:57:49 pi-hole-test tee_test.sh[487]: i shall eat 75940 slices of > pie > Oct 27 08:57:50 pi-hole-test tee_test.sh[229327]: i shall eat 75941 > slices of pizza > Oct 27 08:57:50 pi-hole-test tee_test.sh[487]: i shall eat 75941 slices of > pie > > And here are two `status'es from my Manjaro environment, where logging > isn't working consistently. In the first case the logs were missing in > the system journal. The second case was one of the odd cases where the > logs actually came through. > > Case 1 (logs missing): > Status: > ● tee_test.service - Test teeing under systemd > Loaded: loaded > (/home/mgalgs/.config/systemd/user/tee_test.service; disabled; vendor > preset: enabled) > Active: active (running) since Wed 2021-10-27 08:55:04 PDT; 15min ago >Main PID: 3791090 (tee_test.sh) > Tasks: 2 (limit: 38124) > Memory: 1.0M > CPU: 3.874s > CGroup: > /user.slice/user-1000.slice/user@1000.service/app.slice/tee_test.service > ├─3791090 /bin/bash > /home/mgalgs/src/systemd-tee-output-issue/tee_test.sh > └─3841065 tee -a /tmp/testtee.log > > Oct 27 09:10:11 grinchel tee_test.sh[3791090]: i shall eat 906 slices of pie > Oct 27 09:10:12 grinchel tee_test.sh[3791090]: i shall eat 907 slices of pie > Oct 27 09:10:13 grinchel tee_test.sh[3791090]: i shall eat 908 slices of pie > Oct 27 09:10:14 grinchel tee_test.sh[3791090]: i shall eat 909 slices of pie > Oct 27 09:10:15 grinchel tee_test.sh[3791090]: i shall eat 910 slices of pie > Oct 27 09:10:16 grinchel tee_test.sh[3791090]: i shall eat 911 slices of pie > Oct 27 09:10:17 grinchel tee_test.sh[3791090]: i sh
[systemd-devel] Antw: [EXT] Question about timestamps in the USER_RECORD spec
>>> Arian van Putten schrieb am 26.10.2021 um 10:41 >>> in Nachricht : > Hey list, > > I'm reading the https://systemd.io/USER_RECORD/ spec and I have a question > > There are some fields in the USER_RECORD spec which are described as > "unsigned 64 bit integer values". Specifically the fields describing > time. > > However JSON lacks integers and only has doubles [0]; which would mean 53 That's nonsense: JSON _has_ integers, but they are restricted (See: 6. Numbers in RFC 7159) int = zero / ( digit1-9 *DIGIT ) That was some stupid design decision IMHO. > bit integer precision is about the maximum we can reach. It's unclear to The RFC mentions "IEEE 754-2008 binary64 (double precision) numbers" > me from the spec whether I should use doubles to encode these fields or use > strings. Would it be possible to further clarify it? If it is indeed a > number literal; this means the maximum date we can encode is > 9007199254740991 which corresponds to Tuesday, June 5, 2255 . This > honestly is too soon in the future for my comfort. I suggest encoding 64 > bit integers as string literals instead to avoid the truncation problem. > > [0] https://datatracker.ietf.org/doc/html/rfc7159#section-6
