gst-plugin-scanner hangs, eating CPU time

[Tim-Philipp Müller]

On Fri, 2011-11-11 at 01:57 +0100, Rüdiger Kupper wrote:

Hi Rüdiger,

> we run Linux Terminal Servers (LTSP) at a German school, for approx. 800
> users. The servers run standard Edubuntu, but are located behind a
> firewall that requires authentication for outgoing traffic.
> 
> I frequently see a lot of "gst-plugin-scanner" processes running on our
> servers, without ever terminating, and eating up CPU time. Since many
> users log into the same server, this easily pulls up the load to 10 or
> above, basically killing the servers and frustrating the users (and
> admin ;-) ).
> 
> I have not been able to determine, what "gst-plugin-scanner" actually
> does. I can reproduce that it starts when users try to open sound files
> using banshee or totem.

GStreamer maintains a cache file ("registry") of available plugins. When
GStreamer is initialised by an application, it loads the existing
registry cache if there is one and then checks the available plugins. If
any plugins were were added or have changed since the last time they
were introspected, GStreamer will load those plugins to update the
cached information.

gst-plugin-scanner does exactly this, but out of process, so if a plugin
crashes while loading it doesn't take down the entire application and
can instead just be blacklisted.

> From its name I suspect that "gst-plugin-scanner" may try to contact an
> external web site in order to check for plugins, but this is just my
> wild guess. If so, it certainly gets rejected by our proxy.

The scanner itself does not establish any network connections (unless
the plugins are on a network-mounted part of the file system of course).
It just loads (filesystem-)local plugins and sends the information it
found in the plugins back to the application that spawned it.

It is possible of course that some plugin does that kind of thing in its
plugin init function, but that seems rather unlikely and I'm not aware
of any such plugins.

> Could you clarify for me what "gst-plugin-scanner" actually does? If it
> does web traffic, which site is it trying to reach? (If I knew the
> address I could configure our proxy to let it pass.)
> 
> Or is there any other reason why "gst-plugin-scanner" should fail so
> badly in an LTSP-environment?
> 
> I'd strongly appreciate your help, since this is really a critical
> problem in our setup.
> 
> As a workaround, I have removed execute permissions on the
> "gst-plugin-scanner" binary, but I do not feel well with that, not
> knowing what it does.

That should not be a problem. In this case GStreamer should just fall
back to loading the plugin in-process. You can achieve the same thing by
setting the GST_REGISTRY_FORK environment variable to "no".

What version of GStreamer core are you using on those machines? There
have been a few fixes for corner-cases in gstpoll if I remember
correctly, but I am not sure those ever caused problems on Linux
systems.

Have you tried attaching to one of those runaway scanner instances with
strace or gdb to see what they're doing?

Did you check what plugins those runaway scanners have open?
(cat /proc/$PID/maps | grep gst) Maybe there's one that all those
runaway scanners have in common..

 Cheers
  -Tim