# wpa_supplicant closing fine but leaving file behind?

## Marnux

I have the strange problem that when i shutdown or reboot my computer, the wireless interface is stopped without errors (including wpa_supplicant), but it gives me errors when booting again.

The error is either "Failed to connect to wpa_supplicant - wpa_ctrl_open: Address already in use" or "bind(PF_UNIX): Address already in use".

I tracked down the problem to what i think is the /var/run/wpa_supplicant/eth1 file still existing on boot.

When i delete this file manually after i get the first error listed the following boot is normal again, if the second error is displayed it keeps giving me one of the prior errors after rebooting.

I think this has something to do with the fact that after the first error the interface is unusable, but after the second error you can still use the interface and it's stopped during the shutdown fase.

I started to investigate the /lib/rcscripts/net/wpa_supplicant.sh file to see if i could find anything interesting. In the wpa_supplicant_kill function i saw the code for stopping wpa_supplicant and wpa_cli.

What interested me was that there were 2 lines at the bottom of the function that should be run if wpa_supplicant exits uncleanly and they delete the /var/run/.../eth1 file.

So i assume the script does this also when closing down correctly.

A dirty hack for me would be to just make sure it gets run everytime i reboot or shutdown by making it run in the same if structure as stopping wpa_supplicant or even make it a seperate script to run at shutdown after wpa_supplicant is stopped.

This would take away my problem, but i'm hoping there's a cleaner solution to this.

So any help is appreciated.

Sorry for not having all config and stuff at the ready but i'm using another computer to post here.

----------

## nein

Same problem here!!

Does anybody have a solution ?

----------

## sge_kane

same here....

probably a baselayout bug??

----------

## nein

No solution yet ?

I have also had a look at /lib/rcscripts/net/wpa_supplicant.sh and do not understant why /var/run/wpa_supplicant/eth1 is left sometimes during shutdown.

----------

## sge_kane

The problem apparently disappeared here afer upgrading to baselayout-1.12.5-r2...

What version are you running?

----------

## Marnux

I stopped getting the errors after some fiddling. It still appears sometimes but isn't really annoying anymore. Maybe upgrading to the new baselayout makes sure it never comes back.

----------

## nein

I am using baselayout 1.12.5-r2 (the current stable one) and it happens about 50% of the times

----------

## Marnux

If i keep my wireless up and let gentoo shutdown, it seems to work 95% of the time.

----------

## cgmd

I have an almost identical problem, for which I've been running a thread elsewhere, but without results. I'm also using baselayout-1.12.5-r2.

In my case, the file which which hangs around after reboot, causing the wpa_supplicant failure is /var/run/wpa_supplicant/ath0, shown as follows:

```
Using existing control interface directory.

bind(PF_UNIX): Address already in use

ctrl_iface exists and seems to be in use - cannot override it

Delete '/var/run/wpa_supplicant/ath0' manually if it is not used anymore

Failed to initialize control interface '/var/run/wpa_supplicant'.

You may have another wpa_supplicant process already running or the file was

left by an unclean termination of wpa_supplicant in which case you will need

to manually remove this file before starting wpa_supplicant again.
```

The problem is a major annoyance... I'm glad to find there are others sharing the issue...  :Very Happy: 

----------

## cgmd

I now believe baselayout is, indeed, at the heart of this issue. On a lark, I simply re-emerged it:

```

 emerge -pv baselayout

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R   ] sys-apps/baselayout-1.12.5-r2  USE="unicode -bootstrap -build -static" 0 kB

Total size of downloads: 0 kB

```

...and, voila! The problem, for me appears gone!  :Very Happy: 

(At least over several restarts) I'll report back if it happens to recur!

----------

## sge_kane

Nice, that I'm not the only one who is no longer annoyed by this...   :Very Happy: 

----------

## cgmd

Sad to report that, for me, this is only a bandaid, not a cure...  :Sad: 

Works for a while, then fails... 

So I still struggle with removing /var/run/wpa_supplicant/ath0 and, on occasion, using killall wpa_supplicant, before I can reboot without the problem arising...

----------

## nein

Same here. Re-emerged baselayout, rebooted and the problem arose again.

I noticed baselayout complained about the format of my /etc/conf.d/net file. I have updated this config file to the new format just in case it makes any difference (I think it won't but let's see).

----------

## nein

Ok, belive it or not, adapting the format of the /etc/conf/net file to the new format seemed to solve the problem

I have rebooted 5 times and it worked ok every time. I even did turn off the computer, without shutdown and at boot time I saw the "bind(PF_UNIX): Address already in use" message but then wifi started ok.

I will report if it is just a coincidence and the problem arises again .

----------

## cgmd

What is the new /etc/conf.d/net format? Mine, now, looks like: 

```

modules=( "dhcp" "wpa_supplicant" )

# Configuration of wired stuff

config_eth0=( "dhcp" )

dhcpcd_eth0="-t 10"

# Configuration of wireless - Netgear wg511t

config_ath0=( "dhcp" )

dhcpcd_ath0="-t 30"

wpa_supplicant_ath0="-Dmadwifi"

wpa_timeout_ath0=60

preferred_aps_ath0=( "cgmd-home" "cgmd-work" )

config_cgmd-home=( "dhcp" )

config_cgmd-work=( "dhcp" )

```

Is there a newer format??

----------

## nein

I don't have my laptop here but your net file looks fine. Mine was created 3 years ago and used the old format

----------

## nein

False alarm!!

It just happened again  :Sad:  This is getting reeeeeeeeally annoying

----------

## cgmd

Well, now I have good news to report...

From the above /etc/conf.d/net file, I removed the "preferred_aps_ath0" line: 

```
preferred_aps_ath0=( "cgmd-home" "cgmd-work" ) 
```

