jails exec.poststart = "jail -r ${name}"; for some cleanup problems?

[kreuter]

I'm on 14.4-RELEASE. I run a few GUI applications as an unprivileged (non-root) account in vnet jails, starting the GUI application with command = "/path/to/program"; (vs., say, ssh'ing into a jail whose exec.start is /bin/sh /etc/rc).

Things mostly work as I expect, but I have found that when the application exits, none of the jail's exec.poststop commands nor the implicit cleanups for the mount or mount.devfs parameters will execute. It's a bit of a pain to do all the cleanups by hand, so I'd like that to be automatic.

Today I had the idea to try exec.poststart = "jail -r ${name}"; It seems to do just what I want, but I wonder if I'm doing something unsound here.

Is this expected to be a reliable way to get the cleanups to happen? Specifically, my understanding is that a non-persistent jail gets destroyed when its last process terminates (at least that's what I think jail(8) says for persist). Does the exec.poststart command count as one of the jail's processes? Or is there some chance of a race condition where the system destroys the jail before the exec.poststart command runs?

(For completeness: the GUI applications I run don't appear ever to start any child processes that would have any reason to outlive their ancestor. So the lifetime of the top-most process in the jail delimits the lifetime of all processes inside the jail environment.)

 

[loveydovey]

I'm having the same problem. I start a jail with a script, and when I run ```jail -r myjail``` it does not clean up the mounted myjail/dev . So I tried to add exec.poststop="umount -f /jails/myjail/dev" - and it does not execute it. I tried exec.poststop"logger hello", but that does not log anything either.

So 2 questions:
1) why is jail's mounted /dev not unmounting on a soft shutdown?
2) why is exec.poststop not executing?

 

[loveydovey]

Ok, Grok is on roids today and is solving this for us.

jail -r only does the nice cleanup (including unmounting devfs and running exec.poststop) when it can find the original parameters.

If you started the jail with a one-off script that only passed the parameters on the jail -c … command line and the name myjail does not exist in a configuration file, then jail -r myjail falls back to the “no-config” path (essentially the same as jail -R). It kills the processes and removes the jail, but it never runs the mount-cleanup code because it has no record that a devfs was mounted for that jail. That is why you still see myjail/dev mounted afterwards and no exec.poststop executes.

What to do​

The reliable ways are:

1. Put the jail in a real config file (recommended)

1. If you must start from a script, also write a jid file (both in starting the jail and shutting the jail down with jail -r)

I actually just tried #2, and it's erroring out saying there's some syntax error in the .jid file.

I personally would add that you can also use your script to trap the exit signal and clean up yourself. I do that on one of my jails, and it works like clockwork, leaving nothing to chance.

 

[loveydovey]

Ok, Grok is now saying that ```jail -r``` expects the same syntax as the .conf file for jails, which is why passing .jid file will not work.

The bottom line is: if you want a nice cleanup after your jail, you either use a configuration file for the jail or you clean up yourself.

 

[kreuter]

This is interesting info; thanks. I suppose this means that some jail parameters, such as exec.poststop end up being strictly useless when supplied as arguments with jail -c. (This doesn't seem an essential characteristic: jail -c could conceivably persist the shutdown-related parameters someplace for jail -r to read later. But given what you've explained, I guess I would also expect that if you add or remove cleanups in a jail's configuration file while the jail is running, jail -r can end up trying to run cleanup commands different from those specified when the jail was created. The possibility of parameter skew between creation-time and shutdown-time might be even more reason to want jail -c to persist cleanup instructions for jail -r, maybe.)

Anyhow, ISTM we're looking at related but distinguishable questions. I'm mostly worried about whether jail -r as a exec.poststart parameter is something that's expected to work by design (or at least as an inferrable consequence of design) vs. something that has happened by accident to have worked for me for a few days.