Script in cron job kills needed processes

[George_231]

I have a script running in cron that kills processes NOT attached to a terminal, i.e. with a question mark in the ps -ef output. The script has a provision to exclude certain users like root, lp, application users. I recently added one more ID to be excluded but it continues to kill his processes.
Do I need to recycle cron?
Here is the script:
#!/usr/bin/sh
# kill_nonterm_procs
#
ps -ef | grep "?" > /tmp/RUNPROCS
cat /tmp/RUNPROCS | awk '{ print $1 }' > /tmp/RUNPROCS_USERS
cat /tmp/RUNPROCS_USERS |
grep -v mfg |
grep -v mls |
grep -v root |
grep -v adusys |
grep -v pedi53 |
grep -v pedi54 |
grep -v lp |
grep -v tngadmin|
grep -v ftp |
grep -v patrol |
grep -v patuser |
grep -v jzbnvs |
grep -v grep | sort -u > /tmp/RUNPROCS_USERS_CLEAN
if [ -s /tmp/RUNPROCS_USERS_CLEAN ]
then
for i in `cat /tmp/RUNPROCS_USERS_CLEAN`
do
echo `date` >>/tmp/GG
echo `ps -fu $i | grep -v UID | grep "?"` >> /tmp/GG
PROCS=`ps -fu $i | grep "?" | grep -v PID | grep -v grep | sort -u | awk '{print $2 }'`
if [ -n "$PROCS" ]
then
kill -15 $PROCS
else
:
fi
done
rm /tmp/RUNPROCS
rm /tmp/RUNPROCS_USERS
rm /tmp/RUNPROCS_USERS_CLEAN
else
exit 2
fi

[Pete Randall]

No need to recycle cron, but you do have to have it re-read your cron input. Generally, it's done like this:

crontabl -l > cronfile
edit cronfile to make changes
crontab cronfile


Pete

[Pete Randall]

I'll take that back. If you change the script that cron is executing, then the change should have been implemented immediately. I would look for a flaw in your script logic instead.


Pete

[Geoff Wild]

No need to recycle cron - should be able to just make the change - and the next time it is run - it will run the newest version of the script..

Question is, why are you wanting to kill processes not attatched to a terminel?

Rgds...Geoff

[George_231]

Geoff,
I need to run this script every 30 minutes because there are thousands of users who connect to the server using a windows telnet client and do not log out. Their session shows in "ps -ef" with a question mark.

[Geoff Wild]

Do those show up with a?

who -p

Rgds...Geoff

[Geoff Wild]

Sorry - that should be:

who -du

Rgds...Geoff

[Geoff Wild]

Just took a quick look - don't think who -du will help...do they show up with a "who" at all?

Otherwise, the ps way may be the only way....

Which user is it still killing?

Rgds...Geoff

[Howard Marshall]

After giving this a little extra though I think I would take a different approach.

Instead of making an exclusion list and killing everyone else I think I would make an inclusion list, set up in a for loop, and use ps -fu instead of -ef

That way you are certain that you are only killing user processes for those users its ok to kill those processes for and that your not missing that should be killed just because the processes happens to have one of your excluded strings in description.

#!/usr/bin/sh

for user in user1 user2 user3 user4 user5
do
ps -fu $user | get process list to kill
kill process list
done

[George_231]

The processes to be killed do not show in "who -du" b ut only in "ps -ef"
The script works fine when run manually meaning it excludes the newly added user (in my case user "tngadmin").
The problem occurs when run from cron. I re-read the crontab file with "crontab -e" but it keeps killing the newly added to the exclusion list user "tngadmin".
So I am wondering if I need to recycle cron at a suitable time tonight!?

[Geoff Wild]

No harm stop/starting cron - should be fine during the day - unless there is an issue with some cron job..

/sbin/init.d/cron stop ; /sbin/init.d/cron start

Rgds...Geoff

[OldSchool]

As others have stated, the is no need to recycle cron, its going to run the whatever the script says at the time it is run.

I'd NOT delete the files in /tmp and see if the give you a clue as to which step in your script isn't excluding tngadmin and work forward from there.

[Patrick Wallek]

I seriously doubt that stopping and restarting cron will have any effect.

Usually problems arise in scripts run from cron because of sparse environments. You get a VERY BASIC environment in cron.

Why not try this:

Modify the first line of the script to read

#!/usr/bin/sh -x

The '-x' will force you into 'debug mode'. Then modify your cron job so that you get an e-mail with the results of the run.

1 2 * * * scriptname 2>&1 | mailx -s "script output" youremailaddresshere

Then have a look at what you received to see if you can trace where the problem lies.

[Steven E. Protter]

Shalom,

Possible solution for the telnet users:

1) Configure the applicaiton to terminate after a certain number of minutes of inactivity.
2) Configure the variable TMOUT for all users in their environment prior to running any application.

These two steps will self terminate sessions that have been left idle.

Good Luck,

SEP

[George_231]

cat -e "script name" solved the problem. Found additional space in script. I was running manually the same script but with no space. Thanks everybody.