On Sat, 29 Sep 2018 18:41:45 +0200 Michael Biebl <bi...@debian.org> wrote:
> > + # wait for udev to be ready (see #908796) > > + timeout=15 > > + until udevadm control -S || [ $timeout -le 0 ]; do > > + timeout=$((timeout-1)) > > + sleep 1 > > + done > > + udevadm control -S && log_success_msg || log_failure_msg > > This repeatedly tries to start the execution queue. > Besides having this side-effect, why is this a proper test to check if > udev is ready? this probably shows my ignorance about udev (and lack of documentation), but it seems to me there isn't a proper way to test if udev is ready as the bug doesn't affect my system, I cannot know the state of udev when the udevadm trigger is launched: it could be the control file is missing or it's created but the daemon is not already accepting events reading the source, there is a ping message that is recognized by the control socket, sent internally by udevadm settle, but there isn't a command line for that message in particular it seems to me the least dangerous command is to start the execution queue: in fact when udev is just started, the stop_exec_queue variable is set to false, then the start of exec queue command will set again stop_exec_queue to false and it should results in a no-op we could simply rerun udevadm trigger until it's ok, but it seems not a good idea https://github.com/kubernetes/kubernetes/issues/55007 may be their fix (calling settle with timeout before trigger) will work for us? I don't know, as there are many possible side effects depending on the hardware it could be a good idea to ask the developers, but reading https://github.com/systemd/systemd/issues/2477 it seems they are not really interested about this type of issue and in forward compatibility (it was running fine until they stopped to remove the control socked on exit) I hope I have answered your question, anyway tell me if I can do something more ciao!