Cannot restart banshee after crash

Also see same question here: http://askubuntu.com/questions/315292/how-to-restart-banshee-after-crash

On Wed, Jul 03, 2013 at 09:53:13PM -0000, Launchpad Bug Tracker wrote:
> You have been subscribed to a public bug:
>
> If banshee crashes the sound/audio system menu still shows it as
> available but nothing happens if I click on it. With ps I can see a
> defunct banshee process that cannot be removed. If I try to run banshee
> from the command line nothing happens. Restarting gdm and/or unity also
> has no effect. As far as I can tell there is now no way to start banshee
> short of rebooting which is annoying. Does anyone know how I can start
> banshee without closing everything down and rebooting? Perhaps there is
> some part of Ubuntu that controls the sound menu and I can restart that?
> I was hoping it was part of gdm or unity but restarting them didn't
> help.

Processes labelled <defunct> are zombie processes, which arise when the parent
process does not reap the process after they die. Could you provide the output
of "ps -ef | grep banshee" please?

  status incomplete

--
Kind regards,
Loong Jin

See link to askubuntu question for ps output but I don't see what you can learn from that. I'm not sure it is a banshee bug either. Banshee is dead but why cannot I start another banshee process?

Hmm, judging by the ps output, that looks like an init bug -- like I mentioned, defunct processes come from the parent process not reaping the child after it has died. However, it looks like the parent process is init (ppid=1) and init isn't reaping it, which shouldn't be the case[1].

Could you post the output of `banshee --debug` please?

[1] http://unix.stackexchange.com/questions/11172/how-can-i-kill-a-defunct-process-whose-parent-is-init

I see this on that link you provided: "init can never have zombie children. From the wikipedia article: When a process loses its parent, init becomes its new parent. Init periodically executes the wait system call to reap any zombies with init as parent. One of init's responsibilities is reaping orphans and parentless zombies" So I think that means init is the new parent not the old one.

This is the output of "banshee --debug" but at the moment I do not have a zombie banshee process. When I do, I'll re-run with "--debug"

