Opened 18 years ago

Closed 18 years ago

Last modified 18 years ago

#514 closed enhancement (wontfix)

mythbackend dies when X server shuts down

Reported by: chrisb@… Owned by: Isaac Richards
Priority: trivial Milestone: unknown
Component: mythtv Version: head
Severity: low Keywords:
Cc: Ticket locked: no

Description

If mythbackend is started up from within an X session (eg. if the server is started from an X terminal window), then when the X server shuts down, mythbackend exits. The logfile contains:

ICE default IO error handler doing an exit(), pid = 20300, errno = 107

If mythbackend is started from outside X, this problem does not occur.

Change History (6)

comment:1 Changed 18 years ago by danielk

Resolution: invalid
Status: newclosed

This is not a bug.

The backend's parent process is the shell you launched it in, so it should be shut down when the shell is.

If you reparent it to the init process, it will shut down when init shuts down.

comment:2 Changed 18 years ago by anonymous

Resolution: invalid
Status: closedreopened

This is a bug.

mythbackend is a daemon. By definition, a daemon should detach from it's controlling terminal and start it's own process group. This is normally done with the daemon(3) call from glibc. One of the things that daemon(3) does is call setsid(2), which causes the mythbackend process to "reparent" to the init process.

Anyway, it's not this that is causing mythbackend to shutdown. If you read the error message I quoted, it is because of ICE (which is part of DCOP) encountering an IO error when the X server shuts down.

Currently, my workaround for this bug is to unset the DISPLAY variable in the init.d script for mythbackend. However, this bug should be fixed properly. I don't think mythbackend should be trying to do anything with the X server. It's not an X client, after all - it's a daemon.

comment:3 Changed 18 years ago by danielk

Milestone: unknown
Priority: majortrivial
Severity: mediumlow
Type: defectenhancement
Version: head

So you ran mythbackend with the "--deamon" option?

comment:4 Changed 18 years ago by anonymous

A sane daemon should not detatch from the controlling terminal, since you lose the control over it, which breaks reliable service supervision, like it's done by daemontools or runit. This also true for service designs in other major operating systems, e.g. for Solaris[0], MacOS X[1] and the like.

Just my 2 cent. :-)

[0] http://www.sun.com/bigadmin/content/selfheal/smf-quickstart.html

[1] http://developer.apple.com/documentation/MacOSX/Conceptual/BPSystemStartup/Articles/LaunchOnDemandDaemons.html#//apple_ref/doc/uid/TP40001762-104738

comment:5 Changed 18 years ago by danielk

Resolution: wontfix
Status: reopenedclosed

It might be nice if someone implemented a more sophisticated deamon mode.

But it works as a deamon when run in a startup script, and it works as non-deamon when run on the terminal, this is good enough that no programmer is chomping at the bit to fix this.

I'm marking this as "wontfix", until a patch is attached.

comment:6 Changed 18 years ago by chrisb@…

Thanks for looking at this guys. One of these days I will have time to work on mythtv myself, and may well manage to fix this one.

However, for anyone else having this problem, I have added a workaround to the mythbackend init script that simply unsets the DISPLAY variable. So mythbackend never bothers to connect to the X server anyway.

Note: See TracTickets for help on using tickets.