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
