How can I wake a sleeping bash script?

When a Bash script is running a sleep, here's what the pstree might look like:

bash(10102)───sleep(8506)

Both have process IDs (PIDs), even when running as a script. If we wanted to interrupt the sleep, we'd send kill 8506 and the Bash session would resume... The problem is in a scripted environment we don't know the PID of the sleep command and there isn't a human to look at the process tree.

We can get the PID of the Bash session through the $$ magic variable. If we can store that somewhere, we can then target instances of sleep that are running underneath that PID. Here's what I'd put in the script:

# write the current session's PID to file
echo $$ >> myscript.pid

# go to sleep for a long time
sleep 1000

And then we can tell pkill to nuke sleep instances running underneath that PID:

pkill -P $(<myscript.pid) sleep

Again, this is limiting itself to only sleep processes running directly under that one Bash session. As long as the PID was logged correctly, this makes it a lot safer than killall sleep or pkill sleep, which could nuke any sleep process on the system (permissions allowing).

We can prove that theory with the following example where we have three separate bash sessions, two running sleep. Only because we're specifying the PID of the top-left bash session, only its sleep is killed.

---

An alternative approach is to push sleep into the background, store its PID and then return it to the foreground. In the script:

sleep 1000 &
echo $! > myscript.sleep.pid
fg

And to kill it:

kill $(<myscript.sleep.pid)

You could write your script to handle ("trap") other signals from kill etc. so you could modify the scripts behaviour as needed. See man bash:

SIGNALS
   When  bash  is  interactive,  in the absence of any traps, it ignores SIGTERM (so that kill 0 does not
   kill an interactive shell), and SIGINT is caught and handled (so that the wait builtin  is  interrupt-
   ible).   In all cases, bash ignores SIGQUIT.  If job control is in effect, bash ignores SIGTTIN, SIGT-
   TOU, and SIGTSTP.

   Non-builtin commands run by bash have signal handlers set to the values inherited by  the  shell  from
   its  parent.   When  job  control is not in effect, asynchronous commands ignore SIGINT and SIGQUIT in
   addition to these inherited handlers.  Commands run as a result of  command  substitution  ignore  the
   keyboard-generated job control signals SIGTTIN, SIGTTOU, and SIGTSTP.

   The shell exits by default upon receipt of a SIGHUP.  Before exiting, an interactive shell resends the
   SIGHUP to all jobs, running or stopped.  Stopped jobs are sent SIGCONT to ensure that they receive the
   SIGHUP.   To  prevent the shell from sending the signal to a particular job, it should be removed from
   the jobs table with the disown builtin (see SHELL BUILTIN COMMANDS below) or  marked  to  not  receive
   SIGHUP using disown -h.

   If  the huponexit shell option has been set with shopt, bash sends a SIGHUP to all jobs when an inter-
   active login shell exits.

   If bash is waiting for a command to complete and receives a signal for which a trap has been set,  the
   trap  will not be executed until the command completes.  When bash is waiting for an asynchronous com-
   mand via the wait builtin, the reception of a signal for which a trap has been set will cause the wait
   builtin  to  return immediately with an exit status greater than 128, immediately after which the trap
   is executed.

You could just kill sleep which would continue to the next line of the script:

pkill sleep

Note that this would kill any sleep process running in your system, not only in your script.