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!

  • 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
  • @JacobVlijm so, this is Unity specific right ? Unity has mechanism for that already. What's the requirements ? Only to know process name same as in the ps and xprop output ? – Sergiy Kolodyazhnyy Oct 10 '16 at 1:11
  • @Serg The process name, "calculated" from the .desktop file, which is not necessarily the WM_CLASS. The WM_CLASS can be set from within the application. – Jacob Vlijm Oct 10 '16 at 4:49
  • @JacobVlijm ah, so suppose you started firefox.desktop, it launches firefox with PID 1234, but changed WM_CLASS to something like 'Totally Not Firefox'. The .desktop file however doesn't change. You want to get the name attached to PID 1234 regardless of WM_CLASS. I think I see exactly what needs to be done. But you didn't answer my first question - is it OK if it's only for Unity ? – Sergiy Kolodyazhnyy Oct 10 '16 at 4:55

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?

  • 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

The xprop command (followed by alt-tab to the relevant app window, then click once in the window) seems to do the trick for me.

  • WM_CLASS often matches the process name, but definitely not always. Defining (coding) a window, I can give it any WM_CLASS I want. Even did it myself to make windows, running from different processes, group in one launcher icon. – Jacob Vlijm Oct 9 '16 at 5:52
  • Oh. That's a shame. It was worth my adding the disclaimer "...seems to do the trick for me" at the end. It's a function that I really expected to be built into the operating system, and I thought that I just didn't know how to do it. At the very least, I would expect the information in "About". – el_gallo_azul Oct 10 '16 at 0:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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