On Monday 03 November 2014 16:26:43 Debra S Baddorf did opine And Gene did reply: > On Nov 3, 2014, at 3:00 PM, Gene Heskett <[email protected]> wrote: > > On Monday 03 November 2014 15:30:37 Debra S Baddorf did opine > > > > And Gene did reply: > >> I had a job that sent it’s “I’m Finished” email with a timestamp > >> of 0208, but it was probably only doing tape work between 02:00 > >> and the new 02:00. Yeah, the last dumper activity seems to have > >> finished at 01:26 — the first 01:26 — so only same-node taper > >> work was going on. > >> Looks like I got lucky: > >> > >> Lets see: > >> taper.20141101080003.debug shows the time jumping back suddenly > >> but nobody seems to care: > >> > >> Sun Nov 2 01:54:14 2014: thd-0x8b96ff0: taper: > >> Amanda::Taper::Scribe preparing to write, part size 0, using no > >> cache (PEOM will be fatal) (splitter) (no LEOM) Sun Nov 2 > >> 01:54:14 2014: thd-0x8b96ff0: taper: Starting <Xfer@0x96d08c8 > >> (<XferSourceHolding@0x9345938> -> > >> <XferDestTaperSplitter@0x93451e0>)> Sun Nov 2 01:54:14 2014: > >> thd-0x8b96ff0: taper: Final linkage: <XferSourceHolding@0x9345938> > >> -(PULL_BUFFER)-> <XferElementGlue@0x934d150> -(PUSH_BUFFER)-> > >> <XferDestTaperSplitter@0x93451e0> Sun Nov 2 01:54:14 2014: > >> thd-0x9827c80: taper: Building type SPLIT_FILE header of 32768-32768 > >> bytes with name='clxsrv.fnal.gov' disk='/export/userb' dumplevel=0 > >> and blocksize=32768 Sun Nov 2 01:00:09 2014: thd-0x8b96ff0: taper: > >> Amanda::Taper::Scribe preparing to write, part size 0, using no > >> cache (PEOM will be fatal) (splitter) (no LEOM) Sun Nov 2 > >> 01:00:09 2014: thd-0x8b96ff0: taper: Starting <Xfer@0x996c990 > >> (<XferSourceHolding@0x93458c8> -> > >> <XferDestTaperSplitter@0x9345108>)> Sun Nov 2 01:00:09 2014: > >> thd-0x8b96ff0: taper: Final linkage: <XferSourceHolding@0x93458c8> > >> -(PULL_BUFFER)-> > >> <XferElementGlue@0x934d0a8> -(PUSH_BUFFER)-> > >> <XferDestTaperSplitter@0x9345108> Sun Nov 2 01:00:09 2014: > >> thd-0x99d8da8: taper: Building type SPLIT_FILE header of 32768-32768 > >> bytes with name='daesrv.fnal.gov' disk='/export/engines' dumplevel=0 > >> and blocksize=32768 Sun Nov 2 01:04:30 2014: thd-0x8b96ff0: taper: > >> Amanda::Taper::Scribe preparing to write, part size 0, using no > >> cache (PEOM will be fatal) (splitter) (no LEOM) > >> > >> > >> > >> dumper.20141101080002007.debug seems to be temporarily not busy, > >> but did get a QUIT command at 2:07 (if I got the AMREPORT at 02:08, > >> this is when every piece was wrapping up and being told to QUIT) It > >> looks like he was done transferring data at the first 01:26, > >> remained totally ignorant of the next hour having repeated > >> timestamps, cuz he wasn’t doing anything, and then wrote down > >> 02:07 for the QUIT after the time had changed There was no > >> wrapping of the timestamps, so I think there is a whole 90 minutes > >> actually between that 01:26 entry and the 02:07 one. > >> > >> Sun Nov 2 01:26:18 2014: thd-0x8736368: dumper: > >> stream_read_callback: data is still flowing Sun Nov 2 01:26:29 > >> 2014: thd-0x8736368: dumper: stream_read_callback: data is still > >> flowing Sun Nov 2 01:26:39 2014: thd-0x8736368: dumper: > >> security_stream_seterr(0x87f50d0, EOF) Sun Nov 2 01:26:39 2014: > >> thd-0x8736368: dumper: > >> security_stream_close(0x87f50d0) Sun Nov 2 01:26:39 2014: > >> thd-0x8736368: dumper: security_stream_seterr(0x87e5060, EOF) Sun > >> Nov 2 01:26:39 2014: thd-0x8736368: dumper: > >> security_stream_close(0x87e5060) Sun Nov 2 01:26:39 2014: > >> thd-0x8736368: dumper: security_stream_seterr(0x87ed098, EOF) Sun > >> Nov 2 01:26:39 2014: thd-0x8736368: dumper: > >> security_stream_close(0x87ed098) Sun Nov 2 01:26:39 2014: > >> thd-0x8736368: dumper: Building type FILE header of 32768-32768 > >> bytes with name='clxsrv.fnal.gov' disk='/mecca_head' dumplevel=0 > >> and blocksize=32768 Sun Nov 2 01:26:39 2014: thd-0x8736368: > >> dumper: putresult: 3 DONE Sun Nov 2 02:07:28 2014: thd-0x8736368: > >> dumper: getcmd: QUIT "" Sun Nov 2 02:07:28 2014: thd-0x8736368: > >> dumper: pid 3135 finish time Sun Nov 2 02:07:28 2014 > > > > Thanks Debra and Steve. > > > > I guess I'll have to chalk it up to snilmerg or Murphy. But with my > > ancient wet ram I will likely have forgotten it by the next scheduled > > change, the 80 year accumulation of wear & tear on my wet ram is > > showing I fear. > > > > [...] > > > > Cheers, Gene Heskett > > Put a sticky note on December, with the note bearing a date of <next > DST time change> so that you will move that sticky note to next years > calendar as soon as you get one! > > Wet wear work-around. > Deb
ROTFLMAO! Love it. ;-) Heck, it might even work. But being long time retired, I walk by the calendar for weeks at a time without paying any attention to it, occasionally making a note on the paper nes of how much I dumped from the rain gauge. We also have one of those wooden block things that the missus keeps up to date. But its frame has such a coat of cig smoke on it a sticky falls off in about a week. The important part of _this_ date is that I woke up this morning & that makes it a good day. :) Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
