0

In this answer on SO, I gave an example that should have used a -SIGCONT signal in a job submitted to at. However, I found that the process that I had stopped with -SIGSTOP did not continue. When I changed the signal to the numeric value, it worked.

echo "kill -18 $rspid"|at now + 2 minutes

It's a bad idea to use the numeric value because it can be different on different systems.

How can I submit this job with a symbolic signal (-SIGCONT) instead of the numeric one (-18)?

Community
  • 1
Dennis Williamson
  • 62,149
  • 16
  • 116
  • 151

2 Answers2

7

My guess would be that whatever shell your at job is using is different to the one that you use at the command line, and the at job shell doesn't have a kill built-in that knows about symbolic signal symbols. This is common on Ubuntu, which uses dash for /bin/sh (which is used by at by default) but /bin/bash for interactive shells.

You can use the 'kill' binary by specifying the path to it:

echo "/bin/kill -CONT $rspid" | at now + 2 minutes

Or else specify the shell to execute explicitly:

echo "/bin/bash -c \"kill -CONT $rspid\"" |at now + 2 minutes

I thought there was an option to tell at what shell to use, but I can't seem to find any mention of it now. Perhaps a shebang would work...

womble
  • 96,255
  • 29
  • 175
  • 230
1

It turns out that dash likes signals in the form -CONT and doesn't understand the -SIGCONT style. Since bash understands both, it may be more portable to use the former.

In my testing, it didn't make any difference whether I included an explicit path to 'kill' but the way the signal is specified did.

Dennis Williamson
  • 62,149
  • 16
  • 116
  • 151
  • 2
    Indeed -NAME (e.g. -CONT) or -s NAME (e.g. -s CONT) is the standard (http://www.opengroup.org/onlinepubs/000095399/utilities/kill.html) – Matthew Flaschen May 09 '09 at 21:13
  • 1
    Since that page is a bit lengthy and the information is near the bottom, I have quoted the relevant portion here: "An early proposal also required symbolic signal_names to be recognized with or without the SIG prefix. Historical versions of kill have not written the SIG prefix for the -l option and have not recognized the SIG prefix on signal_names. Since neither applications portability nor ease-of-use would be improved by requiring this extension, it is no longer required." – Dennis Williamson May 10 '09 at 02:11