And, ever since, through multiple restarts and even different wap's, it has not recurred.

I'm now tentatively "holding my breath" and hoping!   :Smile: 

----------

## nein

I do not have that line but I wish you good luck anyway . 

Changes in the net file solve the problem for a while ??? This is really strange

----------

## cgmd

I'll post a follow-up, good or bad, in a day or so...

----------

## cgmd

Just checking in for the day to affirm that my ath0 problem has, indeed, resolved, and the only thing I can attribute it to is simplification of my /etc/conf.d/net, as shown above...

I still don't know the cause.  :Confused: 

----------

## richard_

I have the same problem!

I think it's time to file a bug report.  :Exclamation: 

----------

## shrtckt

Same problem here, dhcpcd was not shutting down properly during the wpa_supplicant shutdown process. It had something to do with xdm being  added to rc-update (default). I was messing around with a fglrx problem, so I temporarily removed xdm from the rc scripts; then I noticed  that a line was added to the  wpa_supplicant shutdown process "shutting  down dhcp..." or something like that. The problem went away. After finishing with fglrx, I added xdm back to rc-update (default). I noted that the system was still shutting  down dhcp during wpa_supplicant shutdown & the problem never repeated. I have booted & shutdown (using  apcid) 36 times now - with NO errors. I'm sure it would have screwed-up by now. I do know for a fact that when the system shuts down dhcp properly during a system shutdown - the problem will not duplicate. I'm not really sure what I did to change it- possibly forcing rc-update to reorganize the script order or something? Anyway, try removing xdm from rc-update then adding it back in (forcing it to reconfigure the order). I know it sounds simple, but it seems to have corrected it for me.  :Smile:  If anyone else can explain why this worked, I'm all ears.

----------

## richard_

 *shrtckt wrote:*   

> Same problem here, dhcpcd was not shutting down properly during the wpa_supplicant shutdown process. It had something to do with xdm being  added to rc-update (default). I was messing around with a fglrx problem, so I temporarily removed xdm from the rc scripts; then I noticed  that a line was added to the  wpa_supplicant shutdown process "shutting  down dhcp..." or something like that. The problem went away. After finishing with fglrx, I added xdm back to rc-update (default). I noted that the system was still shutting  down dhcp during wpa_supplicant shutdown & the problem never repeated. I have booted & shutdown (using  apcid) 36 times now - with NO errors. I'm sure it would have screwed-up by now. I do know for a fact that when the system shuts down dhcp properly during a system shutdown - the problem will not duplicate. I'm not really sure what I did to change it- possibly forcing rc-update to reorganize the script order or something? Anyway, try removing xdm from rc-update then adding it back in (forcing it to reconfigure the order). I know it sounds simple, but it seems to have corrected it for me.  If anyone else can explain why this worked, I'm all ears.

 

I'm trying your solution and so far the problem hasn't recurred.  I'll report back in a week or two.

Thanks!  :Smile: Last edited by richard_ on Thu Nov 30, 2006 4:56 am; edited 1 time in total

----------

## shrtckt

 *Quote:*   

> I'm trying your solution and so far the problem hasn't occured. I'll report back in a week or two.
> 
> 

 Cool, I forgot to add that I have wpa_supplicant built  with +dbus support, and dbus added to the rc scripts.  Once again, I'm not really sure what actually fixed the problem; but as of this post, I still have not had any errors.

----------

## ipreiml

Hi there, I had the same problem and re-adding xdm with rc-update didn't help  :Sad: . Anyway, I solved the problem by altering the following lines in /lib/rcscripts/net/wpa_supplicant.sh from:

```

       # If wpa_supplicant exits uncleanly, we need to remove the stale dir

        [[ -S "/var/run/wpa_supplicant/${iface}" ]] \

                && rm -rf "/var/run/wpa_supplicant/${iface}"

```

to:

```

        # If wpa_supplicant exits uncleanly, we need to remove the stale dir

        [[ -S "/var/run/wpa_supplicant/${iface}" ]] \

                && rm -rf "/var/run/wpa_supplicant"

```

My guess is that the startup scripts check whether the directory "/var/run/wpa_supplicant" exists or not.  They doesn't check whether the directory is empty or not, so it is not sufficient to only remove the ${iface} file. I haven't checked the code yet, but it seems to work for me.

----------

## kds66

Same issue here, even after making the change. It happens in about 10-15% of the reboots.

----------

## kds66

Hmm, I wonder how effective the above workaround would be at boot time, considering that /var/run is cleared during the boot sequence.

Anyway, I just found the following, possibly related line in dmesg output:

ndiswrapper (iw_set_freq:334): setting configuration failed (00010003)

Still does not help me but perhaps somebody has an idea?

----------

## lost-distance

I too have been seeing the "wpa_ctrl_open: Address already in use" bug recently, and believe I have identified the problem.

Temporary socket files named /tmp/wpa_ctrl_pid-counter are being left behind when the system shuts down abnormally. After the next boot a new wpa_supplicant process (or actually wpa_cli process) with the same process-id will try to create the same file and fail for some reason. That is why the bug is intermittent - it depends on the process-id. Such a failure to handle an existing file is clearly an application bug.

A simple workaround is to enable WIPE_TMP in the /etc/conf.d/bootmisc configuration file:

```
WIPE_TMP="yes"
```

Alternatively, if wiping /tmp is too drastic, just append /tmp/wpa_ctrl_* to the list of files deleted by the /etc/init.d/bootmisc startup script:

```
rm -f /tmp/.X*-lock /tmp/esrv* /tmp/kio* /tmp/jpsock.* /tmp/.fam* /tmp/iceauth.* /tmp/xauth.* /tmp/wpa_ctrl_*
```

These have worked for me so far.

----------

