FreeBSD-5.1 problem identified

[edscott wilson garcia]

On mi? 2003-08-06 at 18:39, Mike Makonnen wrote:
> On Wed, Aug 06, 2003 at 01:34:20PM -0500, edscott wilson garcia wrote:
> > This mail is probably spam.  The original message has been attached
> > along with this report, so you can recognize or block similar unwanted
> > mail in future.  See http://spamassassin.org/tag/ for more details.
> > 
> > Content preview:  The problem might also affect other xfce4 elements
> >   besides xffm. I figured out the problem with FreeBSD-5.1 (which *might*
> >   be affecting xfce4-panel, xfce4-session, xfdesktop and xfwm as well).
> >   Apparently the sigaction() function does not work to change the default
> >   action of SIGTERM (and maybe other signals), but the simplified version
> >   signal() works fine. So that by using (in configure.ac): [...] 
> > 
> > Content analysis details:   (5.50 points, 5 required)
> > USER_AGENT_XIMIAN  (-2.4 points) Headers indicate a non-spam MUA (Ximian)
> > 
> > 
> 
> Content-Description: original message before SpamAssassin
> > Date: Wed, 06 Aug 2003 13:34:20 -0500
> > To: "XFce4 development mailing list." <xfce4-dev at xfce.org>
> > From: edscott wilson garcia <edscott at prodigy.net.mx>
> > Subject: FreeBSD-5.1 problem identified
> > Reply-To: edscott at imp.mx,
> >    "XFce4 development mailing list." <xfce4-dev at xfce.org>
> > Errors-To: xfce4-dev-bounces at xfce.org
> > 
> > The problem might also affect other xfce4 elements besides xffm. I
> > figured out the problem with FreeBSD-5.1 (which *might* be affecting
> > xfce4-panel, xfce4-session, xfdesktop and xfwm as well). Apparently the
> > sigaction() function does not work to change the default action of
> > SIGTERM (and maybe other signals), but the simplified version signal()
> > works fine. So that by using (in configure.ac):
> 
> This should not be happening. Xffm works fine on my system
> (5.1-CURRENT). Can you provide me with sample code that
> demonstrates the problem, please? If there is a problem
> it should be fixed in FreeBSD.

OK. The code comes from xffm/libs/tubo.c and occurs after a fork. The
TERM signal is reset for the child which goes into pause until the
parent sends the child the signal to continue. With the sigaction(), the
signal terminates the child and the parent is left waiting. That's why
it gets no answer on nmblookup, nor doing a find, nor trying to
mount/unmount nor other things, otherwise xffm seems to work ok. It can
browse and launch programs and stuff like that since no signals are
involved to do that.

if I undefine HAVE_SIGNAL it won't work:

void *Tubo(void)
{
    int i;
    fork_struct tmpfork, *newfork = NULL;

#ifndef HAVE_SIGNAL
    struct sigaction act;
    sigemptyset(&act.sa_mask);
#ifdef SA_RESTART
    act.sa_flags = SA_RESTART;
#else
    act.sa_flags = 0;
#endif
    act.sa_handler = TuboSemaforo;
#endif

[some code here]

#ifdef HAVE_SIGNAL
    signal(SIGUSR1, TuboSemaforo);
#else
    sigaction(SIGUSR1,&act,NULL);
#endif


    tmpfork.childPID = fork();
    if(tmpfork.childPID)
    {				/* the parent */
	newfork = (fork_struct *) malloc(sizeof(fork_struct));
	if(!newfork)
	{
	    /* red light to child */
	    perror("malloc");
#ifdef DEBUG
 printf("The parent process is sending a red light\n"); 
#endif
	    kill(tmpfork.childPID, SIGTERM);
	    TuboChupoFaros(NULL);
	    return NULL;
	}
#ifdef DEBUG
 printf("The parent process is sending a green light\n"); 
#endif
	kill(newfork->childPID, SIGUSR1);
	return newfork;		/* back to user's program flow */
    }
    else
    {				/* the child */
	/* waitfor green light. */
#ifdef HAVE_SIGNAL
	signal(SIGTERM, TuboSemaforo);
#else
	sigaction(SIGTERM,&act,NULL);
#endif
	
#ifdef DEBUG
 printf("The child process is waiting for the green light\n"); 
#endif
	pause();
#ifdef DEBUG
 printf("The child has received the green light\n"); 
#endif


Looking over the code, it seems that if I use sigaction, the child
receives the signal USR1 and terminates (default for USR1). But if I use
signal() it calls the handler and merrily goes on its way. Maybe there
is a race condition in FreeBSD and that is why it fails on my box but
works on yours. OTH, shouldn't signal be preferred (if available) since
it is simple and straightforward?


regards,

Edscott

ps. I'm sorry my mail looks like spam, but with this new ISP, if I use
"sendmail" to send mail, it gets bounced by xfce.org and a bunch of
other boxes so I have no choice but to use SMTP and forward my mail
through prodigy.net.mx. And for that I have to use different "from" and
"reply-to" addresses.


> 
> Cheers.