jail(8): ignore SIGINT

[kevans]

Summary

Terminating upon SIGINT can be problematic, in the case of jails that a user may not expect to be persistent; e.g. jail -c command=yes followed by a prompt ^C will send SIGINT to both jail and command, terminating both and leaving the jail laying around. In theory, this is not necessary; the command should be terminated, then jail(8) will do the appropriate cleanup.

This is perhaps a request for comments. =-)

[kib]

Why not put the spawned process into its own (foreground) group ?

[kevans]

In D24745#544523, @kib wrote:

Why not put the spawned process into its own (foreground) group ?

I had considered/attempted this, but I also do various things that rely on the current model that I haven't been able to reconcile being able to do in a world where jail(8) pushes the spawned process into its own foreground group, often piping truss into less for examination, e.g. truss -Hf jail -c command=... 2>&1 | less

[jamie]

There's a "right thing" to do on SIGINT, though it's not immediately obvious what that is. In the jail creation process, it would make sense to clean up a partially created jail, probably in conjunction with letting the jailed processes handle their own SIGINT. But that's not quite the same as just ignoring it, because there are other cases:

In the jail removal process, a case may be made for skipping the current step of removal (likely something involving exec.stop commands, i.e. rc.shutdown), and then continuing to actually remove the jail. Or a case may be made for aborting the removal and keeping the jail around. It's all in guessing why the user wanted to abort.

In the case of multiple jails in series, you wouldn't want to start a new jail creation/removal, just clean up the current one and then exit.

[kevans]

In D24745#544634, @jamie wrote:

There's a "right thing" to do on SIGINT, though it's not immediately obvious what that is. In the jail creation process, it would make sense to clean up a partially created jail, probably in conjunction with letting the jailed processes handle their own SIGINT. But that's not quite the same as just ignoring it, because there are other cases:

In the jail removal process, a case may be made for skipping the current step of removal (likely something involving exec.stop commands, i.e. rc.shutdown), and then continuing to actually remove the jail. Or a case may be made for aborting the removal and keeping the jail around. It's all in guessing why the user wanted to abort.

In the case of multiple jails in series, you wouldn't want to start a new jail creation/removal, just clean up the current one and then exit.

It seems that it's probably just the case that jail(8) should not be bent around to do what I'm trying to do with it. From the common perspective (described above), I suspect the current behavior is probably the most ideal as the jail(8) user can assess whatever damage may be caused based on where they promptly interrupted it. It's not really intended to throw a simple command that may be interrupted in a jail to do quirky debugging with.

[kib]

In D24745#544615, @kevans wrote:

In D24745#544523, @kib wrote:

Why not put the spawned process into its own (foreground) group ?

I had considered/attempted this, but I also do various things that rely on the current model that I haven't been able to reconcile being able to do in a world where jail(8) pushes the spawned process into its own foreground group, often piping truss into less for examination, e.g. truss -Hf jail -c command=... 2>&1 | less

Why would use a separate group changes anything for truss ?

[kevans]

In D24745#544649, @kib wrote:

In D24745#544615, @kevans wrote:

In D24745#544523, @kib wrote:

Why not put the spawned process into its own (foreground) group ?

I had considered/attempted this, but I also do various things that rely on the current model that I haven't been able to reconcile being able to do in a world where jail(8) pushes the spawned process into its own foreground group, often piping truss into less for examination, e.g. truss -Hf jail -c command=... 2>&1 | less

Why would use a separate group changes anything for truss ?

The pipe into less is what kills it, as we get hit with a SIGTTOU.

[kevans]

I've written and switched to sysutils/quickjail to solve my problem here... simple utility that creates truly non-persistent jails because it doesn't need to observe the result and potentially run other scripts and whatnot.