* Stephen Hahn <sch at sun.com> [2009-01-22 01:00]: > * Stephen Hahn <sch at sun.com> [2009-01-22 00:54]: > > * 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()... > > Apparently, even that's not enough because stdio doesn't distinguish > enough between "w" and "a" in the flush path. What a mess.
logadm -c is sufficient for the stdio case as well, as long as the file is opened O_APPEND. (I missed a '!' in the first if() in flush.c:_fflush_u(). I suppose I should make a sign error joke.) Moreover, I made a chatty service last night with logadm -c executed every five minutes on a shorter length, and saw correct behaviour. The only issue to note is that, since stdout is buffered, lines may be split during the log rotation. This inconvenience seems justified by the fact that filesystem usage of /var/svc/log will be capped. The svc.startd.log openat() in log.c:log_init() should have O_APPEND added. - Stephen * The behaviour Renaud saw is for a case where the file descriptor lacks O_APPEND. -- sch at sun.com http://blogs.sun.com/sch/
