Re: [systemd-devel] systemd-networkd-wait-online: Wait for specific address family to be online
goes back to 'can we have a configurable script to run when DHCP assigns the address?' Surely it can't be that hard to read a config line, save it, and later execute a script On Tue, Sep 6, 2016 at 1:54 PM, Ernst Bammer wrote: > Hi, > sorry to bring this up again, but maybe somebody is back from vacation > who can answer this? ;-) > Best regards, Ernst > > On Sun, Jul 24, 2016 at 12:31 PM, Ernst Bammer > wrote: > > Hi, > > > > I have a service that depends on a non-loopback IPv4 address to be > > available at start-up. My network configuration is done with networkd, > > it's very simple and basically just: > > > > [Match] > > Name=eth* > > [Network] > > DHCP=v4 > > > > I've added the following to my service: > > > > [Unit] > > Requires=network-online.target > > After=network-online.target > > > > Unfortunately, there is no IPv4 address when the service tries to > > start (and then crashes). > > For debugging purposes, I added this to [Service]: > > > > ExecStartPre=/bin/sh -c "/bin/cat /run/systemd/netif/links/*" > > ExecStartPre=/bin/sh -c "/bin/cat /run/systemd/netif/leases/*" > > > > On reboot, I see this in the journal: > > > > Jul 24 11:41:59 myhost sh[492]: # This is private data. Do not parse. > > Jul 24 11:41:59 myhost sh[492]: ADMIN_STATE=configured > > Jul 24 11:41:59 myhost sh[492]: OPER_STATE=degraded > > Jul 24 11:41:59 myhost sh[492]: FLAGS=69699 > > Jul 24 11:42:00 myhost sh[529]: /bin/cat: /run/systemd/netif/leases/*: > > No such file or directory > > Jul 24 11:42:00 myhost systemd[1]: test.service: control process > > exited, code=exited status=1 > > Jul 24 11:42:00 myhost systemd[1]: Failed to start Test. > > Jul 24 11:42:00 myhost systemd[1]: Unit test.service entered failed > state. > > > > I suspect the problem might be that the network interface also gets a > > link-local IPv6 address, and thus systemd-networkd-wait-online > > immediately returns. If I disable IPv6 on my system (by blacklisting > > the ipv6 module), it works as expected (s-n-w-o waiting for DHCPV4 > > address). > > > > Is there a way to get s-n-w-o to wait for an address family (in my > > case IPv4) to be available? Or is there any other workaround? > > > > FWIW, I'm using Debian 8 Jessie (systemd version 215). > > > > Thank you! > > Ernst > ___ > 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] systemd-networkd-wait-online: Wait for specific address family to be online
Hi, sorry to bring this up again, but maybe somebody is back from vacation who can answer this? ;-) Best regards, Ernst On Sun, Jul 24, 2016 at 12:31 PM, Ernst Bammer wrote: > Hi, > > I have a service that depends on a non-loopback IPv4 address to be > available at start-up. My network configuration is done with networkd, > it's very simple and basically just: > > [Match] > Name=eth* > [Network] > DHCP=v4 > > I've added the following to my service: > > [Unit] > Requires=network-online.target > After=network-online.target > > Unfortunately, there is no IPv4 address when the service tries to > start (and then crashes). > For debugging purposes, I added this to [Service]: > > ExecStartPre=/bin/sh -c "/bin/cat /run/systemd/netif/links/*" > ExecStartPre=/bin/sh -c "/bin/cat /run/systemd/netif/leases/*" > > On reboot, I see this in the journal: > > Jul 24 11:41:59 myhost sh[492]: # This is private data. Do not parse. > Jul 24 11:41:59 myhost sh[492]: ADMIN_STATE=configured > Jul 24 11:41:59 myhost sh[492]: OPER_STATE=degraded > Jul 24 11:41:59 myhost sh[492]: FLAGS=69699 > Jul 24 11:42:00 myhost sh[529]: /bin/cat: /run/systemd/netif/leases/*: > No such file or directory > Jul 24 11:42:00 myhost systemd[1]: test.service: control process > exited, code=exited status=1 > Jul 24 11:42:00 myhost systemd[1]: Failed to start Test. > Jul 24 11:42:00 myhost systemd[1]: Unit test.service entered failed state. > > I suspect the problem might be that the network interface also gets a > link-local IPv6 address, and thus systemd-networkd-wait-online > immediately returns. If I disable IPv6 on my system (by blacklisting > the ipv6 module), it works as expected (s-n-w-o waiting for DHCPV4 > address). > > Is there a way to get s-n-w-o to wait for an address family (in my > case IPv4) to be available? Or is there any other workaround? > > FWIW, I'm using Debian 8 Jessie (systemd version 215). > > Thank you! > Ernst ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [229] systemd timers not triggered after resume
Hello! I found that systemd no longer triggers the timer after waking the system. I'm not sure since which version this is true because I couldn't use suspend for a longer time due to driver bugs in the kernel. # /etc/systemd/system/internal-backup.timer [Unit] Description=Daily Backup Timer [Timer] OnCalendar=03:00 WakeSystem=true [Install] WantedBy=timers.target The system will wake up and go back to sleep after 2 hours later as configured. But the associated service won't start: $ systemctl list-timers NEXT LEFTLAST PASSED UNIT ACTIVATES ... Mi 2016-08-31 03:00:00 CEST 19h leftn/a n/a internal-backup.timerinternal-backup.service ... 9 timers listed. Pass --all to see loaded but inactive timers, too. It simply skips triggering and queues the service for the next invocation. Aug 30 03:00:35 jupiter.sol.local kernel: pcieport :00:1c.6: System wakeup enabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: ehci-pci :00:1d.0: System wakeup enabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: ehci-pci :00:1a.0: System wakeup enabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: PM: noirq suspend of devices complete after 11.418 msecs Aug 30 03:00:35 jupiter.sol.local kernel: ACPI: Preparing to enter system sleep state S3 Aug 30 03:00:35 jupiter.sol.local kernel: PM: Saving platform NVS memory Aug 30 03:00:35 jupiter.sol.local kernel: Disabling non-boot CPUs ... Aug 30 03:00:35 jupiter.sol.local kernel: smpboot: CPU 1 is now offline Aug 30 03:00:35 jupiter.sol.local kernel: smpboot: CPU 2 is now offline Aug 30 03:00:35 jupiter.sol.local kernel: smpboot: CPU 3 is now offline Aug 30 03:00:35 jupiter.sol.local kernel: ACPI: Low-level resume complete Aug 30 03:00:35 jupiter.sol.local kernel: PM: Restoring platform NVS memory Aug 30 03:00:35 jupiter.sol.local kernel: Enabling non-boot CPUs ... Aug 30 03:00:35 jupiter.sol.local kernel: x86: Booting SMP configuration: Aug 30 03:00:35 jupiter.sol.local kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2 Aug 30 03:00:35 jupiter.sol.local kernel: cache: parent cpu1 should not be sleeping Aug 30 03:00:35 jupiter.sol.local kernel: CPU1 is up Aug 30 03:00:35 jupiter.sol.local kernel: smpboot: Booting Node 0 Processor 2 APIC 0x4 Aug 30 03:00:35 jupiter.sol.local kernel: cache: parent cpu2 should not be sleeping Aug 30 03:00:35 jupiter.sol.local kernel: CPU2 is up Aug 30 03:00:35 jupiter.sol.local kernel: smpboot: Booting Node 0 Processor 3 APIC 0x6 Aug 30 03:00:35 jupiter.sol.local kernel: cache: parent cpu3 should not be sleeping Aug 30 03:00:35 jupiter.sol.local kernel: CPU3 is up Aug 30 03:00:35 jupiter.sol.local kernel: ACPI: Waking up from system sleep state S3 Aug 30 03:00:35 jupiter.sol.local kernel: ehci-pci :00:1d.0: System wakeup disabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: pcieport :00:1c.6: System wakeup disabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: ehci-pci :00:1a.0: System wakeup disabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: PM: noirq resume of devices complete after 11.299 msecs Aug 30 03:00:35 jupiter.sol.local kernel: PM: early resume of devices complete after 0.266 msecs Aug 30 03:00:35 jupiter.sol.local kernel: rtc_cmos 00:02: System wakeup disabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: usb usb3: root hub lost power or was reset Aug 30 03:00:35 jupiter.sol.local kernel: usb usb4: root hub lost power or was reset Aug 30 03:00:35 jupiter.sol.local kernel: sd 3:0:0:0: [sdd] Starting disk Aug 30 03:00:35 jupiter.sol.local kernel: sd 0:0:0:0: [sda] Starting disk Aug 30 03:00:35 jupiter.sol.local kernel: sd 4:0:0:0: [sde] Starting disk Aug 30 03:00:35 jupiter.sol.local kernel: sd 1:0:0:0: [sdb] Starting disk Aug 30 03:00:35 jupiter.sol.local kernel: sd 2:0:0:0: [sdc] Starting disk Aug 30 03:00:35 jupiter.sol.local kernel: usb 4-1: reset SuperSpeed USB device number 2 using xhci_hcd Aug 30 03:00:35 jupiter.sol.local kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:00 (unknown) filtered out Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (unknown) filtered out Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: supports DRM functions and may not be fully accessible Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:00 (unknown) filtered out Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (unknown) filtered out Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: supports DRM functions and may not be fully accessible Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: configured for UDMA/133 Aug 30 03:00:35 jupiter.sol.local kernel: PM: noirq resume of devices complete after 11.299 msecs Aug 30 03:00:35 jupiter.sol.local kern
[systemd-devel] [229] systemd timers not triggered after resume
Hello! I found that systemd no longer triggers the timer after waking the system. I'm not sure since which version this is true because I couldn't use suspend for a longer time due to driver bugs in the kernel. # /etc/systemd/system/internal-backup.timer [Unit] Description=Daily Backup Timer [Timer] OnCalendar=03:00 WakeSystem=true [Install] WantedBy=timers.target The system will wake up and go back to sleep after 2 hours later as configured. But the associated service won't start: $ systemctl list-timers NEXT LEFTLAST PASSEDUNIT ACTIVATES ... Mi 2016-08-31 03:00:00 CEST 19h leftn/a n/a internal-backup.timerinternal-backup.service ... 9 timers listed. Pass --all to see loaded but inactive timers, too. It simply skips triggering and queues the service for the next invocation. Aug 30 03:00:35 jupiter.sol.local kernel: pcieport :00:1c.6: System wakeup enabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: ehci-pci :00:1d.0: System wakeup enabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: ehci-pci :00:1a.0: System wakeup enabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: PM: noirq suspend of devices complete after 11.418 msecs Aug 30 03:00:35 jupiter.sol.local kernel: ACPI: Preparing to enter system sleep state S3 Aug 30 03:00:35 jupiter.sol.local kernel: PM: Saving platform NVS memory Aug 30 03:00:35 jupiter.sol.local kernel: Disabling non-boot CPUs ... Aug 30 03:00:35 jupiter.sol.local kernel: smpboot: CPU 1 is now offline Aug 30 03:00:35 jupiter.sol.local kernel: smpboot: CPU 2 is now offline Aug 30 03:00:35 jupiter.sol.local kernel: smpboot: CPU 3 is now offline Aug 30 03:00:35 jupiter.sol.local kernel: ACPI: Low-level resume complete Aug 30 03:00:35 jupiter.sol.local kernel: PM: Restoring platform NVS memory Aug 30 03:00:35 jupiter.sol.local kernel: Enabling non-boot CPUs ... Aug 30 03:00:35 jupiter.sol.local kernel: x86: Booting SMP configuration: Aug 30 03:00:35 jupiter.sol.local kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2 Aug 30 03:00:35 jupiter.sol.local kernel: cache: parent cpu1 should not be sleeping Aug 30 03:00:35 jupiter.sol.local kernel: CPU1 is up Aug 30 03:00:35 jupiter.sol.local kernel: smpboot: Booting Node 0 Processor 2 APIC 0x4 Aug 30 03:00:35 jupiter.sol.local kernel: cache: parent cpu2 should not be sleeping Aug 30 03:00:35 jupiter.sol.local kernel: CPU2 is up Aug 30 03:00:35 jupiter.sol.local kernel: smpboot: Booting Node 0 Processor 3 APIC 0x6 Aug 30 03:00:35 jupiter.sol.local kernel: cache: parent cpu3 should not be sleeping Aug 30 03:00:35 jupiter.sol.local kernel: CPU3 is up Aug 30 03:00:35 jupiter.sol.local kernel: ACPI: Waking up from system sleep state S3 Aug 30 03:00:35 jupiter.sol.local kernel: ehci-pci :00:1d.0: System wakeup disabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: pcieport :00:1c.6: System wakeup disabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: ehci-pci :00:1a.0: System wakeup disabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: PM: noirq resume of devices complete after 11.299 msecs Aug 30 03:00:35 jupiter.sol.local kernel: PM: early resume of devices complete after 0.266 msecs Aug 30 03:00:35 jupiter.sol.local kernel: rtc_cmos 00:02: System wakeup disabled by ACPI Aug 30 03:00:35 jupiter.sol.local kernel: usb usb3: root hub lost power or was reset Aug 30 03:00:35 jupiter.sol.local kernel: usb usb4: root hub lost power or was reset Aug 30 03:00:35 jupiter.sol.local kernel: sd 3:0:0:0: [sdd] Starting disk Aug 30 03:00:35 jupiter.sol.local kernel: sd 0:0:0:0: [sda] Starting disk Aug 30 03:00:35 jupiter.sol.local kernel: sd 4:0:0:0: [sde] Starting disk Aug 30 03:00:35 jupiter.sol.local kernel: sd 1:0:0:0: [sdb] Starting disk Aug 30 03:00:35 jupiter.sol.local kernel: sd 2:0:0:0: [sdc] Starting disk Aug 30 03:00:35 jupiter.sol.local kernel: usb 4-1: reset SuperSpeed USB device number 2 using xhci_hcd Aug 30 03:00:35 jupiter.sol.local kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:00 (unknown) filtered out Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (unknown) filtered out Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: supports DRM functions and may not be fully accessible Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:00 (unknown) filtered out Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (unknown) filtered out Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: supports DRM functions and may not be fully accessible Aug 30 03:00:35 jupiter.sol.local kernel: ata1.00: configured for UDMA/133 Aug 30 03:00:35 jupiter.sol.local kernel: PM: noirq resume of devices complete after 11.299 msecs Aug 30 03:00:35 jupiter.sol.local kernel: PM: early resume of devices complete after 0.266 msecs Aug 30 03:00:35 jupit