After running a process in the background (by putting "&" at the end of the command line) the output of "jobs" correctly shows
the process as "running". If I send the process a STOP signal with "kill -STOP", the process stops and "jobs" shows the
process as "suspended (signal)".  The problem is that after sending a CONT signal to the process (with kill -CONT),
"jobs" still shows the process as suspended, even though the process resumes (if it's a media file I can hear it
playing, for example.

The processes I used to test this were "ping -i 4 -f localhost" and mpg321.  I tried the same using bash and the status
are correctly updated. I tried also "/bin/kill" but the same thing happens.

Thank you for your work.

Cheers.

Your job table isn't being updated when you send the STOP/CONT signals externally.

On Wed, 18 Aug 2010 18:29:59 +0000 Clint Adams <schizo@debian.org> wrote:
when sending a SIGCONT.  That's fairly easy to fix, and it sounds like
it addresses the immediate issue.

However, we ought to be cleverer, since we don't get a signal when a
child gets a SIGCONT from outside the shell, which is perfectly
possible.  To handle that we'd need to use wait3() or waitpid() with
WNOHANG to see if the job was still stopped.  That's still fairly
straightforward, the problem is that if the job has just exited we then
need to update the job status as if we were in the SIGCHLD handler, and
that needs more thought to do it properly.  Probably not *that*
difficult.  I don't suppose anyone has an urge to learn about the signal
code?

Index: Src/jobs.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/jobs.c,v
retrieving revision 1.77
diff -p -u -r1.77 jobs.c
--- Src/jobs.c	31 Jul 2010 22:03:41 -0000	1.77
+++ Src/jobs.c	18 Aug 2010 19:58:50 -0000
@@ -2217,7 +2217,7 @@ bin_kill(char *nam, char **argv, UNUSED(
 	    signal. */
 	    if (jobtab[p].stat & STAT_STOPPED) {
 		if (sig == SIGCONT)
-		    jobtab[p].stat &= ~STAT_STOPPED;
+		    makerunning(jobtab + p);
 		if (sig != SIGKILL && sig != SIGCONT && sig != SIGTSTP
 		    && sig != SIGTTOU && sig != SIGTTIN && sig != SIGSTOP)
 		    killjb(jobtab + p, SIGCONT);
@@ -2225,9 +2225,19 @@ bin_kill(char *nam, char **argv, UNUSED(
 	} else if (!isanum(*argv)) {
 	    zwarnnam("kill", "illegal pid: %s", *argv);
 	    returnval++;
-	} else if (kill(atoi(*argv), sig) == -1) {
-	    zwarnnam("kill", "kill %s failed: %e", *argv, errno);
-	    returnval++;
+	} else {
+	    int pid = atoi(*argv);
+	    if (kill(pid, sig) == -1) {
+		zwarnnam("kill", "kill %s failed: %e", *argv, errno);
+		returnval++;
+	    } else if (sig == SIGCONT) {
+		Job jn;
+		Process pn;
+		if (findproc(pid, &jn, &pn, 0)) {
+		    if (WIFSTOPPED(pn->status))
+			pn->status = SP_RUNNING;
+		}
+	    }
 	}
     }
     unqueue_signals();

I think hooking into the kill builtin is the wrong way to fix this.
Instead, use the facilities provided by modern systems which can notify
you if a child process continues. These are si_code CLD_CONTINUED for
SIGCHLD and the WCONTINUED flag and WIFCONTINUED() macro for waitpid().
Some systems do not provide these, and may not even provide queuing and
siginfo for SIGCHLD, so the latter approach seems best. The WCONTINUED
stuff can then be #ifdef'ed out for systems that do not support it.

On Aug 20, 12:14am, Jilles Tjoelker wrote:
}
} > [continuing a stopped background job using kill is not reflected in the
} > output of jobs]
}
} I think hooking into the kill builtin is the wrong way to fix this.
} Instead, use the facilities provided by modern systems which can notify
} you if a child process continues. These are si_code CLD_CONTINUED for
} SIGCHLD and the WCONTINUED flag and WIFCONTINUED() macro for waitpid().

Zsh *soes* use those facilities.

The problem (if I understand the thread so far correctly) is, in order
to use those facilities, zsh has to wait for the job, i.e., call one of
waitpid() or the like.  But the shell doesn't just sit around all day
waiting for background jobs or polling the ones that are stopped to see
if they spontaneously started again -- in fact the whole point is that
it does NOT wait for background jobs.

So unless the OS sends a SIGCHLD when the background job changes state,
zsh isn't aware that it ought to check on the child status.  There is
a SIGCHLD sent to the parent when the background job stops, but that
signal is NOT sent when the child resumes running again.

You can even see this for yourself by installing a handler, e.g.,

    trap "print CHILD" SIGCHLD

Now run something in the background, kill it with -STOP/-CONT from some
other shell, and watch when CHILD is printed (or isn't).

On Aug 18,  9:09pm, Peter Stephenson wrote:
}
} +	    } else if (sig == SIGCONT) {
} +		Job jn;
} +		Process pn;
} +		if (findproc(pid, &jn, &pn, 0)) {
} +		    if (WIFSTOPPED(pn->status))
} +			pn->status = SP_RUNNING;
} +		}
} +	    }

Hmm, are we really guaranteed that the job has started running again
just because we killed it with SIGCONT?  E.g., if the reason it was
stopped is because it got a TTIN or TTOU, is there a possible race
here because it's just going to immediately stop again?