Will Miles
|
Bug report: fcloseall() and stdin, stdout, and stderr
|
Will Miles
03/10/2009 12:33 PM
post24039
|
Bug report: fcloseall() and stdin, stdout, and stderr
Hi,
I'm still poking at the cron sources, tracking down why the log messages wind up in slogger instead of syslog after the
fork() in trigger(). It turns out this is because the close(STDIN_FILENO) actually ends up closing the syslog fd. This
in turn seems to be because the fcloseall() call in main() is closing stdin, stdout, and stderr, even though the
documentation explicitly states that it does not - thus when openlog() runs it gets fd 0. The function source in lib\c\
stdio\fcloseall.c seems to confirm this behaviour: the loop starts at _Files[0] (eg. stdin) instead of _Files[3].
Is this a bug in the library or the documentation?
-Will
|
|
|
Shiv Nagarajan(deleted)
|
Re: Bug report: fcloseall() and stdin, stdout, and stderr
|
Shiv Nagarajan(deleted)
03/10/2009 12:38 PM
post24040
|
Re: Bug report: fcloseall() and stdin, stdout, and stderr
I think thats a bug. the docs do say fcloseall will not close
stdin, stdout, stderr.
let me poke around and determine where the bug is and create an
appropriate PR for this
shiv
Tue Mar 10 12:38:17 EDT 2009
--> According to Will Miles <--
Hi,
I'm still poking at the cron sources, tracking down why the log messages
wind up in slogger instead of syslog after the fork() in trigger(). It
turns out this is because the close(STDIN_FILENO) actually ends up
closing the syslog fd. This in turn seems to be because the fcloseall()
call in main() is closing stdin, stdout, and stderr, even though the
documentation explicitly states that it does not - thus when openlog()
runs it gets fd 0. The function source in lib\c\stdio\fcloseall.c seems
to confirm this behaviour: the loop starts at _Files[0] (eg. stdin)
instead of _Files[3].
Is this a bug in the library or the documentation?
-Will
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post24039
--
****
Shiv Nagarajan,
Kernel Developer, QNX Software Systems,
Ottawa, Canada
****
|
|
|
Colin Burgess(deleted)
|
Re: Bug report: fcloseall() and stdin, stdout, and stderr
|
Colin Burgess(deleted)
03/10/2009 12:52 PM
post24043
|
Re: Bug report: fcloseall() and stdin, stdout, and stderr
It's interesting... fcloseall is listed as being of the "QNX4" classification. And the watcom docs state
the same caveat.
fcloseall() in newlib (from cygwin) on the other hand DOES close all streams
_fcloseall() in MS C doesn't close the standard streams
fcloseall() in linux closes all streams
so there doesn't appear to be a good standard out there.
It should probably match the original watcom libc behaviour, which appears to be that documented.
Shiv Nagarajan wrote:
> I think thats a bug. the docs do say fcloseall will not close
> stdin, stdout, stderr.
>
> let me poke around and determine where the bug is and create an
> appropriate PR for this
>
> shiv
> Tue Mar 10 12:38:17 EDT 2009
> --> According to Will Miles <--
> Hi,
>
> I'm still poking at the cron sources, tracking down why the log messages
> wind up in slogger instead of syslog after the fork() in trigger(). It
> turns out this is because the close(STDIN_FILENO) actually ends up
> closing the syslog fd. This in turn seems to be because the fcloseall()
> call in main() is closing stdin, stdout, and stderr, even though the
> documentation explicitly states that it does not - thus when openlog()
> runs it gets fd 0. The function source in lib\c\stdio\fcloseall.c seems
> to confirm this behaviour: the loop starts at _Files[0] (eg. stdin)
> instead of _Files[3].
>
> Is this a bug in the library or the documentation?
>
> -Will
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post24039
>
>
--
cburgess@qnx.com
|
|
|
Colin Burgess(deleted)
|
Re: Bug report: fcloseall() and stdin, stdout, and stderr
|
Colin Burgess(deleted)
03/10/2009 1:41 PM
post24050
|
Re: Bug report: fcloseall() and stdin, stdout, and stderr
On second thoughts, since there is no defined standard, perhaps we should just go the more common way, and
leave it as it is, fixing the docs.
Of course we should then fix cron... :-)
Shiv Nagarajan wrote:
> I think thats a bug. the docs do say fcloseall will not close
> stdin, stdout, stderr.
>
> let me poke around and determine where the bug is and create an
> appropriate PR for this
>
> shiv
> Tue Mar 10 12:38:17 EDT 2009
> --> According to Will Miles <--
> Hi,
>
> I'm still poking at the cron sources, tracking down why the log messages
> wind up in slogger instead of syslog after the fork() in trigger(). It
> turns out this is because the close(STDIN_FILENO) actually ends up
> closing the syslog fd. This in turn seems to be because the fcloseall()
> call in main() is closing stdin, stdout, and stderr, even though the
> documentation explicitly states that it does not - thus when openlog()
> runs it gets fd 0. The function source in lib\c\stdio\fcloseall.c seems
> to confirm this behaviour: the loop starts at _Files[0] (eg. stdin)
> instead of _Files[3].
>
> Is this a bug in the library or the documentation?
>
> -Will
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post24039
>
>
--
cburgess@qnx.com
|
|
|
Neil Schellenberger(deleted)
|
Re: Bug report: fcloseall() and stdin, stdout, and stderr
|
Neil Schellenberger(deleted)
03/10/2009 2:24 PM
post24058
|
Re: Bug report: fcloseall() and stdin, stdout, and stderr
FWIW, apropos the discussion in our meeting today, it seems the most
flexible to me to stick with the "closes everything except stdin,
stdout, stderr". That would help applications t oavoid the possibility
of loosing the standard fds. The user could still explicitly fclose()
the standard streams if they really, really meant it ;-)
On Tue, 2009-03-10 at 13:41 -0400, Colin Burgess wrote:
> On second thoughts, since there is no defined standard, perhaps we should just go the more common way, and
> leave it as it is, fixing the docs.
>
> Of course we should then fix cron... :-)
>
> Shiv Nagarajan wrote:
> > I think thats a bug. the docs do say fcloseall will not close
> > stdin, stdout, stderr.
> >
> > let me poke around and determine where the bug is and create an
> > appropriate PR for this
> >
> > shiv
> > Tue Mar 10 12:38:17 EDT 2009
> > --> According to Will Miles <--
> > Hi,
> >
> > I'm still poking at the cron sources, tracking down why the log messages
> > wind up in slogger instead of syslog after the fork() in trigger(). It
> > turns out this is because the close(STDIN_FILENO) actually ends up
> > closing the syslog fd. This in turn seems to be because the fcloseall()
> > call in main() is closing stdin, stdout, and stderr, even though the
> > documentation explicitly states that it does not - thus when openlog()
> > runs it gets fd 0. The function source in lib\c\stdio\fcloseall.c seems
> > to confirm this behaviour: the loop starts at _Files[0] (eg. stdin)
> > instead of _Files[3].
> >
> > Is this a bug in the library or the documentation?
> >
> > -Will
> >
> > _______________________________________________
> > OSTech
> > http://community.qnx.com/sf/go/post24039
> >
> >
>
|
|
|
Will Miles
|
Re: Bug report: fcloseall() and stdin, stdout, and stderr
|
Will Miles
03/10/2009 3:21 PM
post24067
|
Re: Bug report: fcloseall() and stdin, stdout, and stderr
Sounds good to me. Thanks for looking in to it! I hope nothing else
gets bitten by the change in behaviour.
As a short term workaround in my local build I've replaced the fcloseall
() with procmgr_daemon() [also eliminating the need to explicitly
background the program when called]. It turns out that even in this
case cron still needs a fix, though a different one: the fd used to
cache stderr while spawning the target job is currently #defined to 4,
which also happens to be the fd handed to openlog(). STDERR2 needs to
be changed to some other number for the output-catching logic to work
correctly. I just used 5, though perhaps a larger value is less
likely to collide with something in the future.
Thanks again,
-Will
On Tue, 10 Mar 2009 14:24:56 -0400 (EDT)
Neil Schellenberger <community-noreply@qnx.com> wrote:
> FWIW, apropos the discussion in our meeting today, it seems the most
> flexible to me to stick with the "closes everything except stdin,
> stdout, stderr". That would help applications t oavoid the possibility
> of loosing the standard fds. The user could still explicitly fclose()
> the standard streams if they really, really meant it ;-)
>
> On Tue, 2009-03-10 at 13:41 -0400, Colin Burgess wrote:
> > On second thoughts, since there is no defined standard, perhaps we should just go the more common way, and
> > leave it as it is, fixing the docs.
> >
> > Of course we should then fix cron... :-)
> >
> > Shiv Nagarajan wrote:
> > > I think thats a bug. the docs do say fcloseall will not close
> > > stdin, stdout, stderr.
> > >
> > > let me poke around and determine where the bug is and create an
> > > appropriate PR for this
> > >
> > > shiv
> > > Tue Mar 10 12:38:17 EDT 2009
> > > --> According to Will Miles <--
> > > Hi,
> > >
> > > I'm still poking at the cron sources, tracking down why the log messages
> > > wind up in slogger instead of syslog after the fork() in trigger(). It
> > > turns out this is because the close(STDIN_FILENO) actually ends up
> > > closing the syslog fd. This in turn seems to be because the fcloseall()
> > > call in main() is closing stdin, stdout, and stderr, even though the
> > > documentation explicitly states that it does not - thus when openlog()
> > > runs it gets fd 0. The function source in lib\c\stdio\fcloseall.c seems
> > > to confirm this behaviour: the loop starts at _Files[0] (eg. stdin)
> > > instead of _Files[3].
> > >
> > > Is this a bug in the library or the documentation?
> > >
> > > -Will
> > >
> > > _______________________________________________
> > > OSTech
> > > http://community.qnx.com/sf/go/post24039
> > >
> > >
> >
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post24058
>
>
--
Will Miles <wmiles@sgl.com>
|
|
|
|