apt-daily doesn't work on my system. Nov 23 13:53:04 systemd[1]: Starting Daily apt download activities... Nov 23 13:53:34 systemd-networkd-wait-online[13512]: Event loop failed: Connection timed out Nov 23 13:53:34 apt-helper[13510]: E: Sub-process /lib/systemd/systemd-networkd-wait-online returned an error code (1) Nov 23 13:53:34 systemd[1]: apt-daily.service: Control process exited, code=exited status=100 Nov 23 13:53:34 systemd[1]: apt-daily.service: Failed with result 'exit-code'. Nov 23 13:53:34 systemd[1]: Failed to start Daily apt download activities. Nov 23 13:53:34 systemd[1]: apt-daily.service: Consumed 59ms CPU time I notice that apt-helper.cc has a hard-coded list of network management services services which, if running, will be waited on by running a service-specific command. Rather than such a cardcoded list, apt could make use of the network-online.target, which is the well-known integration point provided by systemd for clients to wait for the network to be 'online'. This is documented at <https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/>. You basically unconditionally wait on network-online.target, and then you don't need to worry about which of systemd-networkd, NetworkManager, connman, ifupdown, netscript, etc., are actually pulled in to satisfy the dependency. On my system I use NetworkManager for the ethernet and wireless interfaces, and systemd-networkd for virtual interfaces used for tunneling and bridging. In this case, the systemd-networkd-wait-online command will always time out. From this users' point of view, I have already disabled systemd-networkd-wait-online.service in order to configure the system to ignore systemd-networkd when considering if the network is 'online'. So it would be handy if apt would make use of network-online.target instead of doing its own thing here. Thanks!
Am 23.11.2017 um 15:26 schrieb Sam Morris: Wrong package ?
Am 23.11.2017 um 15:26 schrieb Sam Morris: The problem is, that network-online.target is a boot-time synchronization point, whereas apt needs this for suspend/resume as well, i.e. during runtime. This is not what network-online.target was designed for. See also https://github.com/systemd/systemd/pull/7345
Control: reassign -1 apt 1.5~rc2 This unfortunately does not work at resume or when the timer elapses because the target remains active after the services have exited: In systemd's world, once your system is online it stays online (and I guess if it does not get online during boot, it stays offline? No idea.). right, instead of checking the services of the network managers in question, we could just check if their online wait helper services are disabled, I guess.
Using apt-cacher-ng, after resume I see: Oct 05 04:30:58 debiant apt.systemd.daily[21976]: Reading package lists... Oct 05 04:30:58 debiant apt.systemd.daily[21976]: W: Failed to fetch http://localhost:3142/debian.csail.mit.edu/debian/dists/testing/InRelease Oct 05 04:30:58 debiant apt.systemd.daily[21976]: W: Failed to fetch http://localhost:3142/debian.csail.mit.edu/debian/dists/unstable/InReleas Oct 05 04:30:58 debiant apt.systemd.daily[21976]: W: Failed to fetch http://localhost:3142/security.debian.org/dists/testing/updates/InRelease Oct 05 04:30:58 debiant apt.systemd.daily[21976]: W: Failed to fetch http://deb-multimedia.org/dists/testing/InRelease Temporary failure reso Oct 05 04:30:58 debiant apt.systemd.daily[21976]: W: Some index files failed to download. They have been ignored, or old ones used instead. The only service I have enabled is NetworkManager, and looking at the code it seems like the '--timeout' parameter passed to nm-online should read '--timeout=30' instead of the two strings in apt-helper.cc: {"NetworkManager.service", "nm-online", "-q", "--timeout", "30", nullptr}, nm-online failures would not be seen because of the "-" prefix in the 'ExecStartPre' service statement. Testing with customized service specifying a longer timeout (i.e. 60 seconds), and without the quiet parm.
Hi, On my systems I have two ethernet devices, only one is connected. And thus I have excluded one in the systemd configuration, as you can see below. This is mainly to avoid the needless timeout during boot up. apt-helper however is ignoring this configuration and it is causing unnecessary errors in my syslog. Nov 16 04:30:24 luts systemd[1]: Starting Daily apt download activities... Nov 16 04:30:54 luts systemd-networkd-wait-online[993706]: Event loop failed: Connection timed out Nov 16 04:30:54 luts apt-helper[993698]: E: Sub-process /lib/systemd/systemd-networkd-wait-online returned an error code (1) apt-helper is simply running /lib/systemd/systemd-networkd-wait-online directly without looking at the systemd configuration. I'm not familiar enough with systemctl to know whether there is a better alternative. Perhaps: systemctl -q is-active systemd-networkd-wait-online # systemctl cat systemd-networkd-wait-online # /lib/systemd/system/systemd-networkd-wait-online.service # SPDX-License-Identifier: LGPL-2.1+ # # 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=Wait for Network to be Configured Documentation=man:systemd-networkd-wait-online.service(8) DefaultDependencies=no Conflicts=shutdown.target Requires=systemd-networkd.service After=systemd-networkd.service Before=network-online.target shutdown.target [Service] Type=oneshot ExecStart=/lib/systemd/systemd-networkd-wait-online RemainAfterExit=yes [Install] WantedBy=network-online.target # /etc/systemd/system/systemd-networkd-wait-online.service.d/nowait.conf [Service] ExecStart= ExecStart=/lib/systemd/systemd-networkd-wait-online --ignore=eno2 --quiet
There is no better alternative. The service runs once at boot, but we need to check for network connectivity at resume too. And we're not going to parse systemd units to figure out what you did to them. I don't think that the systemd interface of --ignore is correct here, the configuration which networks should be considered relevant for online-ness should be stored in the .network files. In fact, there's even an option already for that: RequiredForOnline=no
OK, that good be the right solution. I've created a file /etc/systemd/network/99-eno2.network [Match] Name=eno2 [Link] RequiredForOnline=no But I don't understand how to make this effective. Running "networkctl reload" does not seem to read the .network files. Oh, and netplan may also play a role. I have this: network: version: 2 renderer: networkd ethernets: eno1: dhcp4: no dhcp6: no addresses: ... eno2: dhcp4: no dhcp6: no I'm guessing I have to remove the eno2 part and try again. (( But this is a remote system, so I have to be careful not to loose the network connection. ))
Greeting to you once again I am writing for the second time as I did not receive any reply from you to my previous message. Kindly reply so we can discuss the subject as soon as possible. Sincerely, Andy Landman
Greeting to you once again I am writing for the second time as I did not receive any reply from you to my previous message. Kindly reply so we can discuss the subject as soon as possible. Sincerely, Andy Landman
Hello, Good morning, We have gone through your samples from a partner and Here is our Order List. Please do bear in mind that we are very much in need of this order, quote your competitive prices. Kindly send the Order confirmation. Your early reply will be much appreciated. Best Regards, Maryanah Erwin. PT FINDORA INTERNUSA Jln Pahlawan 66 Kec. Arjawinangun 45162 CIREBON West-Java INDONESIA tel : +62 231 357334 fax: +62 231 357260 email: marketing@findora.com
Hello, Good morning, We have gone through your samples from a partner and Here is our Order List. Please do bear in mind that we are very much in need of this order, quote your competitive prices. Kindly send the Order confirmation. Your early reply will be much appreciated. Best Regards, Maryanah Erwin. PT FINDORA INTERNUSA Jln Pahlawan 66 Kec. Arjawinangun 45162 CIREBON West-Java INDONESIA tel : +62 231 357334 fax: +62 231 357260 email: marketing@findora.com
I can confirm that adding RequiredForOnline=no to the unconfigured interface's .network file resolves the timeout issue. I did want to ask about the broader user experience: "apt-helper wait-online" calls "systemd-networkd-wait-online" without any interface arguments, which means it waits for all interfaces systemd-networkd manages. For users with unconfigured interfaces (secondary ethernet, unused wifi cards on servers, etc.), this causes a 30-second delay on every apt-daily run. While the RequiredForOnline=no solution works, it requires users to know about this systemd-networkd option and manually create .network files. Would it be worth considering one of the following? * A configuration option in apt to specify which interfaces to wait for * Documenting this behavior more prominently in apt's documentation? The current behavior was surprising to me, since I had expected apt to work without manual systemd-networkd configuration.