Re: [vdr] 1.5.x Shutdown

2007-05-29 Thread Udo Richter

Chris wrote:

If I use an 'empty' shutdown script that just starts with "#!/bin/sh" or
bash or whatever, the script itself becomes a zombie. And if I use a script
with just an empty line, "sh" becomes the zombie. So in either way,
something is wrong and it can not be the script's fault.


I've checked this again, and you really have to care about processes 
even in their own process group. After some research, I think the 
double-fork trick is the best way to fix this: Make the script a 
grandchild of VDR and let the intermediate child do an instant 
wait-friendly exit. This makes the script an orphan that does not get a 
zombie any more.


A patch is attached.


waitpid( -1, &dummy, WNOHANG) called at some place later should do the
trick. Or waitpid() explicitly for the child's PID, if we want to store
the PID anywhere.


If the script may run longer than VDR, then VDR cannot wait for it. 
Thats the problem.


Cheers,

Udo
--- thread.c.bak2007-05-29 21:07:27.0 +0200
+++ thread.c2007-05-29 21:12:56.0 +0200
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -507,7 +508,7 @@
 
   if (pid > 0) { // parent process
  int status = 0;
- if (!Detached && waitpid(pid, &status, 0) < 0) {
+ if (waitpid(pid, &status, 0) < 0) {
 LOG_ERROR;
 return -1;
 }
@@ -515,6 +516,9 @@
  }
   else { // child process
  if (Detached) {
+// Fork again and let first child die
+// Grandchild stays alive without parent
+if (fork() > 0) exit(0);
 // Start a new session
 pid_t sid = setsid();
 if (sid < 0)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] 1.5.x Shutdown

2007-05-28 Thread Clemens Kirchgatterer
Chris <[EMAIL PROTECTED]> wrote:

> My assumption is that the problem occurs because of the missing wait
> call (if SystemExec is called 'detached'). I know, if VDR would wait
> in there, the script wouldn't run simultaneously. But if VDR never
> waits for the child's PID, the child's termination never gets handled
> and imho that's why the script remains as a zombie.
> 
> waitpid( -1, &dummy, WNOHANG) called at some place later should do the
> trick. Or waitpid() explicitly for the child's PID, if we want to
> store the PID anywhere.

i once found this code somewhere and since use this:

int
System(const string &cmd) {
  // The parent process forks and then waits right there for the child
  // to terminate. The child process then forks again, giving us achild
  // and a grandchild. The child exits immediately (and hence the parent
  // waiting for it notices its death and continues to work). Now the
  // grandchild does whatever the child was originally supposed to do.
  // Since its parent died, it is inherited by init, which will do
  // whatever waiting is needed.

  switch (fork()) {
case 0:
  if (!fork()) system(cmd.c_str());
  _exit(0);
break;
  case -1: break;
default: wait(NULL);
  }

  return (0);
}

i didn't look at vdr's SystemExec, but maybe this code snipet comes in
handy.

best regards ...
clemens

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] 1.5.x Shutdown

2007-05-28 Thread Chris
Monday, May 28, 2007, 9:46:12 PM, Udo wrote:
> The shutdown script has always been a fire-and-forget script that did 
> not evaluate any return codes or output. The only change that landed 
> together with the VDR shutdown rewrite in 1.5.1 is that the script is 
> now called detached from VDR, so it can run in parallel and will not 
> terminate together with VDR. Some shutdown scripts may need to be adapted.

> If you want to investigate: thread.c:SystemExec() is called with the new 
> parameter Detached=true. STDIN is redirected to /dev/null, STDOUT and 
> STDERR are same as VDR, all other FD's get closed as before.

You can reproduce the problem pretty easy:

If I use an 'empty' shutdown script that just starts with "#!/bin/sh" or
bash or whatever, the script itself becomes a zombie. And if I use a script
with just an empty line, "sh" becomes the zombie. So in either way,
something is wrong and it can not be the script's fault.

It would be helpful if someone could test this behavior. 

My assumption is that the problem occurs because of the missing wait
call (if SystemExec is called 'detached'). I know, if VDR would wait
in there, the script wouldn't run simultaneously. But if VDR never
waits for the child's PID, the child's termination never gets handled
and imho that's why the script remains as a zombie.

waitpid( -1, &dummy, WNOHANG) called at some place later should do the
trick. Or waitpid() explicitly for the child's PID, if we want to store
the PID anywhere.

--
Chris


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] 1.5.x Shutdown

2007-05-28 Thread Udo Richter
Chris wrote:
> My shutdown script checks for different running processes (or connections)
> and does not quit vdr if at least one of the tests returns true. But since
> 1.5.2 (or probably since 1.5.0) the shutdown script remains as a zombie
> in such cases until vdr actually quits.

The shutdown script has always been a fire-and-forget script that did 
not evaluate any return codes or output. The only change that landed 
together with the VDR shutdown rewrite in 1.5.1 is that the script is 
now called detached from VDR, so it can run in parallel and will not 
terminate together with VDR. Some shutdown scripts may need to be adapted.

If you want to investigate: thread.c:SystemExec() is called with the new 
parameter Detached=true. STDIN is redirected to /dev/null, STDOUT and 
STDERR are same as VDR, all other FD's get closed as before.

Cheers,

Udo


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] 1.5.x Shutdown

2007-05-23 Thread Chris
Hi there,

I recently updated from VDR 1.4.6 to 1.5.2. (with no problems so far, by the
way :)) But today I noticed something which seems to me like a small bug in
vdr's shutdown routines.
My shutdown script checks for different running processes (or connections)
and does not quit vdr if at least one of the tests returns true. But since
1.5.2 (or probably since 1.5.0) the shutdown script remains as a zombie
in such cases until vdr actually quits.

I haven't checked the sources yet, but I guess there's somewhere a call to
close() (or pclose()) for the opened pipe(s) missing.

-- 
Chris


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] 1.5.x ShutDown rewrite

2007-04-01 Thread Udo Richter

ShorTie wrote:
I understand the need for a rewrite of the shutdown sequence for vdr 
when using timers and stuff.


But I was wondering if the good old crtl/c was going to make it’s way 
back in?


The signal handler for SIGINT (aka. Ctrl+C) should work as before. Do 
you have any problems with it?


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] 1.5.x ShutDown rewrite

2007-03-31 Thread ShorTie
I understand the need for a rewrite of the shutdown sequence for vdr when
using timers and stuff.

But I was wondering if the good old crtl/c was going to make it’s way back
in?

 


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.23/740 - Release Date: 3/30/2007
1:15 PM
 
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr