How can I terminate a process using a script.

[Cadillac84]

The situation is this:

For 24 hours, a process is running as follows:

#tcpdump tcp -q -a -i eth1 > /my_dir/dated_logfile

When the time becomes 23:59, I want to terminate that process and immediately restart it with a new logfile name.

I am handling the logfile naming using a suggestion given to me in an earlier thread like this:

# DATE1=$(date +%y%m%d)

# sleep 60

# DATE2=$(date +%y%m%d)

Now I can use filenames $DATE1tc.log and $DATE2tc.log.

That gives me, for example, 020826tc.log and 020827tc.log as my two file names. The 26 file is today's and I will use that file name to grep the file for what I want to split out and put the parts in their little boxes. All that is in operation thanks to bwkaz.

All that remains for me to have this fully automated is to know how to terminate the tcpdump so that I can manipulate the old log.

I guess I could start the new tcpdump without stopping the old one, but then I couldn't get rid of the old logfile when I am finished.

I have d/l the PDF version of Advanced Bash Scripting manual and I've looked at it, but heck, it's 450 pages and I am having trouble finding my answer!

Can someone help with this?

If it helps, there need be only one tcpdump process underway at any given time. I think the process needs to be ended with a Ctrl-C rather than "kill" so that whatever is unwritten will be written to the file and it closed.

My idea is to wait for the date change (sleep 60) and once having established the name of the new logfile, terminate the process tcpdump and immediately start it again logging to the new file.

Many thanks for any suggestions.

Chuck Moore
CNMoore@Knology.net

[bwkaz]

Well, Ctrl-C is (normally) equivalent to SIGINT, and kill (or, more specifically, killall) can send SIGINT as well as SIGTERM (the default) and SIGKILL.

Try killall --wait --signal=INT tcpdump for starters, if there's only one tcpdump process at a time.

You may not want that --wait in there, just in case the SIGINT gets ignored (read the options section of man killall, under "--wait", for more info -- or at least, see if it makes any sense). Although if Ctrl-C worked every time, then SIGINT shouldn't be being ignored.

[Cadillac84]

I tried that in a manually invoked script which stopped the tcpdump and then printed 'ps -a' and then restarted tcpdump and printed 'ps -a' again.

(First, I made a backup of the logfile :-)

Anyway, that worked just fine. So, I restarted logging >> 020826tc.log and I'm going to see in the morning if it did the whole thing.

I went ahead and left the --wait in there

By the way, the manner of "killing" must have been as desired because everyone has gone home and all is quiet on eth1 -- even so, the closed log file was several hundred bytes larger than the backup and there was no "junk" at the bottom of it. So, the method you prescribed caused the buffer to be written to the log before the process was terminated.

You have been very helpful to me today. Thank you very much.

My next project is to set up a MTA -- I'm looking at Exim. I don't know what the heck I'm doing, but I sure am having fun for a hexagenarian!! (I would have said "sexagenarian," but that's probably an oxymoron in my case!)

Cheers and g'day.

Chuck Moore
CNMoore@Knology.net

[bwkaz]

Hey, no problem. You'll probably have to ask someone else for exim (or any MTA), though -- I've never set up anything like that.

[Cadillac84]

The tcpdump process was stopped and the logfile properly terminated, but the new logging didn't start.

Hmm-m-m.

I checked over my script, and I found lots of mistakes -- and I *said* I ran it manually and it worked! Was I telling a fib, or was I just dumb, or was it a coincidence that it ran!

Anyway, it appears that it stopped at the point of running the line:

#tcpdump tcp -q -a -i eth1 > /usr/log/$DATE'tc.log'

I have an idea!!!

When the script is running, having been called by 'crontab' what tty is is going to run in? Must I be logged in on the "active" tty in order for it to run?

My situation last night (when it failed) was that tty1-tty5 were logged out, and tty6 was running the process 'tcpdump' with its output directed to a logfile.

The tty which was currently selected as stdout was tty1 which was displaying the login: prompt.

Is that what was wrong??

Chuck

[bwkaz]

I doubt it, since you're redirecting stdout anyway.

Did your root account get an email from cron about a job not being able to run? Try running mail as root.

Otherwise, what's the cron line that runs the script, and what's the full script look like?

[Cadillac84]

I think I figured out what is wrong.

However, I'll start by answering your question.

I did a 'pico /etc/crontab' and inserted the line:

59 23 * * * root /bin/bash /usr/log/prepare_logs

Tonight it got quiet early and I set the time to 23:57 and waited.

I set my display on tty6 and, sure enough, at about what I would consider 24:00 the tcpdump process got killed and tty6 went to a # prompt.

However, sadly, it did not go back to "listening on eth1"

Also, I have isolated the part of the script that I think IS working from that which I think is NOT working and did a thing called /usr/log/prepare_logs_manual

When I involke that script, it greps and makes the individual logs and mounts the NFS and copies the individual logs to the NetWare volume and ncpumounts and then zips the individual files and so on. So, all that is good.

The only thing that does NOT seem to work AND, in not working causes the rest of the script to bomb, is:

tcpdump tcp -q -a -i eth1 > /usr/log/$DATE2'tc.log'

Now, I asked myself, why does that not run???

Well, I answered myself, because THAT process does not terminate and the script can't wait for it. Well, of course!!

So, my idea is that I must invoke a command shell under which that process will run.

I THINK the line should be like THIS:

# sh tcpdump tcp -q -a -i eth1 > /usr/log/$DATE2'tc.log'

What do YOU think???

Chuck

[furrycat]

Why don't you save yourself all this hassle and use multilog?

http://cr.yp.to/daemontools.html

Create the directory dump somewhere. Create dump/log. Write the file dump/run: #!/bin/bash
exec 2>&1 tcpdump tcp -q -a -i eth1Write the file dump/log/run: #!/bin/bash
exec multilog t s131072 n100 /var/log/dump Start the whole thing running with supervise dump.

Now all your output will go into log files in /var/log/dump. As each log file reaches 131072 bytes, it will be rotated out. Set your cron job to concatenate all the log files at midnight. tcpdump need never be restarted.

[Cadillac84]

Too bad there is no icon for scratching the head (lol).

I'm going to print this thread and think about that over the long weekend -- I suppose it is *not* "Labor Day weekend" in China! Sorry about that!

That could turn out to be a better way to do it -- probably is.

Meanwhile, I *did* get the problem solved by setting 'tcpdump' to run in the background.

# tcpdump tcp -q -a -i eth1 > /usr/log/$DATE2'tc.log' &

causes it to run just fine.

I also put a date variable comparison in there just in case I forget and run it manually so it will append if the date doesn't change

#if [[ $DATE = $DATE2 ]]
# then tcpdump tcp -q -a -i eth1 >> /usr/log/$DATE2'tc.log' &
# else tcpdump tcp -q -a -i eth1 > /usr/log/$DATE2'tc.log' &
#fi

I've set the clock ahead to let it test for a simulated two-day cycle and it is working. So, I'm going to leave it alone until I get back and then I'll have a go at *your* idea.

Thank all of you for your help.

Chuck Moore
CNMoore@Knology.net