Chrome leaves behind stray processes on exit. Why? How to get rid of them?

[Alain Kalker]

For quite some time now, I'm seeing that the Linux Chromium OS version of chrome often leaves processes running in the background when it exits.

While I most often see processes which may be related to the Flash plugin, I remember having seen others, too.

I'm using prebuilt snapshot binary http://commondatastorage.googleapis.com/chromium-browser-snapshots/Linux_ChromiumOS/237968/chrome-linux.zip on Arch Linux x86_64.

Is this expected behaviour, and if so, how does Chromium OS manage these processes? How can I best deal with these processes on a developer system?

While I know that the regular desktop version of chrome may leave processes running to facilitate certain extensions, isn't chrome for Chromium OS supposed to be a self-contained entity?

Phrased another way, if I were to use either my desktop or a Chromebook with multiple Google accounts, how can I be sure that these background processes will not interfere with online or offline data from multiple accounts?

I'm currently using a wrapper script to kill any left behind processes, I wonder what is the best way of dealing with them without losing data?

[Luigi Semenzato]

Are you sure these are Chrome processes? Can you send the output of ps -axwww?

I agree with you that all Chrome processes should end when Chrome
exits, without external intervention. However, running Chromium OS
Chrome on Arch Linux is a little strange. Why not use the standard
Linux Chrome?

> --
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>

[Alain Kalker]

Thanks for the quick reply :-)

On Sunday, December 8, 2013 4:55:38 PM UTC+1, Luigi Semenzato wrote:

Are you sure these are Chrome processes?  Can you send the output of ps -axwww?

Yes, I'm sure, because I've compared the process trees between the browser version and the Chromium OS UI.

I hope you don't mind me using `ps jf -s <session id>`, for I like to be able to see process groups and sessions as well as wide commandline output in a tree without specifying too many options. Also, I haven't been able to get ps -axwww to select only a single session id without grep'ping the output for it after.

Here's a log of a sample run of my 'session manager' script (it isn't a real X session manager, hence the error from Matchbox at the top) in which Chrome left a few processes behind:

http://pastie.org/private/4ypeiavhdvufqdyougapiw

Ignore the chromiumos-ui-session command line for now, it basically starts Chrome as:

/usr/lib/chromiumos-ui/chrome --user-data-dir=<userdir> --login-user=<user> .

 

I agree with you that all Chrome processes should end when Chrome
exits, without external intervention.  However, running Chromium OS
Chrome on Arch Linux is a little strange.  Why not use the standard
Linux Chrome?

Because I can :-) Well, seriously, because having Chromium OS's UI running in a window or a DM session alongside your regular desktop with all its perks is a nice thing ;-) 

[Alain Kalker]

On Sunday, December 8, 2013 6:44:27 PM UTC+1, Alain Kalker wrote:

Thanks for the quick reply :-)

On Sunday, December 8, 2013 4:55:38 PM UTC+1, Luigi Semenzato wrote:

Are you sure these are Chrome processes?  Can you send the output of ps -axwww?

Yes, I'm sure, because I've compared the process trees between the browser version and the Chromium OS UI.

I hope you don't mind me using `ps jf -s <session id>`, for I like to be able to see process groups and sessions as well as wide commandline output in a tree without specifying too many options. Also, I haven't been able to get ps -axwww to select only a single session id without grep'ping the output for it after.

Here's a log of a sample run of my 'session manager' script (it isn't a real X session manager, hence the error from Matchbox at the top) in which Chrome left a few processes behind:

http://pastie.org/private/4ypeiavhdvufqdyougapiw

Woops, guess I should have made that public, here goes:

http://pastie.org/8537770

[Alain Kalker]

Hmmm, experimenting with the wrapper and both desktop and Chromium OS versions of chromium resp. chrome turned up something interesting, which smells like a bug. Here's how to reproduce (using desktop Chromium in this example):

In one terminal window, start chrome, _without_ any commandline parameters or URL:

$ chrome

(Chromium opens whatever is set as default opening page, the terminal will not respond to input (except Ctrl-C or ctrl-Z, of course) because Chromium is in the foreground.)

Now open or switch to another terminal window and start it again, the same way:

$ chrome

Created new window in existing browser session

$

(Except there is _no_ new tab or window opened, because no URL was specified.)

Now _close_ the Chromium window, expecting the first terminal window to show a prompt again, indicating that Chromium has exited.

Nope, it doesn't. One has to type Ctrl-C or kill Chromium some other way.

I wonder if this has any bearing on the 'runaway processes' issue...

Any comments on this?

[Alain Kalker]

oops again C&P mishap, substitude 'chromium' for 'chrome' in the commands.

[Luigi Semenzato]

Here's my take. You say you like to run Chromium OS Chromium outside
Chromium OS goes (this sentence has too many chromes in it) because
you can. Well, maybe you can't. Chromium OS Chromium is the only UI
between the user and the rest of the system, so it has hooks into
various subsystems. I doubt there is enough interest in making it
work properly on other Linux distributions.

Your other problem, however, looks real, and you have a nice repro
case. It would be worth bringing it to the attention of the Chromium
developers at chromi...@chromium.org, and presenting it exclusively
as a Chromium on LInux problem so that there is no confusion.

Thanks!

[James Cook]

Running Chromium OS Chrome on Linux is just a convenience for Chromium OS developer. A lot of us refer to this as linux_chromeos, similar to how the buildbots name things.  I would describe it as "mostly working" :-)

I'll bet the problem is in the "hand-off" code that tries to open a new window when you start a second instance of Chrome. There's code on the normal Linux build that does this, but that probably won't work with the Chromium OS build, since Chromium OS only expects one copy of Chrome running.

James

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

[Bill Richardson]

You know that Chrome has a "keep running in the background" setting, right?  I don't know if Chromium has that option too, but you might check to be sure.

Art for Art's Sake

Engineering for Money

[Alain Kalker]

On Monday, December 9, 2013 6:29:51 PM UTC+1, Bill Richardson wrote:

You know that Chrome has a "keep running in the background" setting, right?  I don't know if Chromium has that option too, but you might check to be sure.

Yep, Chromium has that, too.

I have this setting unchecked, but still I see background processes running after Chromium exits.

Mostly they seem to be related to the Pepper Flash plugin, but I've seen others as well.

If I can kill these processes by running `kill -9 <pid>` (they often don't die when I just do a `kill <pid>`), why can't the 'master' Chromium process do the same if the relevant setting is unchecked?

[Alain Kalker]

While watching the process tree from node-webkit and searching some old bug reports, notably [1], I saw some very interesting commandline options that are poorly documented:

--child-clean-exit

--wait-for-children-before-exiting

My questions: why are these options apparently not standard on 'production' browsers?

Mentioned in [1], the reason for not waiting for children to exit quickly appears to be to enable them to write profiling data. Is this really so important in a production environment that clean exit of all processes is secondary?

Perhaps someone could have a look at the current state with regard to the deadlock problem mentioned in [2].

[1]: https://codereview.chromium.org/19231006/

[2]: https://code.google.com/p/chromium/issues/detail?id=263594