[vdr] Re: Problems with exit-states (now VDR-1.2.4)

[Steffen Barszus <st_barszus@gmx.de>]

Am Mittwoch, 3. September 2003 10:53 schrieb Sergei Haller:
> On Wed, 3 Sep 2003, Steffen Barszus (SB) wrote:
>
> SB>
> SB> [root@localhost init.d]# su -c "vdr -t /dev/tty11 ; echo $?" root
> SB> passed line 324
> SB> passed line 326
> SB> 0    <== Exitcode  with _"_
> SB>
> SB> [root@localhost init.d]# su -c 'vdr -t /dev/tty11; echo $?' root
> SB> passed line 324
> SB> passed line 326
> SB> 2   <== Exitcode with _'_
> SB>
>
>
> the thing is that in the first case $? is replaced by the shell with
> the return status of the previous (!!!) command, which is not in your
> email.

Uff. I thought vdr would be the last command ... 

> in the second case, $? is passed to su as it is. and is replaced by
> the shell, which is run by su.

Ok

> as you can see here:
>
> # echo $UID
> 500
> # su -c "echo $UID"
> Password:
> 500
> # su -c 'echo $UID'
> Password:
> 0
>
> in the second and the third cases, the echo Program is run by the
> user root. but in second case,
>   echo 500
> is run by root, where in the third case
>   echo $UID
> is run by root.

Ok. 

> Thus,  I  would _STRONGLY_ suggest to look for exit codes of VDR
> _WITHOUT_ using  su  or  sudo or things like that. Once this works
> (or if this works already),  you  can start using programs like su or
> sudo and see that they pass correct return values to outside:



> # su -c '(exit 14)'
> Password:
> # echo $?
> 142
>
> # sudo bash -c '(exit 14)'
> Password:
> # echo $?
> 14
>
> here 142 is the return value of su, which is NOT the return value of
> the subsequent shell.
>
> where 14 as the return value of sudo is exactly the return value of
> the command ran by sudo.

Ok try to wrap my head around that later. Feel like a linux noob ;). But 
that is now another thread.  

> Hope that helps a bit to track the real problem.
>

That was indeed helpfull. I have taken your advice and made a su vdr 
(the vdr user, to not let run vdr as root, as vdr has a network socket 
and could be attacked) 

bash-2.05b$ vdr -t /dev/tty12
passed line 324
passed line 326
Segmentation fault
bash-2.05b$ echo $?
139

So vdr segfaults and 139 seems to be the standard exitcode for that. 

With the third freopen commented out:

     stdin  = freopen(Terminal, "r", stdin);
     fprintf(stderr, "passed line %d\n", __LINE__);
     stdout = freopen(Terminal, "w", stdout);
     fprintf(stderr, "passed line %d\n", __LINE__);
     //stderr = freopen(Terminal, "w", stderr);
     fprintf(stderr, "passed line %d\n", __LINE__);

It doesn't segfault anymore. I had the feeling yesterday night that i 
had mixed two problems :) Thanks for your help. It doesn seem to be a 
problem with exitcodes, its just that vdr segfaults with -t /dev/ttyx 
as user != root . This is because the user does not have write access 
to the console :( and this does not got catched by vdr. Since there is 
nothing to write on stdout , vdr doesn't segfault there, but vdr has 
something to write to stderr (the error i made in my config to test the 
exit states). Thus it segfaults on that place. Good that i had some 
sleep and your explanation. I guess this makes things for Klaus now a 
lot easier ;) then the testing w/o a target i made before. With knowing 
the problem i can handle the other problems 

Steffen


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.