Re: [systemd-devel] How to find out the processes systemd-shutdown is waiting for?
Hi all, Am Do, 3. Mär 2022, um 19:02, schrieb Lennart Poettering: > On Mi, 02.03.22 17:50, Lennart Poettering (lenn...@poettering.net) wrote: > >> That said, we could certainly show both the comm field and the PID of >> the offending processes. I am prepping a patch for that. > > See: https://github.com/systemd/systemd/pull/22655 > > Lennart now that is some service. Thanks for looking into this that quickly! I think we solved our issues, and it seems they were not related to docker at all. The mistake was on our side. We were using the PowerOff() method from org.freedesktop.systemd1.Manager [1], which the manpage advices against. When using PowerOff() from org.freedesktop.login1.Manager, which as per the manpage is the preferred way to trigger a shutdown from GUI, things seem to work okay. That is, this shows the described issues: ``` dbus-send --system --print-reply --type='method_call' --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.PowerOff ``` while this works ok: ``` dbus-send --system --print-reply --type='method_call' --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.PowerOff boolean:false ``` [1] https://www.freedesktop.org/software/systemd/man/org.freedesktop.systemd1.html#Methods [2] https://www.freedesktop.org/software/systemd/man/org.freedesktop.login1.html#Methods Posting this here as it might be of interest to someone on the list. Best regards, Manuel
Re: [systemd-devel] [EXT] [systemd‑devel] How to sychronize service START with STOP of mount units?
>> I currently have no idea how to express this in systemd terms. If someone on > >> this list could provide some advice, it would be much appreciated. > > As for the recent "firmware flashing" thread I think it would be best to > handle that via some boot parameter and something like a "boot once" boot > entry > that adds that specific parameter. > I also think the clearing should be best done in initrd before the real root > filesystem is mounted. That should be most flexible. The more I think about it, the more I like your approach. Thanks, Ulrich.
[systemd-devel] How to find out the processes systemd-shutdown is waiting for?
Hi all, My embedded system is shutting down rather slow, and I'd like to find out the responsible processes. [ 7668.571133] systemd-shutdown[1]: Waiting for process: dockerd, python3 [ 7674.670684] systemd-shutdown[1]: Sending SIGKILL to remaining processes... Is there a way for systemd-shutdown to give me the PID of the processes it waits for? There are quite a few docker and python3 services running on my system and the lines printed above doesn't help much. I'm using systemd 244 (244.5+). Thanks, Manuel
[systemd-devel] How to sychronize service START with STOP of mount units?
Hi all, We'd like to implement a factory reset for an embedded device we are working on. I think the cleanest approach would be a factory-reset.target which WANTS/REQUIRES reboot.target + a factory-reset.service which wipes the persistent storage. The thing is, START of factory-reset.service would need to be synchronized with the STOPs of some mount units which got started during system boot. For easier understanding: System start: 1. Start path-to-first.mount 2. Start path-to-second.mount System halt: 1. Stop path-to-second.mount 2. Stop path-to-first.mount Factory reset: 1. Stop path-to-second.mount 2. Start factory-reset.service, wiping /path/to/first/* 3. Stop path-to-first.mount I currently have no idea how to express this in systemd terms. If someone on this list could provide some advice, it would be much appreciated. Thanks in advance and best regards, Manuel
[systemd-devel] Why is using fstab the preferred approach according to systemd.mount man page?
Hi all, currently, the systemd.mount man page [1] claims that "In general, configuring mount points through /etc/fstab is the preferred approach". Why is that? One would assume systemd proposing use of systemd.mount units over /etc/fstab. [1] https://www.freedesktop.org/software/systemd/man/systemd.mount.html#fstab Regards, Manuel
Re: [systemd-devel] Examples to distinguish Before=/After= and Wants=/Requires=/BindsTo=
Am Mi, 15. Sep 2021, um 19:23, schrieb Andrei Borzenkov: > On 15.09.2021 18:15, Manuel Wagesreither wrote: > > Hello all, > > > > I'm onboarding some collegues who don't have much experience with systemd. > > One thing I would like to focus on is the difference between Before=/After= > > and Wants=/Requires=/BindsTo in systemd units. > > > > I think it would get immediately clear if could provide them an example > > where we want one but not the other. Unfortunately I've got problems coming > > up with such an example. In my use cases, whenever I needed an After= I > > needed an Wants= as well. > > > > Can you come up with something good? > > > > No. B After A means - select start job for B for execution after start > job for A completes. This directive is only meaningful if you guarantee > that both start jobs are present in the queue. And the only way to > ensure it is to use Wants (or Requires as variant). > > If service B really needs service A to be started before it itself can > be started, you must use After and Wants, otherwise you are open to race > conditions. And if service B does not care if service A is started, then > you do not need After in the first place. > > Of course one can try to ensure that all start jobs are present in queue > by some external means. Like making all units to be WantedBy some > super-unit which is called ... default.target (surprise). But that does > not change underlying requirement, just restricts working case to > starting one single unit. Presumably on system boot :) > I understand. Still, I'm looking for giving the people I teach an example why it made sense to implement it this way. Something else than just saying "that's just how it is, just accept it".
[systemd-devel] Examples to distinguish Before=/After= and Wants=/Requires=/BindsTo=
Hello all, I'm onboarding some collegues who don't have much experience with systemd. One thing I would like to focus on is the difference between Before=/After= and Wants=/Requires=/BindsTo in systemd units. I think it would get immediately clear if could provide them an example where we want one but not the other. Unfortunately I've got problems coming up with such an example. In my use cases, whenever I needed an After= I needed an Wants= as well. Can you come up with something good? Thanks, regards, Manuel
Re: [systemd-devel] systemd-udevd: Race condition when rule starts both a systemd-mount and an unit accessing that mount
Am Sa, 4. Sep 2021, um 18:17, schrieb Andrei Borzenkov:
> On 01.09.2021 14:39, Manuel Wagesreither wrote:
> > Am Mi, 25. Aug 2021, um 18:51, schrieb Andrei Borzenkov:
> >> On Wed, Aug 25, 2021 at 3:44 PM Andrei Borzenkov
> >> wrote:
> >> ...
> >>>> Here's the udev rule:
> >>>> ```
> >>>> ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNEL=="*[0-9]*",
> >>>> ENV{ID_FS_USAGE}=="filesystem", TAG+="systemd",
> >>>> ENV{SYSTEMD_WANTS}+="start-standalone-mender-deployment@media-$name.service",
> >>>> RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no
> >>>> --options=ro --collect $devnode /media/$name"
> >>>> ```
> >>>>
> >>>> And here's the systemd service:
> >>>> It is templated and gets instantiated with "media-sdb1". It therefore
> >>>> has an "After=media-sdb1.mount". I suspect Systemd-udevd executes the
> >>>> ENV{SYSTEMD_WANTS} part before the RUN{program} part. Hence,
> >>>> "media-sdb1.mount" doesn't yet exist when the service gets started, as
> >>>> it gets created a tad later by systemd-mount.
> >>>>
> >>>> ```
> >>>> [Unit]
> >>>> Description=Start standalone Mender deployment (%i)
> >>>> After=%i.mount
> >>>>
> >>>> [Service]
> >>>> Type=oneshot
> >>>> Restart=no
> >>>> ExecStart=/bin/sh /usr/bin/start-standalone-mender-deployment.sh /%I
> >>>> ```
> >>>>
> >> ...
> >>>
> >>> Hmm ... if systemd-mount --property accepts Wants and Before, your
> >>> mount unit could pull in your service unit. I cannot test right now.
> >>>
> >>
> >> Yes, this seems to work, so in principle
> >>
> >> RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no
> >> --options=ro --collect --property
> >> Wants=start-standalone-mender-deployment@media-$name.service $devnode
> >> /media/$name"
> >>
> >> is possible. Unfortunately this starts unit even if mount fails and
> >> systemd-mount does not accept RequiredBy property". It is still
> >> possible to add Requires to service itself.
> >>
> >> [Unit]
> >> Description=Start standalone Mender deployment (%i)
> >> After=%i.mount
> >> Requires=%i.mount
> >>
> >> This will fail the service start job if the mount job fails.
> >>
> >> Wants on mount unit pulls in service, so we are guaranteed to always
> >> have both start jobs - for mount and for service and dependencies are
> >> observed.
> >>
> >
> > I was unaware of the --property option of systemd-mount. It seems to be
> > exactly what I was looking for.
> >
> > Thank you!
> >
> > Unfortunately, while testing, I encountered problems with systemd-mount.
> >
> > Sporadically, `systemd-mount /dev/sdb1 /media/sdb1` results in the
> > following:
> > ```
> > $ journalctl -fu systemd-udevd -u media-sdb1.mount -u dev-sdb1.device -u
> > systemd-fsck@dev-sdb1.service
> > 15:55:46 systemd[1]: media-sdb1.mount: Failed to open
> > /run/systemd/transient/media-sdb1.mount: No such file or directory
> > 15:56:46 systemd-udevd[57294]: sdb1: Spawned process
> > '/usr/bin/systemd-mount /dev/sdb1 /media/sdb1' [57295] is taking longer
> > than 59s to complete
>
> This is not expected with --no-block
>
> > 15:56:46 systemd-udevd[3019]: sdb1: Worker [57294] processing SEQNUM=6665
> > is taking a long time
> > 15:57:16 systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start timed out.
> > 15:57:16 systemd[1]: Timed out waiting for device /dev/sdb1.
> > 15:57:16 systemd[1]: Dependency failed for /media/sdb1.
> > 15:57:16 systemd[1]: media-sdb1.mount: Job media-sdb1.mount/start failed
> > with result 'dependency'.
> > 15:57:16 systemd[1]: Dependency failed for File System Check on /dev/sdb1.
> > 15:57:16 systemd[1]: systemd-fsck@dev-sdb1.service: Job
> > systemd-fsck@dev-sdb1.service/start failed with result 'dependency'.
> > 15:57:16 systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start failed with
> > result 'timeout'.
> > 15:57:16 systemd-udevd[57294]: sdb1: Process '/usr/bin/systemd-mount
> > /dev/sdb1 /media/sdb1' failed with exit code 1.
> > ```
> > (Removed date
Re: [systemd-devel] systemd-udevd: Race condition when rule starts both a systemd-mount and an unit accessing that mount
Am Mi, 25. Aug 2021, um 18:51, schrieb Andrei Borzenkov:
> On Wed, Aug 25, 2021 at 3:44 PM Andrei Borzenkov wrote:
> ...
> > > Here's the udev rule:
> > > ```
> > > ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNEL=="*[0-9]*",
> > > ENV{ID_FS_USAGE}=="filesystem", TAG+="systemd",
> > > ENV{SYSTEMD_WANTS}+="start-standalone-mender-deployment@media-$name.service",
> > > RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no
> > > --options=ro --collect $devnode /media/$name"
> > > ```
> > >
> > > And here's the systemd service:
> > > It is templated and gets instantiated with "media-sdb1". It therefore has
> > > an "After=media-sdb1.mount". I suspect Systemd-udevd executes the
> > > ENV{SYSTEMD_WANTS} part before the RUN{program} part. Hence,
> > > "media-sdb1.mount" doesn't yet exist when the service gets started, as it
> > > gets created a tad later by systemd-mount.
> > >
> > > ```
> > > [Unit]
> > > Description=Start standalone Mender deployment (%i)
> > > After=%i.mount
> > >
> > > [Service]
> > > Type=oneshot
> > > Restart=no
> > > ExecStart=/bin/sh /usr/bin/start-standalone-mender-deployment.sh /%I
> > > ```
> > >
> ...
> >
> > Hmm ... if systemd-mount --property accepts Wants and Before, your
> > mount unit could pull in your service unit. I cannot test right now.
> >
>
> Yes, this seems to work, so in principle
>
> RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no
> --options=ro --collect --property
> Wants=start-standalone-mender-deployment@media-$name.service $devnode
> /media/$name"
>
> is possible. Unfortunately this starts unit even if mount fails and
> systemd-mount does not accept RequiredBy property". It is still
> possible to add Requires to service itself.
>
> [Unit]
> Description=Start standalone Mender deployment (%i)
> After=%i.mount
> Requires=%i.mount
>
> This will fail the service start job if the mount job fails.
>
> Wants on mount unit pulls in service, so we are guaranteed to always
> have both start jobs - for mount and for service and dependencies are
> observed.
>
I was unaware of the --property option of systemd-mount. It seems to be exactly
what I was looking for.
Thank you!
Unfortunately, while testing, I encountered problems with systemd-mount.
Sporadically, `systemd-mount /dev/sdb1 /media/sdb1` results in the following:
```
$ journalctl -fu systemd-udevd -u media-sdb1.mount -u dev-sdb1.device -u
systemd-fsck@dev-sdb1.service
15:55:46 systemd[1]: media-sdb1.mount: Failed to open
/run/systemd/transient/media-sdb1.mount: No such file or directory
15:56:46 systemd-udevd[57294]: sdb1: Spawned process '/usr/bin/systemd-mount
/dev/sdb1 /media/sdb1' [57295] is taking longer than 59s to complete
15:56:46 systemd-udevd[3019]: sdb1: Worker [57294] processing SEQNUM=6665 is
taking a long time
15:57:16 systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start timed out.
15:57:16 systemd[1]: Timed out waiting for device /dev/sdb1.
15:57:16 systemd[1]: Dependency failed for /media/sdb1.
15:57:16 systemd[1]: media-sdb1.mount: Job media-sdb1.mount/start failed with
result 'dependency'.
15:57:16 systemd[1]: Dependency failed for File System Check on /dev/sdb1.
15:57:16 systemd[1]: systemd-fsck@dev-sdb1.service: Job
systemd-fsck@dev-sdb1.service/start failed with result 'dependency'.
15:57:16 systemd[1]: dev-sdb1.device: Job dev-sdb1.device/start failed with
result 'timeout'.
15:57:16 systemd-udevd[57294]: sdb1: Process '/usr/bin/systemd-mount /dev/sdb1
/media/sdb1' failed with exit code 1.
```
(Removed date and hostname for brevity.)
While mounting, I had `watch ls /run/systemd/transient/` running, and could see
that `media-sdb1.mount` pops into existence immediately when invoking
systemd-mount. So whatever tries to access misses it just.
Following to note:
* In the example above, systemd-mount got invoked from the following udev rule:
```
ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNEL=="*[0-9]*",
ENV{ID_FS_USAGE}=="filesystem", RUN{program}+="/usr/bin/systemd-mount $devnode
/media/$name"
```
* I triggered the rule with `udevadm trigger --verbose --action=add /dev/sdb`,
and did --action=remove before triggering again.
* When invoking from the shell, journalctl logs the same. (Minus the
systemd-udevd lines obviously.)
* `/bin/mount /dev/sdb1 /media/sdb1` works always
This whole things seems very flaky, but there seems to be a pattern, as crazy
as that may sound: Triggerung udev rule repeatedly results in the same outcome
(mount working or not); same with invoking manually on shell. But the two are
unrelated. At first it even seemed mounting from the rule ALWAYS fails and from
the shell ALWAYS works, but then I started to observe just a few cases which
proved me wrong. Now it doesn't work anymore either way. That said, yesterday I
had a shell script running which was triggering a similar udev rule repeatadly
~900 times, and mounting worked every single time.
I've got systemd 244 (244.3+) running. The
[systemd-devel] systemd-udevd: Race condition when rule starts both a systemd-mount and an unit accessing that mount
Hello all,
this is my first post on this mailing list and, first of all, I'd like to thank
you and appreciate your work on systemd in general. I admire the logic, the
completeness of the manpages and in general how beautifully things are
engineered. I'm no unix graybeard and systemd saved me from having to learn all
that legacy stuff systemd replaces. Compared to fstab, /etc/network/interfaces
and init.d, systemd is a piece of art.
---
I'm working on an embedded device which should access and scan connected usb
drives for certain files. I seem to witness a race condition with my current
solution. I would ask for advice on how to implement this functionality in a
better way.
When a device /dev/sdb1 is connected, the udev rule below starts BOTH
* a systemd-service "start-standalone-mender-deployment@media-sdb1.service"
* `systemd-mount --no-block --automount=no --options=ro --collect /dev/sdb1
/media/sdb1`
The service then starts a shell script accessing the usb drive. Occasionally,
it says the directory the usb drive is mounted at is empty. When checking
manually, I see it's not. I strongly suspect the script accessed the directory
before the usb drive got mounted there.
Here's the udev rule:
```
ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", KERNEL=="*[0-9]*",
ENV{ID_FS_USAGE}=="filesystem", TAG+="systemd",
ENV{SYSTEMD_WANTS}+="start-standalone-mender-deployment@media-$name.service",
RUN{program}+="/usr/bin/systemd-mount --no-block --automount=no --options=ro
--collect $devnode /media/$name"
```
And here's the systemd service:
It is templated and gets instantiated with "media-sdb1". It therefore has an
"After=media-sdb1.mount". I suspect Systemd-udevd executes the
ENV{SYSTEMD_WANTS} part before the RUN{program} part. Hence, "media-sdb1.mount"
doesn't yet exist when the service gets started, as it gets created a tad later
by systemd-mount.
```
[Unit]
Description=Start standalone Mender deployment (%i)
After=%i.mount
[Service]
Type=oneshot
Restart=no
ExecStart=/bin/sh /usr/bin/start-standalone-mender-deployment.sh /%I
```
Can you confirm my theory?
The only alternative I see is to invoke systemd-mount without --no-block from
the shell script itself. Instead of communicating the mount point (media-sdb1)
via unit template parameter, I would communicate the device path (/dev/sdb1) to
the template unit and pass it on to the shell script, which would determine
mount point based on that.
I'm all ears if you have comments or advice on that. I guess I'm not the first
one implementing something like this.
Regards,
Manuel
P.S.: I won't be able to respond until Sunday Aug 29th.
Re: [systemd-devel] Mobile broadband modems support in systemd-networkd
Hi Bruce, Am Fr, 20. Aug 2021, um 22:01, schrieb Bruce A. Johnson: > Mantas' and Ulrich's responses gave me insights to dig more. Neither the > mbim-cli nor ModemManager sets the IP address on the interface, and some > kind of agent needs to do that. > > When I start the connection using ModemManager, I am able to retrieve > addresses that mmcli displays like the below. If I manually assign the > IPv4 address to the interface and set up the route, I'm able to send > traffic to and from other nodes. I haven't yet looked into how > ModemManager communicates this info to NetworkManager or how things like > a change of address are handled. As I see it, these addresses aren't > really static, because the IPv6 addresses are different from one mobile > session to the next. > > > > > IPv4 configuration | method: static > > | address: 6.147.139.XXX > > | prefix: 30 > > | gateway: 6.147.139.YYY > > | dns: 10.177.0.34, 10.177.0.210 > > | mtu: 1500 > > > > IPv6 configuration | method: static > > | address: 2607:fb90:648f:2648:a5b3:8146:95aa:2955 > > | prefix: 64 > > | gateway: 2607:fb90:648f:2648:68d8:1c67:a27:b968 > > | dns: fd00:976a::9, fd00:976a::10 > > | mtu: 1500 > > > I took a closer look at what's going on with systemd-networkd, and I > found whether I use ModemManager or mbim-cli to connect to the mobile > network, the .network file will be processed, but _only after I restart > systemd-networkd_. I'm not 100% sure this applies to all the applications in the systemd ecosystem (like systemd-networkd), but systemd is reloading .unit, .service, .mount and all the other files there are only after a `systemctl daemon-reload`. That's the intended behaviour. Just wanted to mention this. Can't comment on anything else, though, as I have no clue either. But I'm interested in this topic and am silently monitoring this thread. Regards, Manuel
[systemd-devel] Does After=systemd-udevd.service make my service run after the services started by udev rules?
Hi all,
when I have an udev rule with an ENV{SYSTEMD_WANTS}+="my.service", and
another.service with After=systemd-udevd.service, can I at system boot rely on
my.service to be already run when another.service starts?
Here's the background to the question:
I'm developing an embedded device with autoupdate functionality. It grabs the
new disk image from an usb drive when plugged in. The udev rule and the systemd
units + shell scripts run all fine. The only thing complicating all this is
that at boot into the new system, the udev rule fires as well.
I worked around this in the following way:
* udev-triggered start-update.service runs only if
/persistent/update-running.stamp doesn't yet exist. When started, it creates
this file.
* autoscheduled conclude-update.service contains After=systemd-udevd.service
and removes /persistent/update-running.stamp.
I assumed this would at system boot ensure the start-update.service to be
started before conclude-update.service, hence not doing anything. Until
recently, this seemed to worked fine, but I have received reports making me
believe I was just witnessing a race condition resulting in my favor.
Best regards,
Manuel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] taking time off
Am Di, 15. Jan 2019, um 22:21, schrieb Vito Caputo: > On Tue, Jan 15, 2019 at 09:58:20PM +0100, Michael Biebl wrote: > > Will stop maintaining systemd in debian for a while. > > > > What's going on is just too stupid/crazy. > > > > Michael, as a long-time Debian user, I just wanted to say I appreciate > your work. I'm confident in saying it's no accident that I've been able > to largely ignore systemd on my Debian machines updated over the years. > > Thanks, > Vito Caputo I agree! Thanks for your support in the project! It is not unnoticed. Thanks Manuel Wagesreither ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd dies on one machine but runs okay on another
Hello all, it turned out this problem is entirely unrelated to systemd-timesyncd. I genuinely thought it was related to systemd, as I thought I have ruled out all other possibilities. It turned out I didn't. Sorry for the noise. Manuel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd dies on one machine but runs okay on another
Am Mo, 3. Sep 2018, um 16:47, schrieb Mantas Mikulėnas: > On Mon, Sep 3, 2018 at 3:41 PM Manuel Wagesreither > wrote:>> Hallo all! >> >> I'm working on an embedded project consisting of an host and >> numerous virtual machines and am facing problems related to time >> management. systemd-timesyncd dies on one machine (HOST), but runs >> okay on another (VM2) with identical config.>> >> The project setup is as follows: >> >> HOST: Runs a (heavily) modified Debian with systemd, retrieves time >> via NTP from VM1 using systemd-timesyncd.>> * VM1: Runs openwrt and serves >> time via NTP using chrony >> * VM2: Runs a (heavily) modified Debian with SELINUX and systemd, >>retrieves time via NTP from VM1 using systemd-timesyncd>> * VM3-?: Some >> other VMs which seem to run fine >> >> The symptoms are as follows: >> >> HOST: `systemd-timesyncd.service` is reported as inactive (dead). A >> time update (adjusting the time by 2 days) took place. Then, after >> 5min, the service died. (It always seems to die 5-15min after a time >> update.)>> ``` >> root@HOST:/var/log# systemctl status systemd-timesyncd >> ● systemd-timesyncd.service - Network Time Synchronization >> Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; >> enabled; vendor preset: enabled)>>Drop-In: >> /lib/systemd/system/systemd-timesyncd.service.d >> └─disable-with-time-daemon.conf >> Active: inactive (dead) since Wed 2018-09-05 07:30:02 CEST; 1 day >> 17h left>> Docs: man:systemd-timesyncd.service(8) >>Process: 4724 ExecStart=/lib/systemd/systemd-timesyncd >>(code=exited, status=0/SUCCESS)>> Main PID: 4724 (code=exited, >> status=0/SUCCESS) >> Status: "Idle." >> >> Sep 03 11:51:58 HOST systemd[1]: Starting Network Time >> Synchronization...>> Sep 03 11:51:58 HOST systemd[1]: Started Network Time >> Synchronization.>> Sep 05 07:25:31 HOST systemd-timesyncd[4724]: >> Synchronized to time >> server 192.168.253.1:123 (192.168.253.1).>> Sep 05 07:30:02 HOST >> systemd[1]: Stopping Network Time >> Synchronization...>> Sep 05 07:30:02 HOST systemd[1]: Stopped Network Time >> Synchronization.>> ``` > > Looks like a normal exit, though. What systemd version is this? For > v217 or later I'd expect to see _Status: "Shutting down"_...> > Try starting it with [Service] Environment="SYSTEMD_LOG_LEVEL=debug" > to see more details. With "normal exit" you mean `systemctl stop systemd-timesync`, I suppose? Hmm... I did not invoke this command. I am using systemd 232. And, by the way, may I ask where the "Status" field of `systemctl status systemd-timesyncd` is coming from? Is the content of this field returned by the particular unit or from systemd? I activated verbose logging as per your suggestion, but the output doesn't yield any additional information:``` root@HOST:~# systemctl status systemd-timesyncd ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/run/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d └─disable-with-time-daemon.conf Active: inactive (dead) since Wed 2018-09-05 23:30:01 CEST; 8h ago Docs: man:systemd-timesyncd.service(8) Process: 15355 ExecStart=/lib/systemd/systemd-timesyncd (code=exited, status=0/SUCCESS)Main PID: 15355 (code=exited, status=0/SUCCESS) Status: "Idle." Sep 05 23:29:57 HOST systemd-timesyncd[15355]: poll interval: 32 Sep 05 23:29:57 HOST systemd-timesyncd[15355]: adjust (jump): - 16.125 secSep 05 23:29:41 HOST systemd-timesyncd[15355]: status : 8192 syncSep 05 23:29:41 HOST systemd-timesyncd[15355]: time now : 1536182981.380Sep 05 23:29:41 HOST systemd-timesyncd[15355]: constant : 2 Sep 05 23:29:41 HOST systemd-timesyncd[15355]: offset : +0.000 secSep 05 23:29:41 HOST systemd-timesyncd[15355]: freq offset : - 2177702 (-33 ppm)Sep 05 23:29:41 HOST systemd-timesyncd[15355]: interval/delta/delay/jitter/drift 32s/-16.125s/0.001s/0.001s/-33ppmSep 05 23:30:01 HOST systemd[1]: Stopping Network Time Synchronization...Sep 05 23:30:01 HOST systemd[1]: Stopped Network Time Synchronization. ``` Also, `timedatectl set-ntp yes` doesn't seem to have any effect either. This is the output while systemd-timesyncd was up and running:``` root@HOST:~# timedatectl set-ntp yes root@HOST:~# timedatectl Local time: Wed 2018-09-05 23:49:51 CEST Universal time: Wed 2018-09-05 21:49:51 UTC RTC time: Thu 2018-09-06 06:48:25 Time zone: Europe/Berl
Re: [systemd-devel] systemd-timesyncd dies on one machine but runs okay on another
Sorry, some typos. The time server is VM1, not VM3. Please find a corrected version below. ~~~ Hello all! I'm working on an embedded project consisting of an host and numerous virtual machines and am facing problems related to time management. systemd-timesyncd dies on one machine (HOST), but runs okay on another (VM2) with identical config. The project setup is as follows: HOST: Runs a (heavily) modified Debian with systemd, retrieves time via NTP from VM1 using systemd-timesyncd. * VM1: Runs openwrt and serves time via NTP using chrony * VM2: Runs a (heavily) modified Debian with SELINUX and systemd, retrieves time via NTP from VM1 using systemd-timesyncd * VM3-?: Some other VMs which seem to run fine The symptoms are as follows: HOST: `systemd-timesyncd.service` is reported as inactive (dead). A time update (adjusting the time by 2 days) took place. Then, after 5min, the service died. (It always seems to die 5-15min after a time update.) ``` root@HOST:/var/log# systemctl status systemd-timesyncd ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d └─disable-with-time-daemon.conf Active: inactive (dead) since Wed 2018-09-05 07:30:02 CEST; 1 day 17h left Docs: man:systemd-timesyncd.service(8) Process: 4724 ExecStart=/lib/systemd/systemd-timesyncd (code=exited, status=0/SUCCESS) Main PID: 4724 (code=exited, status=0/SUCCESS) Status: "Idle." Sep 03 11:51:58 konnektor systemd[1]: Starting Network Time Synchronization... Sep 03 11:51:58 konnektor systemd[1]: Started Network Time Synchronization. Sep 05 07:25:31 konnektor systemd-timesyncd[4724]: Synchronized to time server 192.168.253.1:123 (192.168.253.1). Sep 05 07:30:02 konnektor systemd[1]: Stopping Network Time Synchronization... Sep 05 07:30:02 konnektor systemd[1]: Stopped Network Time Synchronization. ``` VM2:`systemd-timesyncd.service` is reported to be active (running), time updates occur regularly. ``` root@VM2:~# systemctl status systemd-timesyncd ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d └─disable-with-time-daemon.conf Active: active (running) since Thu 2018-08-30 20:53:19 CEST; 5 days ago Docs: man:systemd-timesyncd.service(8) Main PID: 12125 (systemd-timesyn) Status: "Synchronized to time server 192.168.253.1:123 (192.168.253.1)." Tasks: 2 (limit: 4915) CGroup: /system.slice/systemd-timesyncd.service └─12125 /lib/systemd/systemd-timesyncd Aug 30 20:53:19 k-basisdienste systemd[1]: Starting Network Time Synchronization... Aug 30 20:53:19 k-basisdienste systemd[1]: Started Network Time Synchronization. Aug 30 20:44:53 k-basisdienste systemd-timesyncd[12125]: Synchronized to time server 192.168.253.1:123 (192.168.253.1). ``` On this VM, we DO have the problem of the time jumping by 15s every 50s or so. I think is caused by the time server (chrony) over-compensating a clockdrift. Hence, I think this is totally unrelated. I just mention it for the sake of completeness. When I query chrony on VM1 for statistics on the connected clients, it as well reports that the other VMs are updated every ~50s, while the last update to the host system occured hours ago. ``` root@VM1:~# chronyc clients Hostname NTP Drop Int IntL Last Cmd Drop Int Last === 192.168.253.14 11054 0 6 - 1 0 0 - - 192.168.253.10 11053 0 6 - 1 0 0 - - 192.168.253.2 11053 0 6 - 1 0 0 - - 192.168.253.18 11053 0 6 - 1 0 0 - - 192.168.253.3 390 0 10 - 237m 0 0 - - COMMENT: This is the host machine ``` systemd-timesyncd on both HOST and VM2 are using an identical unit file and also timesyncd.conf (Please find both below.) Questions I'm asking myself are: * What could be the reason for systemd-timesyncd dying on the host machine? How can I find details? * If I interpret the output correctly, systemd-timesyncd died with an exit code of 0 (success). How is that possible? Shouldn't it remain active, just the way it does on VM2? Thanks a lot for your support! Manuel systemd-timesyncd configuration for both HOST and VM2 ``` root@HOST, VM2:/var/log# cat /lib/systemd/system/systemd-networkd.service # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the
[systemd-devel] systemd-timesyncd dies on one machine but runs okay on another
Hallo all! I'm working on an embedded project consisting of an host and numerous virtual machines and am facing problems related to time management. systemd-timesyncd dies on one machine (HOST), but runs okay on another (VM2) with identical config. The project setup is as follows: HOST: Runs a (heavily) modified Debian with systemd, retrieves time via NTP from VM3 using systemd-timesyncd. * VM1: Runs openwrt and serves time via NTP using chrony * VM2: Runs a (heavily) modified Debian with SELINUX and systemd, retrieves time via NTP from VM3 using systemd-timesyncd * VM3-?: Some other VMs which seem to run fine The symptoms are as follows: HOST: `systemd-timesyncd.service` is reported as inactive (dead). A time update (adjusting the time by 2 days) took place. Then, after 5min, the service died. (It always seems to die 5-15min after a time update.) ``` root@HOST:/var/log# systemctl status systemd-timesyncd ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d └─disable-with-time-daemon.conf Active: inactive (dead) since Wed 2018-09-05 07:30:02 CEST; 1 day 17h left Docs: man:systemd-timesyncd.service(8) Process: 4724 ExecStart=/lib/systemd/systemd-timesyncd (code=exited, status=0/SUCCESS) Main PID: 4724 (code=exited, status=0/SUCCESS) Status: "Idle." Sep 03 11:51:58 konnektor systemd[1]: Starting Network Time Synchronization... Sep 03 11:51:58 konnektor systemd[1]: Started Network Time Synchronization. Sep 05 07:25:31 konnektor systemd-timesyncd[4724]: Synchronized to time server 192.168.253.1:123 (192.168.253.1). Sep 05 07:30:02 konnektor systemd[1]: Stopping Network Time Synchronization... Sep 05 07:30:02 konnektor systemd[1]: Stopped Network Time Synchronization. ``` VM2:`systemd-timesyncd.service` is reported to be active (running), time updates occur regularly. ``` root@VM2:~# systemctl status systemd-timesyncd ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d └─disable-with-time-daemon.conf Active: active (running) since Thu 2018-08-30 20:53:19 CEST; 5 days ago Docs: man:systemd-timesyncd.service(8) Main PID: 12125 (systemd-timesyn) Status: "Synchronized to time server 192.168.253.1:123 (192.168.253.1)." Tasks: 2 (limit: 4915) CGroup: /system.slice/systemd-timesyncd.service └─12125 /lib/systemd/systemd-timesyncd Aug 30 20:53:19 k-basisdienste systemd[1]: Starting Network Time Synchronization... Aug 30 20:53:19 k-basisdienste systemd[1]: Started Network Time Synchronization. Aug 30 20:44:53 k-basisdienste systemd-timesyncd[12125]: Synchronized to time server 192.168.253.1:123 (192.168.253.1). ``` On this VM, we DO have the problem of the time jumping by 15s every 50s or so. I think is caused by the time server (chrony) over-compensating a clockdrift. Hence, I think this is totally unrelated. I just mention it for the sake of completeness. When I query chrony on VM1 for statistics on the connected clients, it as well reports that the other VMs are updated every ~50s, while the last update to the host system occured hours ago. ``` root@VM1:~# chronyc clients Hostname NTP Drop Int IntL Last Cmd Drop Int Last === 192.168.253.14 11054 0 6 - 1 0 0 - - 192.168.253.10 11053 0 6 - 1 0 0 - - 192.168.253.2 11053 0 6 - 1 0 0 - - 192.168.253.18 11053 0 6 - 1 0 0 - - 192.168.253.3 390 0 10 - 237m 0 0 - - COMMENT: This is the host machine ``` systemd-timesyncd on both HOST and VM2 are using an identical unit file and also timesyncd.conf (Please find both below.) Questions I'm asking myself are: * What could be the reason for systemd-timesyncd dying on the host machine? How can I find details? * If I interpret the output correctly, systemd-timesyncd died with an exit code of 0 (success). How is that possible? Shouldn't it remain active, just the way it does on VM2? Thanks a lot for your support! Manuel systemd-timesyncd configuration for both HOST and VM2 ``` root@HOST, VM2:/var/log# cat /lib/systemd/system/systemd-networkd.service # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Network Service
