[DNG] WAIT_ONLINE_METHOD=none
Hi all! Maybe somebody can shed some light in here: /etc/default/networking has an option "WAIT_ONLINE_METHOD" and "WAIT_ONLINE_IFACE". The documentation gives the impression that one or both methods can be used to get rid of that pesky endlesss wait while booting without network. Is this impression wrong or is the documentation not telling the truth? I have not found any settings that get rid of that pesky bootdelay when booting without network :-( Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Ok, an addition to this issue: Anno domini 2019 Wed, 13 Feb 13:14:36 +0100 Dr. Nikolaus Klepp scripsit: > Hi all! > > Maybe somebody can shed some light in here: > > /etc/default/networking has an option "WAIT_ONLINE_METHOD" and > "WAIT_ONLINE_IFACE". The documentation gives the impression that one or both > methods can be used to get rid of that pesky endlesss wait while booting > without network. Is this impression wrong or is the documentation not telling > the truth? I have not found any settings that get rid of that pesky bootdelay > when booting without network :-( > > Nik > Looks like the package "ifupdown" for sysvinit is missing the ability to use WAIT_ONLINE_* To be more precise: WAIT_ONLINE_* is used in /lib/ifupdown/wait-online.sh. That file used only from systemd: /lib/systemd/system/ifupdown-wait-online.service:ExecStart=/lib/ifupdown/wait-online.sh This is the solution that I came up with: #$ diff /tmp/networking /etc/init.d/networking 138,143c138,143 < if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose < then < log_action_end_msg $? < else < log_action_end_msg $? < fi --- > > BG=$( [ "$WAIT_ONLINE_METHOD" = "none" ] && echo '&') > ( > ifup -a $exclusions $verbose && ifup_hotplug $exclusions > $verbose > log_action_end_msg $? > )$BG At least "WAIT_ONLINE_METHOD=none" would be working as documented and remove that bootdelay when booting without network. Thoughts on this? Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Le 13/02/2019 à 14:32, Dr. Nikolaus Klepp a écrit : Ok, an addition to this issue: Anno domini 2019 Wed, 13 Feb 13:14:36 +0100 Dr. Nikolaus Klepp scripsit: Hi all! Maybe somebody can shed some light in here: /etc/default/networking has an option "WAIT_ONLINE_METHOD" and "WAIT_ONLINE_IFACE". The documentation gives the impression that one or both methods can be used to get rid of that pesky endlesss wait while booting without network. Is this impression wrong or is the documentation not telling the truth? I have not found any settings that get rid of that pesky bootdelay when booting without network :-( Nik Looks like the package "ifupdown" for sysvinit is missing the ability to use WAIT_ONLINE_* To be more precise: WAIT_ONLINE_* is used in /lib/ifupdown/wait-online.sh. That file used only from systemd: /lib/systemd/system/ifupdown-wait-online.service:ExecStart=/lib/ifupdown/wait-online.sh This is the solution that I came up with: #$ diff /tmp/networking /etc/init.d/networking 138,143c138,143
Re: [DNG] WAIT_ONLINE_METHOD=none
Anno domini 2019 Wed, 13 Feb 16:06:07 +0100 Didier Kryn scripsit: > Le 13/02/2019 à 14:32, Dr. Nikolaus Klepp a écrit : > > Ok, an addition to this issue: > > Anno domini 2019 Wed, 13 Feb 13:14:36 +0100 > > Dr. Nikolaus Klepp scripsit: > >> Hi all! > >> > >> Maybe somebody can shed some light in here: > >> > >> /etc/default/networking has an option "WAIT_ONLINE_METHOD" and > >> "WAIT_ONLINE_IFACE". The documentation gives the impression that one or > >> both methods can be used to get rid of that pesky endlesss wait while > >> booting without network. Is this impression wrong or is the documentation > >> not telling the truth? I have not found any settings that get rid of that > >> pesky bootdelay when booting without network :-( > >> > >> Nik > >> > > Looks like the package "ifupdown" for sysvinit is missing the ability to > > use WAIT_ONLINE_* > > To be more precise: WAIT_ONLINE_* is used in /lib/ifupdown/wait-online.sh. > > That file used only from systemd: > > /lib/systemd/system/ifupdown-wait-online.service:ExecStart=/lib/ifupdown/wait-online.sh > > > > > > This is the solution that I came up with: > > > > #$ diff /tmp/networking /etc/init.d/networking > > 138,143c138,143 > > < if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose > > < then > > < log_action_end_msg $? > > < else > > < log_action_end_msg $? > > < fi > > --- > >>BG=$( [ "$WAIT_ONLINE_METHOD" = "none" ] && echo '&') > >>( > >>ifup -a $exclusions $verbose && ifup_hotplug $exclusions > >> $verbose > >>log_action_end_msg $? > >>)$BG > > At least "WAIT_ONLINE_METHOD=none" would be working as documented and > > remove that bootdelay when booting without network. > > > > Thoughts on this? > > > > Nik > > > > > > > > If your ethernet cable can be either plugged or unplugged and you > want your system to react when you plug/unplug a cable in, then you need > a server to detect these changes and invoke ifup/ifdown accordingly. > This server can be ifplugd or netplug. > > In this situation you simply don't need and don't want neither > 'auto eth0' nor 'allow-hotplug eth0' stanzas in your interfaces file. > These are the stanzas which will make your OS hang at boot time and they > are simply useless. Just remove them. > > Didier Hi Didier! I followed your suggestion and installed "ifplugd". It would be nice if that was the default configuration for desktops :-) Thank you, Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Hi, On 13/2/19 16:59, Dr. Nikolaus Klepp wrote: If your ethernet cable can be either plugged or unplugged and you want your system to react when you plug/unplug a cable in, then you need a server to detect these changes and invoke ifup/ifdown accordingly. This server can be ifplugd or netplug. In this situation you simply don't need and don't want neither 'auto eth0' nor 'allow-hotplug eth0' stanzas in your interfaces file. These are the stanzas which will make your OS hang at boot time and they are simply useless. Just remove them. Didier Hi Didier! I followed your suggestion and installed "ifplugd". It would be nice if that was the default configuration for desktops:-) Thank you, Nik The backend of simple-netaid also can detect plug/unplug events without any other server -neither ifplugd nor netplugd-, but there is still work to do. I didn't work on it since september, though i have it in mind, of course. Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
hi Aitor! Anno domini 2019 Wed, 13 Feb 23:12:25 +0100 aitor_czr scripsit: > Hi, > > On 13/2/19 16:59, Dr. Nikolaus Klepp wrote: > >> If your ethernet cable can be either plugged or unplugged and you > >> want your system to react when you plug/unplug a cable in, then you need > >> a server to detect these changes and invoke ifup/ifdown accordingly. > >> This server can be ifplugd or netplug. > >> > >> In this situation you simply don't need and don't want neither > >> 'auto eth0' nor 'allow-hotplug eth0' stanzas in your interfaces file. > >> These are the stanzas which will make your OS hang at boot time and they > >> are simply useless. Just remove them. > >> > >> Didier > > Hi Didier! > > > > I followed your suggestion and installed "ifplugd". It would be nice if > > that was the default configuration for desktops:-) > > > > Thank you, > > Nik > > The backend of simple-netaid also can detect plug/unplug events without > any other server -neither ifplugd nor netplugd-, but there is still work > to do. > > I didn't work on it since september, though i have it in mind, of course. Is there a place to download "simple-netaid"? I have tried "ifplugd" the last days, but that did not work especially well: It worked when starting without network and connecting within a hour or so, but it failed when connecting after several hours. No I'm trying "netplug" ... Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Le 16/02/2019 à 21:56, Dr. Nikolaus Klepp a écrit : I have tried "ifplugd" the last days, but that did not work especially well: It worked when starting without network and connecting within a hour or so, but it failed when connecting after several hours. Strange. Mostly worked fine for me, for at least a decade, I would say. Did you try 'dpkg-reconfigure ifplugd' ? Only ethernet interfaces should be monitored by ifplugd, not the wifi interfaces, these are monitored by wpa_supplicant, and therefore, must have an "auto" stanza in the interfaces file. The issues I had in the past came from misunterstanding because there was no warning that only Ethernet interfaces should be monitored and that their "auto" stanzas should be removed from the interfaces file. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Anno domini 2019 Sat, 16 Feb 23:23:23 +0100 Didier Kryn scripsit: > Le 16/02/2019 à 21:56, Dr. Nikolaus Klepp a écrit : > > I have tried "ifplugd" the last days, but that did not work especially > > well: It worked when starting without network and connecting within a hour > > or so, but it failed when connecting after several hours. > > Strange. Mostly worked fine for me, for at least a decade, I would say. > > Did you try 'dpkg-reconfigure ifplugd' ? Only ethernet interfaces > should be monitored by ifplugd, not the wifi interfaces, these are > monitored by wpa_supplicant, and therefore, must have an "auto" stanza > in the interfaces file. I had explictly defined "eth0" in /etc/default/idplugd and I went through all 3 possible combinations. I have not tried "dpkg-reconfigure ifplugd". The testmachine only has eth0, no wifi. > The issues I had in the past came from misunterstanding because > there was no warning that only Ethernet interfaces should be monitored > and that their "auto" stanzas should be removed from the interfaces file. I have removed that as you suggested. But I have news on the "openssh hangs on boot"-issue: kernel 4.9 (from ascii) works as expected. But kernel 4.19 from beowulf lets openssh hang on boot. Same computer, same config, just kernel changed. But this is different: 4.9: Feb 16 22:24:23 localhost kernel: [6.033782] Bluetooth: BNEP socket layer initialized Feb 16 22:24:24 localhost kernel: [6.978681] random: crng init done 4.19: Feb 16 22:09:14 localhost kernel: [5.062847] Bluetooth: BNEP socket layer initialized Feb 16 22:09:44 localhost kernel: [ 34.345896] random: crng init done So openssh is blocked by random, which by some unknown reason takes ~ 30 seconds to start on 4.19 (in contrast to ~ 1 second o 4.9) Any suggestions on how to proceed? Nik > > Didier > > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Le 16/02/2019 à 23:42, Dr. Nikolaus Klepp a écrit : So openssh is blocked by random, which by some unknown reason takes ~ 30 seconds to start on 4.19 (in contrast to ~ 1 second o 4.9) I've read things about that in other lists. There's a new requirement to have a big enough amount of random numbers (they call this entropy, as an extension of the physical concept to computing), in some new random generator. openssh requires that to be able to start securely. The only workaround, IMHO is to find a way to not wait until openssh is ready to continue the start up. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
On 16/02/2019 23:07, Didier Kryn wrote: Le 16/02/2019 à 23:42, Dr. Nikolaus Klepp a écrit : So openssh is blocked by random, which by some unknown reason takes ~ 30 seconds to start on 4.19 (in contrast to ~ 1 second o 4.9) I've read things about that in other lists. There's a new requirement to have a big enough amount of random numbers (they call this entropy, as an extension of the physical concept to computing), in some new random generator. openssh requires that to be able to start securely. The only workaround, IMHO is to find a way to not wait until openssh is ready to continue the start up. Didier If you install 'haveged' package /dev/random and /dev/urandom should (a) be better quality and (b) programs that need chunks of random data such as SSL on start-up should come up more quickly, i.e. not block waiting. Mike ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Anno domini 2019 Sun, 17 Feb 16:29:12 + Mike Tubby scripsit: > > On 16/02/2019 23:07, Didier Kryn wrote: > > Le 16/02/2019 à 23:42, Dr. Nikolaus Klepp a écrit : > >> So openssh is blocked by random, which by some unknown reason takes ~ > >> 30 seconds to start on 4.19 (in contrast to ~ 1 second o 4.9) > > > > I've read things about that in other lists. There's a new > > requirement to have a big enough amount of random numbers (they call > > this entropy, as an extension of the physical concept to computing), > > in some new random generator. openssh requires that to be able to > > start securely. The only workaround, IMHO is to find a way to not wait > > until openssh is ready to continue the start up. > > > > Didier > > > > > If you install 'haveged' package /dev/random and /dev/urandom should (a) > be better quality and (b) programs that need chunks of random data such > as SSL on start-up should come up more quickly, i.e. not block waiting. > > Mike OK, that worked. Now the bootdelay is gone. What remains is thinkpad_acpi flooding the message log. Is there a way to tell that thing to shut down after the first error messages? Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Le 17/02/2019 à 17:29, Mike Tubby a écrit : If you install 'haveged' package /dev/random and /dev/urandom should (a) be better quality and (b) programs that need chunks of random data such as SSL on start-up should come up more quickly, i.e. not block waiting Looks kije a great suggestion. I'd never heared of it. Shouldn't this package be recommended, or at least suggested, by things like openssl and openssh ? Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Le 18/02/2019 à 11:50, Didier Kryn a écrit : Looks kije a great suggestion. I'd never heared of it. Sorry j->k , k->l . ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
> On 18 Feb 2019, at 21:50, Didier Kryn wrote: > >> Le 17/02/2019 à 17:29, Mike Tubby a écrit : >> If you install 'haveged' package /dev/random and /dev/urandom should (a) be >> better quality and (b) programs that need chunks of random data such as SSL >> on start-up should come up more quickly, i.e. not block waiting > > > Looks kije a great suggestion. I'd never heared of it. > > Shouldn't this package be recommended, or at least suggested, by things > like openssl and openssh ? The quality of entropy from haveged is not guaranteed. https://security.stackexchange.com/questions/34523/is-it-appropriate-to-use-haveged-as-a-source-of-entropy-on-virtual-machines https://lwn.net/Articles/525459/ Maybe rng tools might be a better option if you are low on entropy? I don’t claim to be an expert on security or crypto though. https://wiki.archlinux.org/index.php/Rng-tools —Tom___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Anno domini 2019 Mon, 18 Feb 23:31:24 +1100 wirelessduck--- via Dng scripsit: > > > On 18 Feb 2019, at 21:50, Didier Kryn wrote: > > > >> Le 17/02/2019 à 17:29, Mike Tubby a écrit : > >> If you install 'haveged' package /dev/random and /dev/urandom should (a) > >> be better quality and (b) programs that need chunks of random data such as > >> SSL on start-up should come up more quickly, i.e. not block waiting > > > > > > Looks kije a great suggestion. I'd never heared of it. > > > > Shouldn't this package be recommended, or at least suggested, by things > > like openssl and openssh ? > > The quality of entropy from haveged is not guaranteed. > > https://security.stackexchange.com/questions/34523/is-it-appropriate-to-use-haveged-as-a-source-of-entropy-on-virtual-machines > > https://lwn.net/Articles/525459/ > > Maybe rng tools might be a better option if you are low on entropy? I don’t > claim to be an expert on security or crypto though. > > https://wiki.archlinux.org/index.php/Rng-tools > > —Tom Just tested "rng-tools": they also work. Comming back to the original issue: I tested ifplugd - which turned out to be not very reliable, but worked at least some hours. Now I tested "netplugd". The result is not verry promising: eudev logged the plug-event immediately, but netplugd sometimes took a break for 5 minutes ore more to detect that the cable was plugged in. Is there a deeper reason why eth0 plug/unplug events cannot be handled by eudev (any more)? Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Le 18/02/2019 à 14:07, Dr. Nikolaus Klepp a écrit : Comming back to the original issue: I tested ifplugd - which turned out to be not very reliable, but worked at least some hours. Now I tested "netplugd". The result is not verry promising: eudev logged the plug-event immediately, but netplugd sometimes took a break for 5 minutes ore more to detect that the cable was plugged in. Eudev should react to the detection of the eth interface and create the device. It isn't supposed to react to carrier detection (cable connected). And, of course, the device should exist prior to ifplugd/netplug to detect the carrier. What kind of ethernet interface do you have? Is it some external device connected through usb ? Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Anno domini 2019 Mon, 18 Feb 14:51:03 +0100 Didier Kryn scripsit: > Le 18/02/2019 à 14:07, Dr. Nikolaus Klepp a écrit : > > Comming back to the original issue: I tested ifplugd - which turned out to > > be not very reliable, but worked at least some hours. Now I tested > > "netplugd". The result is not verry promising: eudev logged the plug-event > > immediately, but netplugd sometimes took a break for 5 minutes ore more to > > detect that the cable was plugged in. > > Eudev should react to the detection of the eth interface and create > the device. It isn't supposed to react to carrier detection (cable > connected). And, of course, the device should exist prior to > ifplugd/netplug to detect the carrier. > > What kind of ethernet interface do you have? Is it some external > device connected through usb ? It's the built-in ethernet of T60/T61 laptops. This is what "dmesg" says (cable plugged in, device booted. Then cable detatched (232.150573), cable reattached (236.562619) and detached again (764.652272) - same to be found in /var/log/messages: [ 57.202695] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx [ 57.202873] e1000e :01:00.0 eth0: 10/100 speed: disabling TSO [ 232.150573] e1000e: eth0 NIC Link is Down [ 232.465673] e1000e: eth0 NIC Link is Down [ 234.126681] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx [ 234.126860] e1000e :01:00.0 eth0: 10/100 speed: disabling TSO [ 234.850510] e1000e: eth0 NIC Link is Down [ 236.562619] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx [ 236.562797] e1000e :01:00.0 eth0: 10/100 speed: disabling TSO [ 764.652272] e1000e: eth0 NIC Link is Down [ 768.674596] e1000e :01:00.0 eth0: MAC Wakeup cause - Link Status Change [ 769.121767] e1000e: eth0 NIC Link is Down [ 769.397761] e1000e: eth0 NIC Link is Down [ 769.741891] e1000e: eth0 NIC Link is Down What I do not understand: In my understanding "udevadm monitor" should print all events, not only the events it has rules for. But it does not print anything of these plug/unplug events. What's the point I am missing? Nik > > Didier > > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Le 18/02/2019 à 15:05, Dr. Nikolaus Klepp a écrit : Anno domini 2019 Mon, 18 Feb 14:51:03 +0100 Didier Kryn scripsit: Le 18/02/2019 à 14:07, Dr. Nikolaus Klepp a écrit : Comming back to the original issue: I tested ifplugd - which turned out to be not very reliable, but worked at least some hours. Now I tested "netplugd". The result is not verry promising: eudev logged the plug-event immediately, but netplugd sometimes took a break for 5 minutes ore more to detect that the cable was plugged in. Eudev should react to the detection of the eth interface and create the device. It isn't supposed to react to carrier detection (cable connected). And, of course, the device should exist prior to ifplugd/netplug to detect the carrier. What kind of ethernet interface do you have? Is it some external device connected through usb ? It's the built-in ethernet of T60/T61 laptops. This is what "dmesg" says (cable plugged in, device booted. Then cable detatched (232.150573), cable reattached (236.562619) and detached again (764.652272) - same to be found in /var/log/messages: [ 57.202695] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx [ 57.202873] e1000e :01:00.0 eth0: 10/100 speed: disabling TSO [ 232.150573] e1000e: eth0 NIC Link is Down [ 232.465673] e1000e: eth0 NIC Link is Down [ 234.126681] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx [ 234.126860] e1000e :01:00.0 eth0: 10/100 speed: disabling TSO [ 234.850510] e1000e: eth0 NIC Link is Down [ 236.562619] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx [ 236.562797] e1000e :01:00.0 eth0: 10/100 speed: disabling TSO [ 764.652272] e1000e: eth0 NIC Link is Down [ 768.674596] e1000e :01:00.0 eth0: MAC Wakeup cause - Link Status Change [ 769.121767] e1000e: eth0 NIC Link is Down [ 769.397761] e1000e: eth0 NIC Link is Down [ 769.741891] e1000e: eth0 NIC Link is Down What I do not understand: In my understanding "udevadm monitor" should print all events, not only the events it has rules for. But it does not print anything of these plug/unplug events. What's the point I am missing? Dunno for udevadm. I've used my own uevent logger in the past to watch what was happening. It is clear that the driver logs a message every time the cable is plugged/unplugged; I've observed that many times on various hosts. But I don't think if it generates an uevent for that, therefore, I don't this message is from udev and I dunno how ifplugd is notified. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Am 2019-02-18 14:07, schrieb Dr. Nikolaus Klepp: Comming back to the original issue: I tested ifplugd - which turned out to be not very reliable, Guess who made it! L.P. :-D ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Le 18/02/2019 à 18:09, J. Fahrner via Dng a écrit : Am 2019-02-18 14:07, schrieb Dr. Nikolaus Klepp: Comming back to the original issue: I tested ifplugd - which turned out to be not very reliable, Guess who made it! We all know who made it (-: . But it just does one thing and seems do it well, at least for me - never looked at the source. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Anno domini 2019 Mon, 18 Feb 18:09:21 +0100 J. Fahrner via Dng scripsit: > Am 2019-02-18 14:07, schrieb Dr. Nikolaus Klepp: > > Comming back to the original issue: I tested ifplugd - which turned > > out to be not very reliable, > > Guess who made it! > L.P. :-D *sigh* That L. does not stand for Lovecraft, does it? -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Am 2019-02-18 18:20, schrieb Didier Kryn: We all know who made it (-: . But it just does one thing and seems do it well, at least for me - never looked at the source. I had some boot delay because of dhcpdiscover, so I tried ifplugd as it was mentioned in this thread. Boot delay was gone, but network availability also ;-) Next I read the man page to see if I had to configure something. As I saw who made it, I purged the package immediately ;-) Better some short boot delay as no network at all. Jochen ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Le 18/02/2019 à 18:33, J. Fahrner via Dng a écrit : Am 2019-02-18 18:20, schrieb Didier Kryn: We all know who made it (-: . But it just does one thing and seems do it well, at least for me - never looked at the source. I had some boot delay because of dhcpdiscover, so I tried ifplugd as it was mentioned in this thread. Boot delay was gone, but network availability also ;-) Next I read the man page to see if I had to configure something. As I saw who made it, I purged the package immediately ;-) If you reject the software because you distrust the author, try netplug intead, or write your own. The function is the same: react to plugging/unplugging the Ethernet cable. I dunno how these daemons get notified, but they do, and configure/deconfigure your interface. That's what they do and what they're supposed to do. I never tried netplug, but I guess it invokes ifup/ifdown, just like ifplugd. Alternatively, you can also invoke ifup/ifdown by hand (-: Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Am 2019-02-18 18:45, schrieb Didier Kryn: If you reject the software because you distrust the author, try netplug intead, or write your own. The function is the same: react to plugging/unplugging the Ethernet cable. I dunno how these daemons get notified, but they do, and configure/deconfigure your interface. That's what they do and what they're supposed to do. I never tried netplug, but I guess it invokes ifup/ifdown, just like ifplugd. Alternatively, you can also invoke ifup/ifdown by hand (-: I don't think there is any advantage to work around the dhcpdiscover boot delay by using daemons that bring up networking later. Several init scripts (like ntpd) rely on networking and have a dependency on this. Now when we bypass it, they simply fail and try later. This is not a clean concept. If we need networking during boot, we shall wait until network is ready (or encapsulate all network related processes and run them in background) Jochen ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WAIT_ONLINE_METHOD=none
Le 18/02/2019 à 20:04, J. Fahrner via Dng a écrit : Am 2019-02-18 18:45, schrieb Didier Kryn: If you reject the software because you distrust the author, try netplug intead, or write your own. The function is the same: react to plugging/unplugging the Ethernet cable. I dunno how these daemons get notified, but they do, and configure/deconfigure your interface. That's what they do and what they're supposed to do. I never tried netplug, but I guess it invokes ifup/ifdown, just like ifplugd. Alternatively, you can also invoke ifup/ifdown by hand (-: I don't think there is any advantage to work around the dhcpdiscover boot delay by using daemons that bring up networking later. Several init scripts (like ntpd) rely on networking and have a dependency on this. Now when we bypass it, they simply fail and try later. This is not a clean concept. The only way to work around the dhcpdiscover delay is to configure the interface statically. But this isn't the issue here. The delay we are dealing with is the delay until a person eventually plugs a network cable into the computer. If ifup is invoked at start-up in the absence of a carrier, it will give up after some delay and the boot process can proceed. Not only this causes a delay, but then nothing will bring automagically the interface when the cable is plugged in, you will need to invoke ifup/ifdown manually, restart networking, or even reboot. The solution is to not bring up automatically the ethernet interface when you don't know if there is a carrier - which avoids the boot delay, and have a daemon which will do it when there is a carrier - which avoids rebooting after plugging the cable. dhcpdiscover is the very last step; it is invoked after alll the preceding has succeeded. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
