shutting down the service by deleting foldtrajlite.lock

[FoBoT]

if i delete the foldtrajlite.lock file when the DF service is running on WinXP/W2K , it shuts the service down

my questions are:

1- is this an "ok" way to shut it down? if not, what is the bettter way (from a .bat file)

2- does the current structure complete its run to 129 (or whatever the # is for a particular protein) before the service ends or does it just stop in mid-crunch?

the reason this matters is, i am deleting the .lock file to stop the service, then having the .bat file sleep for 7 seconds before copying the .log.bz2 and .val.bz2 files . i originally tried 3 seconds, then 4 seconds and sometimes my copy occured before the last .bz2 file was created (and the filelist.txt was updated), so i ended up with an orphan .bz2 file (no matching pair) and losing work

i think i just need to pick a long enough sleep time so that most of the time (~90%) the service shuts down and writes the files before i start copying them

thanks

[Paratima]

FoBoT: I believe that from a .bat file, removing the .lock file is the ONLY way to kill the client without losing data. I don't think it will close correctly with a signal (not even sure it listens for signals).

However, this has worked for me 100%. Loop on existence of the progress.txt file. When the client stops, progress.txt disappears.

PS. I think that's how dfGUI knows when the client has stopped.

PPS. Make sure that the client is running first, or you could wait a VERY long time!

[FoBoT]

ah...

so instead of guessing how long to wait with a sleep X seconds
check to see when the progress.txt file goes away

ok, thanks i will switch methodology

[Gunslinger]

Originally posted by Paratima

PPS. Make sure that the client is running first, or you could wait a VERY long time!

How do you do that in a batch file?

(If I can get this to work 100% reliably I can bring a few more workstations onto DF part-time)

[FoBoT]

this is what i am trying now

if exist c:\images\rptoutbx\filelist.txt goto END
mkdir c:\images\rptoutbx
if exist not c:\winnt\temp\mldf\foldtrajlite.lock goto END
del c:\winnt\temp\mldf\foldtrajlite.lock
:STEP1
c:\winnt\temp\mldf\sleep.exe 2
if exist c:\winnt\temp\mldf\progress.txt goto STEP1
move c:\winnt\temp\mldf\filelist.txt c:\images\rptoutbx
move c:\winnt\temp\mldf\*.log.bz2 c:\images\rptoutbx
move c:\winnt\temp\mldf\*.val.bz2 c:\images\rptoutbx
move c:\winnt\temp\mldf\*.log c:\images\rptoutbx

:END

line by line
1.checks to see if this box has an outstanding batch in the destination location
2. create the destination directory where the structures will end up
3.see if foldtrajlite.lock exists, if so, then DF service is running(probably? right?)
4.delete the .lock file to stop the service
5.wait 2 seconds (just to let things settle out)
6.if the progress.txt file hasn't been removed by the service shutting down yet, then loop back up and wait until its gone
7-9.copy the filelist.txt and .log.bz2 and .val.bz2 files to my outgoing directory
10.copy .log files on the pc to my outgoing directory (the REAL reason i am doing all this, to gather log files to check thier status )

i tried it on my test boxen, now to deploy it/field test it

[FoBoT]

crap, i just thought of a flaw with this

if the service is off and supposed to be off, then my collection never happens (line 3)

crap

[bwkaz]

If the problem is that the boxes without the service running will never get harvested, even if they have stored data, then you could check for .log.bz2 files as well.

Do something like check for a lock file first, and stop the client if there is one. But don't just end if there isn't -- check for .log.bz2 files (or a filelist.txt, or something) if the client isn't running.

From my understanding of the current problem, this should help...

[Paratima]

Sorry to leave you in the lurch, but I'm fighting a miserable head cold (2nd day) which kept me away from the office, which is where the code is.

From what I remember, you've got most of it there.

As for the loop... If the client isn't supposed to be running, what's to harvest? The problem is that the .lock file probably WILL be there if the client crashes. In that case, you will spin forever waiting for progress.txt to go away. So you must use a counter to break out of that loop. I think I gave it 20 seconds max (I have some s...l...o...w machines on my pharm).

I like bwkaz's solution, which I think is close to what I have. I just look for filelist.txt.

When I get to the office, I'll check on it.

[Brian the Fist]

Deleting the .lock should end the service, safely, after completing the current structure. The program can be detected as finished by watching for progress.txt to disappear and the sleeping an additional 2 seconds just to be safe.