* Stephen Hahn <sch at sun.com> [2009-01-21 23:58]: > * Stephen Hahn <sch at sun.com> [2009-01-21 23:28]: > > * David Powell <David.Powell at sun.com> [2009-01-21 22:47]: > > > Casper.Dik at sun.com wrote: > > >>> * Nicolas Williams <Nicolas.Williams at sun.com> [2009-01-21 00:14]: > > >>>> Perhaps we need a new system call, or proc(4) extension, or perhaps we > > >>>> could use proc(4) as is, via the agent LWP (to open the new logfile in > > >>>> each victim process and dup2() it into place as fildes 1 and 2). > > >>> There's an old /proc-based tool in someone's home directory that does > > >>> this; I've asked that someone to see if we can examine the source. > > >> > > >> > > >> Argh. (We really should not create tools which change attributes > > >> through > > >> the agent LWP; and those we have should be scrapped) > > > > > > Agreed. > > > > > > More generally, the agent LWP is a debugging tool. It shouldn't play > > > a role in our administrative infrastructure. > > > > Both of you must have sent your messages prematurely, as neither > > contains a suggestion for solving the actual problem. > > Ignore me. I'm bothered about other things. Apologies to you and to > Casper. > > (In the meantime, using the left side of my brain, I've looked at the > write(2) implementation for tmpfs, ufs, and zfs, and for fprintf(3C), > and don't see why logadm -c doesn't work--O_APPEND is correctly > handled (or not overridden) throughout. A test program seems due.)
For the non-stdio case, logadm -c is sufficient. It appears that stdio doesn't respect the O_APPEND on stdout or stderr during initialization (see lib/libc/port/stdio/data.c), nor does fdopen(3C) allow one to divine the presence of O_APPEND on an existing file descriptor. I suppose we could fix the first case--standards permitting--by doing 2 stat(2) calls in libc_init()... - Stephen -- sch at sun.com http://blogs.sun.com/sch/
