Re: signal vs. sigaction and SIGCHLD
Doesn't wait call suspend the calling process until the child is terminated? >From man page for wait: The wait() function suspends execution of its calling process until status information is available for a terminated child process But in your case the child process is not terminated. If you use the same pid = waitpid(-1, &tstat, WUNTRACED); in case of signal you'll get the same result as with sigaction, or that's what I suspect to happen, haven't had a chance test it. Vilda 2013/5/21 Polytropon > > On Tue, 21 May 2013 15:24:26 +1000, Noel Hunt wrote: > > If I recompile with `#undef SIGACTION', waithandler is not > > called. > > > > I should add that even with the sigaction(2) interface, without > > the `sigprocmask' call, it still doesn't work, which suggests > > that SIGCHLD is being blocked. > > > > Can anyone explain why? > > From reading "man 3 signal", I get the following impression: > > NoName Default Action Description > 20SIGCHLD discard signal child status has changed > > The default action is to discard the signal, so the following > paragraph could make sense: > > The sig argument specifies which signal was received. The func procedure > allows a user to choose the action upon receipt of a signal. To set the > default action of the signal to occur as listed above, func should be > SIG_DFL. A SIG_DFL resets the default action. To ignore the signal func > should be SIG_IGN. This will cause subsequent instances of the signal to > be ignored and pending instances to be discarded. If SIG_IGN is not > used, further occurrences of the signal are automatically blocked and > func is called. > > From my limited understanding, maybe this could help you find > an explanation of the observed behaviour? > > Also compare /usr/include/sys/signal.h for the definition of > the involved typedef's. > > > -- > Polytropon > Magdeburg, Germany > Happy FreeBSD user since 4.0 > Andra moi ennepe, Mousa, ... > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: signal vs. sigaction and SIGCHLD
On Tue, 21 May 2013 15:24:26 +1000, Noel Hunt wrote: > If I recompile with `#undef SIGACTION', waithandler is not > called. > > I should add that even with the sigaction(2) interface, without > the `sigprocmask' call, it still doesn't work, which suggests > that SIGCHLD is being blocked. > > Can anyone explain why? >From reading "man 3 signal", I get the following impression: NoName Default Action Description 20SIGCHLD discard signal child status has changed The default action is to discard the signal, so the following paragraph could make sense: The sig argument specifies which signal was received. The func procedure allows a user to choose the action upon receipt of a signal. To set the default action of the signal to occur as listed above, func should be SIG_DFL. A SIG_DFL resets the default action. To ignore the signal func should be SIG_IGN. This will cause subsequent instances of the signal to be ignored and pending instances to be discarded. If SIG_IGN is not used, further occurrences of the signal are automatically blocked and func is called. >From my limited understanding, maybe this could help you find an explanation of the observed behaviour? Also compare /usr/include/sys/signal.h for the definition of the involved typedef's. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
signal vs. sigaction and SIGCHLD
I have a small test program which simply forks and execs
its command line arguments, but after the fork and before
the exec, it sends a SIGSTOP to the child. The parent then
sleeps for 3 seconds before exiting. However, a signal
handler for SIGCHLD has been installed and I was expecting
the parent to be notified of the SIGSTOP sent to the child,
but with the `signal' interface this doesn't appear to work.
If I change the code to use `sigaction' and `sigprocmask'
(to unblock any blocked SIGCHLD), this program works the
way intended, that is, the signal handler is called:
1 #include
2 #include
3 #include
4 #include
5 #include
6 #include
7 #include
8 #include
9
10 #define SIGACTION
11
12 static void waithandler(int i){
13 int pid, cursig;
14 int tstat;
15
16 #ifdef SIGACTION
17 pid = waitpid(-1, &tstat, WUNTRACED);
18 #else
19 pid = wait(&tstat);
20 signal(SIGCHLD, waithandler);
21 #endif
22 if (pid < 0)
23 return;
24
25 printf("waithandler: child (%d)", pid);
26 if (WIFSTOPPED(tstat)) {
27 printf(" received");
28 cursig = WSTOPSIG(tstat);
29 if (cursig == SIGSTOP)
30 printf(" SIGSTOP\n");
31 else if (cursig == SIGTRAP)
32 printf(" SIGTRAP\n");
33 else
34 printf(" %d\n", cursig);
35 } else {
36 printf(" exited status=%d\n", WEXITSTATUS(tstat));
37 }
38 }
39
40 main(int argc, char **argv){
41 int i, j;
42 int fd, hangpid;
43 FILE *ttyerr;
44 char ctl[16];
45 #ifdef SIGACTION
46 sigset_t sigmask[2];
47 struct sigaction sa;
48
49 sa.sa_flags = 0;
50 sigemptyset(&sa.sa_mask);
51 sa.sa_handler = waithandler;
52 sigaction(SIGCHLD, &sa, NULL);
53 sigemptyset(&sigmask[0]);
54 sigaddset(&sigmask[0], SIGCHLD);
55 sigprocmask(SIG_UNBLOCK, &sigmask[0], &sigmask[1]);
56 #else
57
58 signal(SIGCHLD, waithandler);
59 #endif
60 ttyerr = fopen("/dev/tty", "w");
61 if (argc <= 1) {
62 if( ttyerr )
63 fprintf(ttyerr,"Usage: %s cmd [args...]\n",argv[0],*argv);
64 exit(1);
65 }
66 if( (hangpid=fork())==0 ){
67 kill(getpid(), SIGSTOP);
68 execvp(argv[1], argv+1);
69 perror(argv[1]);
70 exit(1);
71 }
72 if(hangpid==-1){
73 perror("fork");
74 exit(1);
75 }
76 if( ttyerr ){
77 fprintf(ttyerr,"/proc/%d\n",hangpid);
78 fclose(ttyerr);
79 }
80 sleep(3);
81 }
The file is `hang.c'. I compile and run it like this:
% ./hang echo foo bar baz
waithandler: child (2280) received SIGSTOP
/proc/2280
If I recompile with `#undef SIGACTION', waithandler is not
called.
I should add that even with the sigaction(2) interface, without
the `sigprocmask' call, it still doesn't work, which suggests
that SIGCHLD is being blocked.
Can anyone explain why?
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Upgrading emacs; Glib-warning, SIGCHLD, SIG_IGN and ECHILD
Greetings FYI: On or about August 1 I upgraded emacs to V. 24.x and when running it, I found this error in a terminal: GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request the exit status, or don't set the SIGCHLD action. Then my X session would hang, and I needed to pkill emacs to regain my X session's mouse and keyboard. I found that a make config which sets GTK3 and unsets GTK2 seems to be the fix. Best regards, Joe ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: SIGCHLD and sockets HELP!
Keith Bottner wrote: I am having a problem with SIGCHLD signals and their interaction with sockets. I have an application that forks modules in separate processes and use UNIX domain sockets for communication. The main application handles the SIGCHLD signal so that it can detect when/if a module crashes and if so restart that specific module. The problem arises when the module crashes and before the main application is notified with the SIGCHLD signal the socket will continue to allow writes. I expected that there would be occasions when the SIGCHLD signal would occur after my attempt to write into the socket, but I also expected the socket to return an error at which point I could then mark the module for restart as well. My question is, has anybody else had this problem? Does anybody know exactly what is going on an why? And most importantly, does anybody have a solution? Thanks in advance for your time, it is quite an interesting problem so I am hoping to get some insightful answers. No-one is chiming in so maybe it would help if you posted a code fragment that shows the write to the socket which you expect to fail, but which doesn't seem to. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SIGCHLD and sockets HELP!
I am having a problem with SIGCHLD signals and their interaction with sockets. I have an application that forks modules in separate processes and use UNIX domain sockets for communication. The main application handles the SIGCHLD signal so that it can detect when/if a module crashes and if so restart that specific module. The problem arises when the module crashes and before the main application is notified with the SIGCHLD signal the socket will continue to allow writes. I expected that there would be occasions when the SIGCHLD signal would occur after my attempt to write into the socket, but I also expected the socket to return an error at which point I could then mark the module for restart as well. My question is, has anybody else had this problem? Does anybody know exactly what is going on an why? And most importantly, does anybody have a solution? Thanks in advance for your time, it is quite an interesting problem so I am hoping to get some insightful answers. Keith ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SIGCHLD and sockets
I am having a problem with SIGCHLD signals and their interaction with sockets. I have an application that forks modules in separate processes and use UNIX domain sockets for communication. The main application handles the SIGCHLD signal so that it can detect when/if a module crashes and if so restart that specific module. The problem arises when the module crashes and before the main application is notified with the SIGCHLD signal the socket will continue to allow writes. I expected that there would be occasions when the SIGCHLD signal would occur after my attempt to write into the socket, but I also expected the socket to return an error at which point I could then mark the module for restart as well. My question is, has anybody else had this problem? Does anybody know exactly what is going on an why? And most importantly, does anybody have a solution? Thanks in advance for your time, it is quite an interesting problem so I am hoping to get some insightful answers. Keith ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SIGCHLD
On Mon, Feb 10, 2003 at 07:52:06PM +0100, Alexander wrote: > I'm having a problem when running a program that forks a child. > The program handles SIGCHLD with its own function that calls waitpid(). > So the program thinks that when SIGCHLD is raised then the child is terminated. > But the parent gets SIGCHLD even if the child is still running and then > the following happens - The child is doing its job but the parent > calls the SIGCHLD handler and gets into waitpid() (although it shouldn't !) > > SIGNAL(3) manual page says: > NameDefault Action Description > > SIGCHLD discard signal child status has changed > > Does this mean that SIGCHLD is not only raised when the process is terminated ? Yes. Look at the wait(2) man page: the parent process can receive a SIGCHLD when the child process is stopped, by eg. a SIGSTOP signal. However, you only get that if you set the WUNTRACED option in the waitpid() call. It's also possible for your parent process to receive SIGCHLD signals for any descendant process in the same process group, depending on the value of the wpid parameter. Unless you've called setsid(2) or used the double fork(2) trick, your child process, and any grandchild process it spawns will all belong to the same process group as your original program. It's exceedingly unlikely that such a fundamental part of process control could be buggy without leaving an enormous trail all over the mailing lists. However, it was the case that perl(1) used to have problems with SIGCHLD propagation on FreeBSD: http:[EMAIL PROTECTED]/msg89611.html > And does it mean, "always ignore SIGCHLD and never trust it" ? The sigaction(2) man page explains how you control the behaviour of a program in response to signals. > And what does this mean "child status has changed" ? When is it changed ? Uh --- the signal should be delivered pretty much instantaneously with the child process changing status. 'Changing status' means that the child process has called exit(3) or _exit(2) or received a signal such as SIGINT or SIGKILL which will cause the child process to exit. It can also mean that the child received a SIGSTOP or SIGTSTP or SIGCONT or similar which has caused it to temporarily stop or restart execution. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
SIGCHLD
Hello
I'm having a problem when running a program that forks a child.
The program handles SIGCHLD with its own function that calls waitpid().
So the program thinks that when SIGCHLD is raised then the child is terminated.
But the parent gets SIGCHLD even if the child is still running and then
the following happens - The child is doing its job but the parent
calls the SIGCHLD handler and gets into waitpid() (although it shouldn't !)
SIGNAL(3) manual page says:
NameDefault Action Description
SIGCHLD discard signal child status has changed
Does this mean that SIGCHLD is not only raised when the process is terminated ?
And does it mean, "always ignore SIGCHLD and never trust it" ?
And what does this mean "child status has changed" ? When is it changed ?
thanks
P.S. Please include my mail when replying.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message
