Signal trapped during read resumes sleeping

Shell Programming and Scripting
1

Greetings. This is my first post in this forum; I hope y'all find it useful. One caveat: "Concise" is my middle name. NOT! :smiley:

I am almost done with a shell script that runs as a daemon. It monitors a message log that is frequently written to by a database server but it it works my client will have more such daemons.

After a few rough starts and things that just don't work, I am using dtksh (M-12/28/93d; the alternative on my client's old Solaris box was ksh 88). Here's how the loop works:

tail -0f $ONLINELOG |
while true                           # Loop until a break command
do
  if [[ $go_flag -eq $FALSE ]]
  then
    break
  fi
  read newline
<.... Do my stuff, parsing $newline for a significant event ...>
done

Now how do I send this daemon a message to clean up after itself and exit quietly? Well, before I started that loop, I set up a simple, one-signal trap command:

trap 'echo Interrupt received; go_flag=$FALSE; break' INT

(I'm not even certain that break will do what I think.) All so very logical! So what's the problem? :confused:

Well, it is overwhelmingly likely that when I send it the "kill -2", my daemon will be sleeping on that "read newline" command. My output log shows that it did catch the signal but it goes right back to sleep on that read!

A Google search [ksh signal break read] showed me I am not alone; the first hit was a 5-year-old posting on this very forum. I was quite unhappy with the conclusion of that thread but even if ksh83v (the latest I've heard of) has fixed the issues discussed in that thread, I have no access to that. But I love to tinker so I added this to the trap handler:

trap 'echo Interrupt received; go_flag=$FALSE; echo "" >>$ONLINELOG; break' INT

What did I do up there?

I fed an extra empty line to the end of the file being tailed. (Remember, I'm not reading directly from the file but from a pipeline.) Hence, that read is immediately satisfied and the process awakens to see an empty line, continues back at the top of the loop, where it sees that $go_flag is $FALSE and breaks out of the loop.

This kluge worked for me, although it's a fair bet it won't work for everyone. And, of course, for all I know the SA_RESETHAND issue discussed in that post has been fixed.

-- JS, who should have been a teacher. :rolleyes:

2

I don't think the "resethand" issue is related. Your shell has no issue receiving the interrupt, and does exactly what you told it to do -- wait for input. What needs to be told that something is happening is read. How can you do that? Close whatever it's reading from. Killing tail would do it, for example. Or using a named pipe and forcing it to close.

#!/bin/ksh

# On ctrl-C, close the read-end of the named pipe.
trap 'echo "Closing FIFO" ; exec 5<&-' INT

mkfifo $$ # Create a named pipe file in the current directory

# Open one end of pipe in background, read from log file,
# write into pipe.
# This will hang until we open the other end,
# so we have to put it in the background.
(exec tail -f /var/log/logfile > $$) &

exec 5<$$ # Open the other end in our shell, into file descriptor 5.
rm /tmp/$$ # Clean up mess

# Read from file descriptor 5 until something forces it to close,
# whether it be tail quitting, the pipe closing, or the apocalypse
while read LINE
do
        echo "$LINE"
done <&5

wait # wait for tail to quit.  Closing our end of the pipe ought to force it to quit (it will get SIGPIPE)

echo "Normal exit"
3

Corona,
I like it better than my own solution because it would work where I cannot mess with the input file. :b: I did call my solution a kluge, indicating some dissatisfaction with it.

I may use your technique in the future or I may even start tinkering with it now, although I have started to implement the script across my servers. Pragmatism says let it run as it, for now.

-- JS

1 Like