On Mon, 06 Jul 2020 at 01:48:45 +0200, Vincent Lefevre wrote: > On 2020-07-06 01:06:58 +0200, Guilhem Moulin wrote: >> On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote: >>> On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote: >>>> The raison d'être of wait_for_dropbear() is to avoid handing the >>>> execution over to init(1) with a running ipconfig process or unclean >>>> network stack. This is what the race condition described in #943459 is >>>> about. wait_for_dropbear() somewhat of a hack, but ipconfig doesn't >>>> seem to react to SIGTERM and I couldn't do better at the time. >>> >>> How about SIGKILL, then? >> >> No. > > Why no?
Not gonna send SIGKILL processes not under my control. Bad practice. It might leave all sort crap behind, I need a documented abort mechanism. >>> The user has more knowledge than initramfs. For instance, he knows >>> whether the link is present. And he generally knows the typical >>> time he has to wait for the DHCP server (unless a major problem >>> occurs with the server, in which case he may have to wait any time). >>> So it's better to leave the control to the user. >> >> I could certainly make the timeout configurable, but that's be an option >> hardcoded in the initramfs (or the kernel command line) so probably not >> ideal to manually flip occasionally when the users knows there is no >> link present. > > If you let the user run a script that controls the timeout, that > would be better. For instance, a typical setting when dropbear is > used to unlock the disk(s) would be to set the timeout so that the > following conditions are *both* satisfied: > > 1. Some lower bound has been reached (say 10 seconds). > > 2. The passphrase has been validated. > > This makes sense because in this case, it is useless to abort > wait_for_dropbear() while the passphrase has not been validated > yet. wait_for_dropbear() runs at init-bottom stage, so after dm-crypt devices have been mapped (if cryptsetup-initramfs is installed and the crypttab is not empty, that is). So you're essentially asking to set the timeout to 10s. > BTW, I've just noticed that the timeout introduces a second annoying > regression: If there is a temporary issue with the DHCP server just > after the machine has been restarted, so that the timeout is reached, > the user will not be able to unlock the disk until he can go back in > front of his machine! You mean the timeout from configure_networking() it init-premout stage? That's not a regression from 2020.79-1, didn't touch the premount script for many years. Yes configure_networking() might fail and leave the system without network, however dropbear-initramfs is not the place to fix this. configure_networking() comes from initramfs-tools, and AFAICT the same problem arises for NFS mounts. > My proposal would solve this issue. Then I probably didn't understand the issue you're describing. -- Guilhem.
signature.asc
Description: PGP signature
