On Wednesday 26 September 2007 10:03:33 Ulrich Drepper wrote:
> On 9/26/07, John Z. Bohach <[EMAIL PROTECTED]> wrote:
> > Is there some reason that syslog() sleeps in __kernel_vsyscall()
> > when invoked from a signal handler?
>
> Only very few functions are allow
Is there some reason that syslog() sleeps in __kernel_vsyscall() when
invoked from a signal handler? Is it that I am not allowed to call any
system calls from inside a signal handler?
I use syslog() from a daemon client/server sys. app. that (tries) to log
whenever a child exits. I've registe
Hello,
I'm writing a system app. that becomes a daemon by the usual fork() ->
setsid() -> fork() method.
It then registers a signal handler for SIGCHLD via sigaction (SA_SIGINFO
style).
chldAction.sa_sigaction = sigChld;
sigemptyset(&(chldAction.sa_mask));
chldAction.sa_flags = SA_
On Saturday 22 September 2007 16:35:56 Andreas Schwab wrote:
> "John Z. Bohach" <[EMAIL PROTECTED]> writes:
> > if (WIFEXITED(siginfo->si_status))
>
> That does not make any sense. si_status is _not_ a wait status.
>
> Andreas.
Thank you for clearing
On Saturday 22 September 2007 11:49:09 Michael Kerrisk wrote:
> John,
>
...snip...
>
> If the child terminated by calling exit(), regardless of whether it
> was done from inside a signal handler, then WIFEXITED() should test
> true, but WIFSIGNALED() will not. If you are seeing otherwise, then
>
Hello,
It is unclear from the various documentions in the kernel and glibc what
the proper behaviour should be for the case when a child process
catches a SIGNAL (say for instance, SIGTERM), and then calls exit()
from within its caught SIGNAL handler.
Since the exit() will cause a SIGCHLD to t
Howdy,
I've tried googling for this, and searched the archives as well, but I
haven't found a satisfactory answer. My apologies if this is covered
somewhere...
The kernel's linux/types.h resolves mode_t to __kernel_mode_t which is
then defined as:
typedef unsigned short __kernel_mode_t;
in
7 matches
Mail list logo
