25/11/13 21:40, intrigeri wrote:
> anonym wrote (25 Nov 2013 19:24:32 GMT) :
>> I managed to reproduce it after a couple of reboots and, unsurprisingly,
>> it's a race condition. See commit 4df28d9 for more info.
>
> Congrats!
>
> Why set a 5 seconds timeout to udevadm --settle, instead of the
> default 120 seconds?
Good catch! I was trying out what happens when `udev settle` times out
(exit status etc) and apparently committed it by mistake. Fix pushed.
Actually this relates to an interesting potential issue; do we want to
potentially block the post-login script from finishing (and hence the
GNOME desktop from starting, leaving an empty blue screen) for up to 120
(or whatever) seconds? I suppose this could happen with some faulty
hardware and/or crappy udev rules.
Something that would make the exposure to this smaller would be to only
replay network device-related triggers, and I've tried to add
`--subsystem-match=net` to the `udevadm trigger` call in
tails-unblock-network, but that only added my wired NIC, not my wireless
NIC. To get the latter to load (I got hints by looking at `udevadm
monitor`) I needed to add the following too
--subsystem-match=module --subsystem-match=queues \
--subsystem-match=drivers
While adding those too wouldn't be a problem, I just don't feel
confident this will be enough for all network devices imaginable.
Another way to completely avoid this type of blocking would be to:
1. (re)start network-manager in tails-unblock-network, not in TG's
post-login script like now, and
2. start tails-unblock-network in the background in TG's post-login
script (now it starts "blocking").
That looks better to me, and starting NM in there instead actually makes
sense. Perhaps renaming it to `tails-enable-networking` also would be a
good idea, especially when we add the enable/disable networking feature
(which now is only some GUI-programming in TG away, plus an if-statement
in TG's post-login script that control whether to start
tails-enable-networking or not).
Thoughts?
Cheers!
