Launcher – How to Determine an Application’s Process Name

desktoplauncherprocess

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!

Best Answer

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?

Related Question