Shell Process – Can’t Kill Gedit Process from Its PID

background-processgeditkillprocessshell

This is the sequence of commands, gedit starts, but it cannot be killed from its process ID

$ gedit&
$ t=$!
$ echo $t
4824
$ kill $t
bash: kill: (4824) - No such process

It would work just fine for a sleep process, like

sleep 999&
[1] 4881
$ t=$!
$ echo $t
4881
$ kill $t
$ ps -p $t
[1]   Terminated              sleep 999

What's the difference? How can the gedit process be terminated?

Best Answer

The gedit process is already terminated.

Remember how Windows applications mainly worked back in the Win16 days before Win32 came along and did away with it: where there were hInstance and hPrevInstance, attempting to run a second instance of many applications simply handed things over to the first instance, and this made things difficult for command scripting tools (like Take Command) because one would invoke an application a second time, it would visibly be there on the screen as an added window, but as far as the command interpreter was concerned the child process that it had just run immediately exited?

Well GNOME has brought the Win16 behaviour back for Linux.

With GIO applications like gedit, the application behaves as follows:

  • If there's no registered "server" named org.gnome.gedit already on the per-user/per-login Desktop Bus, gedit decides that it's the first instance. It becomes the org.gnome.gedit server and continues to run.
  • If there is a registered "server" named org.gnome.gedit already on the per-user/per-login Desktop Bus, gedit decides that it's a second or subsequent instance. It constructs Desktop Bus messages to the first instance, passing along its command line options and arguments, and then simply exits.

So what you see depends from whether you have the gedit server already running. If you haven't, you'll be in sebvieira's shoes and wondering why you aren't seeing the behaviour described. If you have, you'll be in your shoes and seeing the gedit process terminating almost immediately, especially since you haven't given it any command-line options or arguments to send over to the "first instance". Hence the reason that there's no longer a process with that ID.

Much fun ensues when, as alluded to above, the per-login Desktop Bus is switched to the "new" style of a per-user Desktop Bus, and suddenly there's not a 1:1 relationship between a Desktop Bus and an X display any more. Single user-bus-wide instance applications suddenly have to be capable of talking to multiple X displays concurrently.

Further hilarity ensues when people attempt to run gedit as the superuser via sudo, as it either cannot connect to a per-user Desktop Bus or connects to the wrong (the superuser's) Desktop Bus.

There's a proposal to give gedit a command-line option that makes the process that is invoked just be the actual editor application, so that gedit would be useful as the editor pointed-to by the EDITOR environment variable (which it isn't for many common usages of EDITOR, from crontab to git, when it just exits immediately). This proposal has not become reality yet.

In the meantime, people have various ways of having a simple second instance of a "lightweight text editor", such as invoking a whole new Desktop Bus instance, private to the invocation of gedit, with dbus-run-session. Of course, this tends to spin up other GNOME Desktop Bus servers on this private bus as they are in turn invoked by gedit, making it not "lightweight" at all.

The icing on the cake is when you've followed this recommendation or one like it and interposed a shell function named gedit that immediately removes the gedit process from the shell's list of jobs. Not only does the process terminate rapidly so that you don't see it later with kill or ps, but the shell doesn't even monitor it as a shell-controlled job.

Further reading

Related Question