weird behavior with "[un]setopt monitor"

weird behavior with "[un]setopt monitor"

[Atom Smasher]

as expected:
  % sleep 30 &
  [1] 47773
  % jobs
  [1]  + running    sleep 30
  % kill %sleep
  [1]  + terminated  sleep 30

somewhat as expected:
  % unsetopt monitor ; sleep 30 & ; setopt monitor
  % jobs
  [1]  + running    sleep 30
  % kill %sleep
  kill: kill %sleep failed: no such process

not at all expected:
  % unsetopt monitor ; sleep 30 & ; setopt monitor
  % jobs
  [1]  + running    sleep 30
  % unsetopt monitor ; kill %sleep
  % jobs
  %

in the first case, i start "sleep 30" in the background. it shows up in 
the jobs table, and can be killed as expected. no surprised there.

in the second case, i start "sleep 30" in the background after unsetting 
the monitor option. after the job is dropped into the background, i reset 
the monitor option. the job is listed in the jobs table, which i didn't 
expect. as expected, it isn't killed in the normal way.

the third example is where things really get weird. i start "sleep 30" in 
the background after unsetting the monitor option. after the job is 
dropped into the background, i reset the monitor option. the job is listed 
in the jobs table, which i didn't expect. so far, the same as the second 
example. but if after i unset the monitor option, i can kill the job with 
kill. not at all what i expected.

is this a bug or an undocumented feature? it seems like an alternate table 
to store jobs in, which is useful. can i take advantage of this feature? 
or is it a bug that will be "fixed"?

thanks...


-- 
         ...atom

  ________________________
  http://atom.smasher.org/
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -------------------------------------------------

 	"I have presented factual data, statistical data, and
 	 projected data. Form your own conclusions. Perhaps the
 	 NSA has found a polynomial-time (read: fast) factoring
 	 algorithm. But we cannot dismiss an otherwise secure
 	 cryptosystem due to paranoia. Of course, on the same
 	 token, we cannot trust cryptosystems on hearsay or
 	 assumptions of security. Bottom line is this: in the
 	 field of computer security, it pays to be cautious. But
 	 it doesn't pay to be un-informed or needlessly paranoid.
 	 Know the facts."
 		-- infiNity, The PGP Attack FAQ

Re: weird behavior with "[un]setopt monitor"

[Bart Schaefer]

On Mar 14,  9:34pm, Atom Smasher wrote:
}
} somewhat as expected:
}   % unsetopt monitor ; sleep 30 & ; setopt monitor
}   % jobs
}   [1]  + running    sleep 30
}   % kill %sleep
}   kill: kill %sleep failed: no such process

No, that's definitely not as expected.  The kill should have succeeded.
 
} not at all expected:
}   % unsetopt monitor ; sleep 30 & ; setopt monitor
}   % jobs
}   [1]  + running    sleep 30
}   % unsetopt monitor ; kill %sleep
}   % jobs

This, however, IS as expected.

} in the second case, i start "sleep 30" in the background after unsetting 
} the monitor option. after the job is dropped into the background, i reset 
} the monitor option. the job is listed in the jobs table, which i didn't 
} expect.

Jobs started with monitor turned off have always been in the job table,
because they have to be properly managed by the shell for purposes of
the "wait" command etc. even if you can't manipulate them with "fg" and
"bg".

Older zsh hid them from view, but would then lose track of details like
the job name, so when you turned monitor back on again "jobs" would
find them and produce a list of nameless processes.

There are still some oddities.  I don't recall exactly when jobs started
to be visible to "jobs" even with monitor turned off, but if they are
started when monitor is off they're impervious to ctrl+z (TSTP signals),
so if you turn monitor on again and bring them into the foreground, they
can't be stopped and re-backgrounded.

} as expected, it isn't killed in the normal way.

This is a bug.  Once you turn "monitor" back on, "kill" attempts to hit
jobs with killpg(pid, sig), equivalent to kill(-pid, sig), but because
the job was started with monitor turned off, it has no process group
and consequently killpg() fails even though the pid exists.

} the third example is where things really get weird. i start "sleep 30" in 
} the background after unsetting the monitor option. after the job is 
} dropped into the background, i reset the monitor option. the job is listed 
} in the jobs table, which i didn't expect. so far, the same as the second 
} example. but if after i unset the monitor option, i can kill the job with 
} kill. not at all what i expected.

With monitor off, zsh does kill(pid, sig) directly to stop only the
single process, regardless of whether the jobs were started with the
option turned on, so the right thing happens for jobs started without
monitor, but the wrong thing happens for jobs started with monitor.
This probably needs some attention; "kill" should do its work based
on the state of "monitor" at the time the job table entry was created,
not on the current state.

Bottom line, you're not guaranteed of predictable behavior unless you
change the monitor option only when the job table is empty.

} is this a bug or an undocumented feature?

It's a bug, but not the bug you think.

} it seems like an alternate table 
} to store jobs in, which is useful.

I'm not sure how you reached that conclusion, but it all depends on
whether the jobs are assigned to a process group.  Jobs started with
monitor off are never expected to have interaction with a terminal,
so they get no process group and ignore tty-generated signals.  All
jobs are in the same table, regardless.

It could be considered a bug that "fg" fails to ignore jobs that do
not have a process group.

Re: weird behavior with "[un]setopt monitor"

[Peter Stephenson]

On Sat, 14 Mar 2009 09:56:40 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Bottom line, you're not guaranteed of predictable behavior unless you
> change the monitor option only when the job table is empty.

Indeed it's never really been set up to be a dynamic option at all, more
as a way of querying whether a shell has job control, although turning
it off at the start of a shell is probably consistent.  This hasn't been
documented, though.  I can believe there are numerous oddities around if
you start trying to turn it on and off.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/