-------- Original Message --------
Subject: Re: Re-8: rt_printf with daemonized task (07-Okt-2009 17:38)
From: Jan Kiszka <[email protected]>
To: [email protected]
> [email protected] wrote:
> >
> >
> > As you expected, changing the syslog call from
> > syslog( LOG_ERR | LOG_LOCAL4, head->text );
> > to
> > syslog( LOG_ERR | LOG_LOCAL4, "%s", head->text );
> >
> > did not change anything.
> >
> > To track down the problem further, I have made a small test application :
> >
> > #include <stdlib.h>
> > #include <stdio.h>
> >
> > #include <native/task.h>
> > #include <native/timer.h>
> > #include <rtdk.h>
> >
> >
> > int main( int arc, char *argv[] )
> > {
> > int i;
> >
> > rt_print_auto_init(1);
> >
> > rt_printf("--------------- TEST RT-PRINTF 1 ------------\n");
> >
> > sleep(1);
> >
> > daemon(0,0);
> >
> > rt_print_auto_init(1);
> >
> > rt_printf("--------------- TEST RT-PRINTF 2 ------------\n");
> >
> > sleep(10);
> >
> > return(0);
> > }
> >
> >
> >
> > This application gives the following results :
> > - If the daemon() function is not called, all rt_printf() do work well
> > and output is shown in syslog
> > - If daemon() function is called, and first call to sleep(1) is omitted,
> > there is no output in the syslog whatsoever.
> > - If daemon() function is called, and first call to sleep(1) is executed,
> > there is output of the first rt_printf in the syslog but not of the
> > second
> > one.
> >
> > I do not have any idea why daemonizing of the process is not giving
> > any output to the syslog.
>
> As you are already looking at rt_printf.c: __rt_print_init spawns a
> pthread that polls the internal queues and issues the output to stdout
> or whatever. On fork (or daemonize), this thread is not replicated. So
> the child process simply has no printing thread.
Ok, understood, at least for the scenario where the rt_print feature is
initialised
befor the fork/daemon call.
What I don't understand is, why it does not work if the rt_print feature is
initialised after the fork / daemon.
>
> I think this should be fixable with a pthread_atfork hook, patches
> always welcome.
I would like to follow up this track. I have to have a look at pthread_atfork
first,
because I'm not so familiar with the pthread functions.
Therefor any hint what should be done with pthread_atfork is very welcome.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux
Oliver
To: [email protected]
Cc: [email protected]
[email protected]
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
