wpa_cli.sh is called whenever wireless connectivity goes up/down. It can also be used from the command line to pause wireless and all init scripts that depend on the wireless interface. However, when IN_BACKGROUND is true, openrc returns as soon as net.wlan0 is started (rc_parallel=NO). If another disconnect comes in before all the daemons needing wireless are started, openrc will get confused and leave some processes marked as 'starting' while others are 'stopping'. Steps to reproduce: This pretty much always works for me where ntp-client can take up to 10 seconds to 'start'. 1.) Have some daemon that takes a while to boot depend on net. 2.) # rand_sleep() { sleep $(echo "${RANDOM} / 32768" | bc -l); } # for ((i=0;i<10;i++)) do; wpa_cli disconnect; rand_sleep; wpa_cli reassociate; rand_sleep done 3.) Look at rc-status, the wireless interface will be 'starting' while some other processes are 'stopping'. Eventually, something does giveup, and the processes that were 'stopping' will be 'stopped', which is the issue, they should have been restarted. I'm attaching a patch. The loop on rc-status seems to be fixing this, although I'll admit it's not pretty. I've also added a lockfile which may not be necessary. During testing, I never saw the lock not get aquired. However, it is easy to see that wpa_cli.sh does have locking issues, all you need to do is call it by hand.
Created attachment 202355 [details, diff] patch for wpa_cli.sh
Having a busyloop is not a solution, but a hack ;-) The problem seems to be the way network behaves in openrc. From what the author of openrc says, there is a new way for handling network coming, which handles wpa_supplicant differently. (Have a look at the comments here: http://roy.marples.name/projects/openrc/ticket/167 ) So for now, I think the best thing to do is to wait until the new openrc version comes out, and see if the problem persists.
(In reply to comment #2) > Having a busyloop is not a solution, but a hack ;-) Oh, I fully agree, but as someone relying on this behavior to stop various other daemons, I figured it was worth posting here. > So for now, I think the best thing to do is to wait until the new openrc > version comes out, and see if the problem persists. Fine by me, let me know if you'd like me to do any testing.
I've tried to reproduce this issue with sys-apps/openrc-0.6.0-r1 and net-wireless/wpa_supplicant-0.7.1 and do not see a problem if I had some sleeps in the net init script (with IN_BACKGROUND=true). However, I am not totally clear as to the original problem -- Justin, if you're still available could you clarify: "3.) Look at rc-status, the wireless interface will be 'starting' while some other processes are 'stopping'. Eventually, something does giveup, and the processes that were 'stopping' will be 'stopped', which is the issue, they should have been restarted. " By "Eventually, something does giveup" do you mean that the net service starts or do you mean that it stopped and 'gave up' trying to start? Also, do you have the time to test this out with the sys-apps/openrc-0.6.0-r1? Thanks. Trevor
(In reply to comment #4) > I've tried to reproduce this issue with sys-apps/openrc-0.6.0-r1 and > net-wireless/wpa_supplicant-0.7.1 and do not see a problem if I had some sleeps > in the net init script (with IN_BACKGROUND=true). > > However, I am not totally clear as to the original problem -- Justin, if you're > still available could you clarify: > > "3.) Look at rc-status, the wireless interface will be 'starting' > while some other processes are 'stopping'. Eventually, something > does giveup, and the processes that were 'stopping' will be > 'stopped', which is the issue, they should have been restarted. > " > > By "Eventually, something does giveup" do you mean that the net service starts > or do you mean that it stopped and 'gave up' trying to start? Eventually is on the order of minutes to tens of minutes. Then end result is net.* is started but some of the other services that depend on net are stopped. > > Also, do you have the time to test this out with the sys-apps/openrc-0.6.0-r1? Sure, give me until mid next week though please.
I can still reproduce. I'm attaching a (slightly altered for readability) log.
Created attachment 221175 [details] log
