How to close wicd gui without leaving dangling process

1

1

If I open the wicd gui with wicd-gtk &, closing it (even using the "Quit" button) may close the gui, but always leaves a process wicd-client running in the background apparently doing nothing. I noticed this because I checked my running processes after 20 days of uptime only to find about 15 wicd-clients listed. FYI I'm running debian jessie.

How come these processes don't die with the gui and how can I fix this?

I have noticed that if I start the client without backgrounding it (i.e. simply with the command wicd-gtk) when I close the gui, the terminal still hangs until I CTRL-C. Upon hitting CTRL-C, the wicd-client process closes.

nullUser

Posted 2014-08-26T04:21:02.930

Reputation: 593

Answers

1

wicd-gtk hangs when its window is closed unless it is invoked as wicd-gtk --no-tray or wicd-client --no-tray (withoutwicd-curses installed, wicd-client invokes wicd-gtk).

The quick solution is to put something like this in your PATH or shell profile that replaces wicd-gtk with wicd-gtk --no-tray.

For users who do not want to run the client in the background, or use the feared wicd-curses client, this is annoyingly not configurable without the command-line option; wicd-client.py would need to be patched. The patch could be a check for an existing process, then bringing up a GTK window attached to that process instead of starting.

insignificant zebra

Posted 2014-08-26T04:21:02.930

Reputation: 233

1

I still have the same problem with wicd. The underlying problem, is that when you start wicd, it launches separate processes to handle whatever it needs to handle that's not your input. These processes interact but are not one process, the GUI is one process, the monitor is one process, the daemon is also it's own process. You can see below that it is not one program being launched in the traditional sense, but three or four python scripts launched by separate python interpreters.

If you open a terminal examine it with top -c (the show command option) you'll find the processes running are:

/usr/bin/python -O /usr/share/wicd/daemon/monitor.py
/usr/bin/python -O /usr/share/wicd/daemon/wicd-daemon.py
/usr/bin/python -O /usr/share/wicd/gtk/wicd-client.py

Now I'm running ubuntu, which is a debian variant, but the process that works for me should probably work for you with no or little adjustment.

1st, get the pids with ps aux | grep wicd

2nd, run kill and the pids of the processes.

OR

if you have no other python interpreters open running processes you can get them all at once with

kill $(pidof python)

blanket_cat

Posted 2014-08-26T04:21:02.930

Reputation: 136

Thanks @DavidPostill, is that your way of saying my answer is formatted wrong? – blanket_cat – 2014-08-26T06:53:48.157

Ha! okay, thanks. I'm not used to people being super nice on the internet. – blanket_cat – 2014-08-26T06:58:50.300

1I'm more interested in an automatic solution. I don't want to have to remember to kill these processes every time I close wicd. Is this really the design the authors had intended? – nullUser – 2014-08-26T13:32:32.487

The best solution I can think of is to take something like the while structure outlined in the solution here, and set it to wait for your gui to die, then add a line that instructs the script to kill the remaining processes, if the GUI is no longer alive. http://stackoverflow.com/questions/1058047/wait-for-any-process-to-finish

– blanket_cat – 2014-08-27T02:47:13.713

-1

You don't say whether you're running wicd-gtk or wicd-curses? It sounds like GTK since you mention "button".

wicd-gtk is a single process (Python session). Sorry to knotech, but you're just wrong. There are daemon and monitor processes, but they are supposed to remain running at all times and it is extremely unlikely that there will be multiple copies, and they won't be called wicd-client. Just for completeness, the daemon (and monitor) can be started by running wicd-client, but this will only happen if they aren't already running and only after you enter your gksudo password. If you kill the daemon then your networks will no longer be managed, they won't automatically (re-)connect, and you may be left without a connection.

So wicd-gtk starts one or both, or neither, of a window and a tray icon. Typing just wicd-gtk (or typing wicd-client which will run your installed type of wicd client) should start both. wicd-gtk --tray will start just the tray, wicd-gtk --no-tray just the window. wicd-gtk --only-notifications will start neither, just spawning a process which can give you notification bubbles when your networks are connected or disconnected.

Pressing the Quit button in the window closes the window. It does not close the tray icon, so if you started with just wicd-gtk (or wicd-gtk --tray and later opened the window) then you will be left with a tray icon. This is known as "close to tray" behaviour and is very common, although it might be nicer for some people if it could be configured not to do it. If you started with wicd-gtk --no-tray then the whole thing will close when you press the Quit button. If you do have a tray icon (do you?) then you can close the whole thing from the tray icon context menu. Or with ctrl-C from wherever you started it.

If you don't have a tray icon and don't want one then start with wicd-gtk --no-tray. Then your client will close when you press the Quit button. If you want a tray icon but want the whole thing to go away when you press the Quit button in the window then at the moment you're out of luck.

Lithopsian

Posted 2014-08-26T04:21:02.930

Reputation: 1

wicd-client will spawn wicd-gtk processes WITHOUT prompting for gksudo elevation on some distros, like Debian. Why is it "extremely unlikely" there will be multiple copies of wicd-gtk if it is invoked and closed several times? As of 1.7.2.4, it does not appear that the application stops itself or existing processes when it is started. Also according to man (8) wicd, reconnection should be done by wicd-daemon.py. – insignificant zebra – 2015-10-30T04:00:14.173