Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is the situation:

Working on (the next version of) a Unity Quick List editor, I would like to add a reliable way of "restarting" launcher icons. To do so, I need to remove the icon (editing gsettings) and replace it on the same position. So far no problem. However, if the application in question is running, user will possibly lose data, as the application will quit when it's icon is removed from the launcher. What I need is a reliable way to find an application's process name, to let the editor check in the list of running processes if the application is running, and send a warning message to the user that the icon can not be restarted if the application is running.

What I did so far is make the editor look into the desktop file, to read the command, also read the command, stripped from the directory section, and furthermore look into possible remote scripts the desktop file command might refer to, looking for strings starting with "./"

Although the method seems to work well with all applications I tested it on, I have the feeling there must be an easier way to cover the problem in an "all in one" way...

Is there?

Also suggestions to catch more exceptional situations are welcome!

share|improve this question
Why would an application quit when its icon is removed from the launcher? Quitting an application that is not pinned to the launcher causes its icon to be removed, but why would removing the icon quit the application? – Eliah Kagan Jan 5 '13 at 23:16
@Eliah: quitting is probably not the right expression, the application simply crashes.... – Jacob Vlijm Jan 6 '13 at 8:35
up vote 3 down vote accepted

There is no way to solve this in the general case. Whatever mechanism you come up with, I believe that it will always be possible to write a process that will elude you, unless you modify the way that processes are launched in the first place in order to track them that way.

Upstart has to deal with exactly the same problem to track if daemons are still running, and upstart job authors have to specify details (the number of forks) for upstart to track. Given that upstart cannot manage it without help, I don't think that you can, either. And upstart is even in control of the way that processes are launched, which I don't think you are here.

I think the best you can do is what you are doing already. Looking at /proc/<pid>/stat and /proc/<pid>/cmdline is a reasonably general way, but still will not catch every case. The pgrep command wraps this. If you aren't already using pgrep, take a look at the pgrep manpage for options of things you can match against.

Having said all that, I'm not convinced that you really need to do this in the first place. If you can't track the process, then I don't see how Unity could do this either. Wouldn't a better approach be to eliminate the application crashes in the first place? I would look into details of why your applications are crashing (surely that's a bug somewhere?), rather than trying to work around it as you have described. I wonder if this only affects Unity-aware applications which are calling back to Unity for extra functionality via DBus?

share|improve this answer
Thank you for your thorough answer! I will look into the details (especially your last paragraph), and will probably offer the icon "restart" function as an "experimental" option if I cannot find a 100% soulution. The good news is that in the meantime, I found no exceptions on the method I used. Thanks once again! – Jacob Vlijm Jan 6 '13 at 14:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.