Like everything else, occasionally the automation process fails and you will need to try and salvage a run by hand (not killing the finalize node if at all possible!). If you kill the finalize node you will have to resubmit the runs as this would otherwise interfere with the rolling calibrations that are written out.
The first place that a finalize node can be seen is in the lm.log file when it is allocated and later when it is retrieved:
OPR:logFiles/PC-00050644-1-04-08-01.12:30:50/> grep Finalize lm.log
2004-08-01_12:36:09.122158 Sending Finalize to tori0005.slac.stanford.edu
2004-08-01_12:38:21.787326 Remove Finalize from tori0005.slac.stanford.edu
The finalize node for a particular run can also be identified by and entry named in its d-machine.log file:
d-barb0047-19376.log:OprDEventGetter: Event of type finalize 274575400
where of course this node/job will change from run to run. There are also several entries in that node/job's corresponding f-machine file:
f-barb0047-19506.log::(00:19:53) -- OprFTestModule:finalize(2001Sep17-00:19:52.216636000)
f-barb0047-19506.log:00:19:53.404 OprBuildEnv finalize
f-barb0047-19506.log:OprBuildEnv finalize Run Number: 0
f-barb0047-19506.log:00:22:52.205 OprBuildEnv finalize finished
f-barb0047-19506.log:::DchOprAlign.cc(679):finalize, requesting 1000 tracks
f-barb0047-19506.log::BeamOprCalib: finalize, requesting 1000 tracks
f-barb0047-19506.log::PocOprBoostModule: finalize. Requesting 500 events.
If a run has failed to finalize you may see 'abort()' being called in the finalize node's f-machine file or you could even get a crash as seen by the debugger. Such things can happen if you have an incorrent LD_LIBRARY_PATH entry for the objy tools stuff.