** Running Mono with --debug **
[1 Debug 08:44:37.548] Bus.Session.RequestName ('org.bansheeproject.Banshee') replied with PrimaryOwner
[1 Info 08:44:37.561] Running Banshee 2.6.1: [Ubuntu 13.04 (linux-gnu, x86_64) @ 2013-04-21 19:43:57 UTC]
[1 Debug 08:44:37.567] Initializing GTK
[1 Debug 08:44:38.126] Post-Initializing GTK
[1 Debug 08:44:38.132] Configuration client extension loaded (Banshee.GnomeBackend.GConfConfigurationClient)
[1 Debug 08:44:38.133] Using default gconf-base-key
[1 Debug 08:44:38.189] Core service started (DBusServiceManager, 0.000744)
[1 Debug 08:44:38.191] Registering remote object /org/bansheeproject/Banshee/DBusCommandService (Banshee.ServiceStack.DBusCommandService) on org.bansheeproject.Banshee
[1 Debug 08:44:38.194] Core service started (DBusCommandService, 0.004611)
[1 Debug 08:44:38.222] Opened SQLite (version 3.7.15.2) connection to /home/john/.config/banshee-1/banshee.db
[1 Debug 08:44:38.223] Core service started (DbConnection, 0.028348)
[1 Debug 08:44:38.233] Database version 45 is up to date
[1 Debug 08:44:38.293] Core service started (PreferenceService, 0.018716)
[1 Debug 08:44:38.302] Core service started (Network, 0.009347)
[1 Debug 08:44:38.303] Registering remote object /org/bansheeproject/Banshee/SourceManager (Banshee.Sources.SourceManager) on org.bansheeproject.Banshee
[1 Debug 08:44:38.303] Core service started (SourceManager, 0.001069)
[1 Debug 08:44:38.311] Core service started (MediaProfileManager, 0.000395)
[1 Debug 08:44:38.315] Registering remote object /org/bansheeproject/Banshee/PlayerEngine (Banshee.MediaEngine.PlayerEngineService) on org.bansheeproject.Banshee
[1 Debug 08:44:38.317] Core service started (PlayerEngine, 0.006476)
[1 Debug 08:44:38.326] Registering remote object /org/bansheeproject/Banshee/PlaybackController (Banshee.PlaybackController.PlaybackControllerService) on org.bansheeproject.Banshee
[1 Debug 08:44:38.327] Core service started (PlaybackController, 0.001754)
[1 Debug 08:44:38.330] Starting - Startup Job
[1 Debug 08:44:38.330] Core service started (JobScheduler, 0.00366)
[1 Debug 08:44:38.337] IO provider extension loaded (Banshee.IO.Gio.Provider)
[1 Debug 08:44:38.389] Loaded HardwareManager backend: Banshee.Hardware.Gio
[1 Debug 08:44:38.390] Core service started (HardwareManager, 0.05952)
[1 Debug 08:44:38.391] Bus.Session.RequestName ('org.bansheeproject.CollectionIndexer') replied with PrimaryOwner
[1 Debug 08:44:38.392] Registering remote object /org/bansheeproject/Banshee/CollectionIndexerService (Banshee.Collection.Indexer.CollectionIndexerService) on org.bansheeproject.CollectionIndexer
[1 Debug 08:44:38.394] Core service started (Collect...

On Mon, Jul 08, 2013 at 07:45:40AM -0000, John Reid wrote:
> I see this on that link you provided: "init can never have zombie
> children. From the wikipedia article: When a process loses its parent,
> init becomes its new parent. Init periodically executes the wait system
> call to reap any zombies with init as parent. One of init's
> responsibilities is reaping orphans and parentless zombies" So I think
> that means init is the new parent not the old one.

Clarification: When a process dies, it becomes a zombie until its parent reaps
(wait/waitpid) it. If its parent dies without reaping it, the process gets
reparented to init, which has pid 1, which is in turn supposed to reap it. If
init doesn't reap the process (due to a bug in init itself), then it remains a
zombie child of init. So it's not that init can never have zombie children. It's
that init *should* never have zombie children for extended periods, because it's
init's job to reap these zombie children.

> This is the output of "banshee --debug" but at the moment I do not have
> a zombie banshee process. When I do, I'll re-run with "--debug"
>
> [...]

Unfortunately, this isn't very helpful -- that's a normal Banshee log. I need
the one when Banshee refuses to start in order to tell what's going on.

--
Kind regards,
Loong Jin

Banshee crashed again but the process didn't disappear. Here's the log for the banshee I'm trying to start.

john@W530$ banshee --debug
** Running Mono with --debug **
[1 Debug 17:54:39.785] Bus.Session.RequestName ('org.bansheeproject.Banshee') replied with InQueue

I've attached the log for the banshee that crashed.

Here is the current ps output:

john@W530$ ps -ef|grep banshee
john 2170 1711 0 17:58 pts/21 00:00:00 grep --color=auto banshee
john 25995 15673 4 13:00 pts/7 00:14:35 [banshee] <defunct>

What's process 15673? That's Banshee's current parent process.

Good point, I didn't check the output too closely. 15673 is the bash shell I started banshee from:

~/Downloads
john@W530$ ps -ef|grep 15673
john 4724 4624 0 18:59 pts/21 00:00:00 grep --color=auto 15673
john 15673 10712 0 Jul09 pts/7 00:00:00 bash
john 25995 15673 4 13:00 pts/7 00:14:35 [banshee] <defunct>

However banshee is not responding to Ctrl-C in the bash terminal nor to kills so what to do?

~/Downloads
john@W530$ kill -9 25995
~/Downloads
john@W530$ kill -15 25995
~/Downloads
john@W530$ kill 25995
~/Downloads
john@W530$ ps -ef|grep 15673
john 4780 4624 0 19:00 pts/21 00:00:00 grep --color=auto 15673
john 15673 10712 0 Jul09 pts/7 00:00:00 bash
john 25995 15673 4 13:00 pts/7 00:14:35 [banshee] <defunct>

On Mon, Jul 15, 2013 at 06:01:36PM -0000, John Reid wrote:
> Good point, I didn't check the output too closely. 15673 is the bash
> shell I started banshee from:
>
> ~/Downloads
> john@W530$ ps -ef|grep 15673
> john 4724 4624 0 18:59 pts/21 00:00:00 grep --color=auto 15673
> john 15673 10712 0 Jul09 pts/7 00:00:00 bash
> john 25995 15673 4 13:00 pts/7 00:14:35 [banshee] <defunct>
>
> However banshee is not responding to Ctrl-C in the bash terminal nor to
> kills so what to do?
>
> ~/Downloads
> john@W530$ kill -9 25995
> ~/Downloads
> john@W530$ kill -15 25995
> ~/Downloads
> john@W530$ kill 25995
> ~/Downloads
> john@W530$ ps -ef|grep 15673
> john 4780 4624 0 19:00 pts/21 00:00:00 grep --color=auto 15673
> john 15673 10712 0 Jul09 pts/7 00:00:00 bash
> john 25995 15673 4 13:00 pts/7 00:14:35 [banshee] <defunct>

Try killing the bash process itself. If that doesn't work, keep following the
trail up until you reach 1. There seems to be a parent process of that bash
process.

--
Kind regards,
Loong Jin

OK I can try and kill bash but I'd like to know what to do when the parent is 1. That is the problem and forces me to reboot.

Killing bash make the PPID 1 and banshee won't start

~/Downloads
john@W530$ kill 15673
~/Downloads
john@W530$ kill -9 15673
~/Downloads
john@W530$ ps -ef|grep banshee
john 6435 4624 0 20:04 pts/21 00:00:00 grep --color=auto banshee
john 25995 1 3 13:00 ? 00:14:35 [banshee] <defunct>
~/Downloads
john@W530$ banshee --debug
** Running Mono with --debug **
[1 Debug 20:05:23.875] Bus.Session.RequestName ('org.bansheeproject.Banshee') replied with InQueue

On Mon, Jul 15, 2013 at 07:05:49PM -0000, John Reid wrote:
> Killing bash make the PPID 1 and banshee won't start
>
> ~/Downloads
> john@W530$ kill 15673
> ~/Downloads
> john@W530$ kill -9 15673
> ~/Downloads
> john@W530$ ps -ef|grep banshee
> john 6435 4624 0 20:04 pts/21 00:00:00 grep --color=auto banshee
> john 25995 1 3 13:00 ? 00:14:35 [banshee] <defunct>
> ~/Downloads
> john@W530$ banshee --debug
> ** Running Mono with --debug **
> [1 Debug 20:05:23.875] Bus.Session.RequestName ('org.bansheeproject.Banshee') replied with InQueue

Hmm, very weird.
http://unix.stackexchange.com/questions/11172/how-can-i-kill-a-defunct-process-whose-parent-is-init
seems to show a similar case, with no solution.

This is just another stab in the dark, but could you check the output of "ps -p
25995 -o stat"? If it says "Z", then it would definitely be a zombie process.
Also please try "kill -SIGCHLD 1". This shouldn't kill init, but just notify
init that there's a child process waiting for reaping.

--
Kind regards,
Loong Jin

On Tue, Jul 16, 2013 at 09:58:19AM +0800, Chow Loong Jin wrote:
> On Mon, Jul 15, 2013 at 07:05:49PM -0000, John Reid wrote:
> > Killing bash make the PPID 1 and banshee won't start
> >
> > ~/Downloads
> > john@W530$ kill 15673
> > ~/Downloads
> > john@W530$ kill -9 15673
> > ~/Downloads
> > john@W530$ ps -ef|grep banshee
> > john 6435 4624 0 20:04 pts/21 00:00:00 grep --color=auto banshee
> > john 25995 1 3 13:00 ? 00:14:35 [banshee] <defunct>
> > ~/Downloads
> > john@W530$ banshee --debug
> > ** Running Mono with --debug **
> > [1 Debug 20:05:23.875] Bus.Session.RequestName ('org.bansheeproject.Banshee') replied with InQueue
>
> Hmm, very weird.
> http://unix.stackexchange.com/questions/11172/how-can-i-kill-a-defunct-process-whose-parent-is-init
> seems to show a similar case, with no solution.
>
> This is just another stab in the dark, but could you check the output of "ps -p
> 25995 -o stat"? If it says "Z", then it would definitely be a zombie process.
> Also please try "kill -SIGCHLD 1". This shouldn't kill init, but just notify
> init that there's a child process waiting for reaping.

I just noticed something -- it seems to be stuck trying to write to the file in
/mnt/htpc-music. What filesystem is that mount? If it's a network mount, could
the connection have broken somehow? Are you able to access the files in
/mnt/htpc-music from something else (nautilus/mplayer/totem?).

--
Kind regards,
Loong Jin

http://www.noah.org/wiki/Kill_-9_does_not_work mentions zombie processes wedged on NFS, so some of the solutions mentioned there might help.

Thanks for the pointers. I'm pretty convinced it happens when there is a problem with my network mounted filesystem (/etc/fstab):
//192.168.1.74/music /mnt/htpc-music cifs noauto,credentials=/etc/samba/user,noexec,uid=john,gid=john 0 0

The advice in the noah.org article looks good but I'm using CIFS not NFS. Apparently CIFS mounts in a soft fashion by default. I'll have to check my configuration. I might have a look at switching to NFS with the soft option. Thanks a lot for all the help it is really appreciated.

On Tue, Jul 16, 2013 at 06:42:17AM -0000, John Reid wrote:
> Thanks for the pointers. I'm pretty convinced it happens when there is a problem with my network mounted filesystem (/etc/fstab):
> //192.168.1.74/music /mnt/htpc-music cifs noauto,credentials=/etc/samba/user,noexec,uid=john,gid=john 0 0
>
> The advice in the noah.org article looks good but I'm using CIFS not
> NFS. Apparently CIFS mounts in a soft fashion by default. I'll have to
> check my configuration. I might have a look at switching to NFS with the
> soft option. Thanks a lot for all the help it is really appreciated.

No problem. Actually I've had similar issues with rsync and gvfs-fuse before,
but since FUSE mounts have userspace processes, you can kill -9 them to force
the mount to collapse.

Anyway, I think we can consider the issue solved, so I'll just mark this bug as
invalid.

  status invalid

--
Kind regards,
Loong Jin

Is it really solved though? Despite the problem being caused by a cifs/nfs error, banshee's behaviour is still quite bad. A GUI shouldn't really be unresponsive even if there are network problems behind the scenes. BTW I have been running using a NFS mount instead of CIFS mount for a few days now and I've seen similar behaviour.

On Thu, Jul 18, 2013 at 01:33:05PM -0000, John Reid wrote:
> Is it really solved though? Despite the problem being caused by a
> cifs/nfs error, banshee's behaviour is still quite bad. A GUI shouldn't
> really be unresponsive even if there are network problems behind the
> scenes. BTW I have been running using a NFS mount instead of CIFS mount
> for a few days now and I've seen similar behaviour.

Well, that's true. It probably a deadlock of some kind. Create an empty file
~/.config/banshee-1/always-debug, restart Banshee, and and the next time it
hangs, run "killall -SIGQUIT banshee". After that attach ~/.config/banshee-1/log
here.

That being said, even if Banshee didn't deadlock, the situation wouldn't be much
better. Thing is, Banshee plays media files from that mount. If the mount hangs,
then it follows that your playback is going to hang, or in this case, based on
your logs, writing metadata changes back to file (presumably play counts). And
because it's hanging in the middle of a system call, you're also not going to be
able to quit and restart, because at least one thread will be completely stuck
(and unkillable).

--
Kind regards,
Loong Jin

Agreed the situation wouldn't be much better in terms of playing music but I think banshee's behaviour could be. At the moment Ubuntu appears not to work as I try to start banshee and nothing happens (not even an error message). Are there no system calls that can return errors instead of deadlocking when failing to read files from a network mounted filesystem? If not perhaps it is a failing of the system? If there are shouldn't banshee be using them? Perhaps for some technical reason it is not possible to implement them?

I've the created the empty file and I'll attach the log if it happens again.

Here's the log you asked for.

I think better than rebooting might be unmounting the network share. I'll try that next time.

On Fri, Jul 19, 2013 at 10:39:04AM -0000, John Reid wrote:
> Here's the log you asked for.
>
> ** Attachment added: "debug log as asked for"
> https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/1196828/+attachment/3742400/+files/log

Hmm, did you run the "killall -SIGQUIT banshee" command like I mentioned? I
don't see any stacktraces there, and Mono's supposed to dump them all out when
SIGQUIT is received.

--
Kind regards,
Loong Jin

I did run that command. If it happens again I'll make doubly sure.

This happens to me pretty often too. I'm not using any kind of network share. Happened after upgrading to Fedora 19, which I'm assuming means a new version of mono. I suspect it's mono, because after this happens, none of my other mono apps will work.

5247 1 0 Nov04 ? 00:05:53 [banshee] <defunct>

Running on Fedora 19 x64

This happens to me with both banshee *and* rhythmbox. I prefer banshee so it's most annoying for that. The only solution seems to be a reboot. (I also have the <defunct> banshee process and it won't restart). I have a pretty stock ubuntu 14.04 install.

Same problem. Banshee crashes almost after every 3-4 songs and the process says `<defunct>`. Only way to start banshee again is to restart the computer.

I'm going to re-open this issue, as it's not solved, and in my case is not a file system issue - as banshee is stuck in a fuse_write stae, writing to the primary disk that everything else is running on quite happily.

Banshee will restart once I reboot, which is not a viable option. I've tried every variation of every trick listed in this thread and others (and the noah site) and nothing works.