Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#11670 closed Bug Report - General (Upstream Bug)

leftover startpar with mythtv-backend

Reported by: marillat@… Owned by:
Priority: minor Milestone: unknown
Component: Packaging Version: 0.26-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

A "startpar -f -- mythtv-backend" process hanging around when starting the server.

Apparently this bug is the same than this one http://bugs.debian.org/537182

MythTV from git 0.26 fixes branch updated the 28 June 2013, Debian unstable i386.

Christian

Change History (4)

comment:1 Changed 12 years ago by Raymond Wagner

Component: MythTV - Services API - BackendPackaging
Resolution: Upstream Bug
Status: newclosed
Type: Bug Report - Hang/DeadlockBug Report - General

This sounds like an issue with the Debian init scripts, and not something within our control.

comment:2 Changed 12 years ago by marillat@…

Then could you tell me what is wrong ?

mythtv-backend script is called in the a default scrip used by other package.

If mythtv-backend doesn't support standart option this should be documented.

We use the script provided here :

http://www.mythtv.org/wiki/Debian_init.d_mythbackend

Christian

comment:3 Changed 12 years ago by Raymond Wagner

At the moment, the --daemon command line argument tells the application to close STDIN, and squelch all logging to STDOUT and STDERR. Proper daemonization also requires a "double fork" to orphan the application and cause it to be adopted by init. The common behavior if the init script even bothers to check anything, is for the init script to wait for the STDIN to close, terminate itself, and orphan the application in the process. If I had to guess, startpar is being very strict and waiting on either its child process to terminate, or STDOUT/STDERR to close, before it terminates.

comment:4 Changed 12 years ago by marillat@…

I found a work around. If we add

# X-Interactive:     true

in the LSB header for the init script, then the startpar process is closed properly.

Note: See TracTickets for help on using tickets.