How to close "screen" session from a script?

taylorkh · 06-26-2011, 05:15 PM

I am using screen to start a LONG running script on my server over an ssh connection. This works fine. I can see that the script is continuing to run after I disconnect from the screen session using Ctrl-A d. When the script is complete I can reconnect to the screen session and manually terminate it.

I would like to be able to terminate the screen session at the end of the script. I tried issuing an exit command at the end of the script. That did NOT work. Any ideas?

TIA,

Ken

Tinkster · 06-26-2011, 05:18 PM

You could tack a "kill -9 PID" at the end of your script if you
can uniquely identify the screen instance you're firing up :}

Cheers,
Tink

taylorkh · 06-26-2011, 05:45 PM

Thanks Tinkster,

I think that would be rather easy for one script running. My plan is to initiate 4 parallel scripts so I will have to do some investigation. If I KNEW which script would end last I could have it iterate and kill all "screen" processes. Or I could run the scripts serially. I am not sure which would be faster. Basically I am using dd if=/dev/urandom of=(partition I want to clear)/bigfile to do a quick and dirty wipe of free space. Well at least quick compared to using sfill -l -l which I computed would take 12 DAYS! I guess I need to fill up more of the 5 GB of storage on my server with crap so I have less free space to wipe

Ken

Tinkster · 06-26-2011, 07:06 PM

You could conceivably fire of all processes; check them in a while loop w/
a 1-second sleep, and kill screen if they're all gone ....
something like

Code:

/path/to/script1 &
/path/to/script2 &

...
# after the last of the four
while pgrep "script1|script2|..." >/dev/null 2>&1
do
  sleep 1
done
pkill  -9 "SCREEN"

No guarantee for completeness above ;D

Cheers,
Tink

chrism01 · 06-26-2011, 07:55 PM

An alternative to the above would be to utilise the $! Special Var http://tldp.org/LDP/abs/html/internalvariables.html and track the actual pids of the created processes.

taylorkh · 06-27-2011, 08:40 AM

Thanks folks! I allowed two processes to run overnight (14 hours) and based on the progress they made I think I will have to run sequentially. That will make things easier.

Ken

Tinkster · 06-27-2011, 12:25 PM

Out of curiosity: is this path to be wiped on an external USB device?

taylorkh · 06-27-2011, 01:47 PM

In answer to your curiosity... The system consists of:

A Dell Poweredge 400 SC server (Pentium 4; 2.33 GHz; 3 GB RAM) with the following hard drives (all SATA):

Western Digital Caviar Black 1 TB
Western Digital Caviar Green 1 TB
Western Digital Caviar Green 1 TB
Western Digital Caviar Green 2 TB

The green drives are low power consumption and a little slow but not that slow. I think the limiting factor is the CPU which is consumed 100% by dd.

I have had better results creating a file of say 1 GB with dd if=/dev/urandom and then copying the 1 GB files to the drive to be wiped from within a loop (cp to an incremented file name each time) until it runs out of space.

Ken

Tinkster · 06-27-2011, 02:16 PM

You could (to help the CPU) use a decent blocksize with dd ...

dd if=/dev/urandom of=/... bs=4096

Of course the problem may be the urandom usage.

[edit]
Scrap that - slow as. From urandoms man-page

Quote:

The kernel random-number generator is designed to produce a small
amount of high-quality seed material to seed a cryptographic pseudo-
random number generator (CPRNG). It is designed for security, not
speed, and is poorly suited to generating large amounts of random data.
Users should be very economical in the amount of seed material that
they read from /dev/urandom (and /dev/random); unnecessarily reading
large quantities of data from this device will have a negative impact
on other users of the device.

So really, you probably just want to generate a 4096 or 2048
byte file, and slap that over the devices in the loop ;}
[/edit]

Cheers,
Tink

taylorkh · 06-27-2011, 06:05 PM

Thanks! Good point. urandom is really slow. I had at one time played with copying various size files of random data to fill free space. Larger files seemed to be faster.

Ken