instead of a mount.devfs.ruleset pseudo-parameter.
Document the potential for jail escape. From r224615: Always disable mount and unmount for jails with enforce_statfs==2. From r231267: A new jail(8) option "devfs_ruleset" defines the ruleset enforcement for mounting devfs inside jails. A value of -1 disables mounting devfs in jails, a value of zero means no restrictions. Nested jails can only have mounting devfs disabled or inherit parent's enforcement as jails are not allowed to view or manipulate devfs(8) rules. From r232059: To improve control over the use of mount(8) inside a jail(8), introduce a new jail parameter node with the following parameters: allow.mount.devfs: allow mounting the devfs filesystem inside a jail allow.mount.nullfs: allow mounting the nullfs filesystem inside a jail From r232186: allow.mount.zfs: allow mounting the zfs filesystem inside a jail
Some errors printed the jail name for unnamed (command line) jails. Attempting to create an already-existing jail from the command line returned with no error (even for non-root) due to bad logic in start_state. Ignore kvm_proc errors, which are typically caused by permission problems. Instead, stop ignoring permission errors when removing a jail (but continue to silently ignore other errors, i.e. the jail no longer existing). This makes non-root attempts at removing a jail give a clearer error message.
(but continue to flag when from a config file).
as part of jail removal (IP_STOP_TIMEOUT). Note a jail as "removed" even if it wasn't jail_remove() that did the deed, e.g. if it already went away because all its processes were killed.
finish_command can be processed properly. Call failed() once in next_command() instead of multiple times in run_command(). Continue processing commands when a no-wait operation (IP__OP or background command) succeeds.
and the cost of an ugly single-use global variable.
a single command string to run, and an inner function (run_command) that runs that single string. Move the list of start/stop commands to run from a switch statement into an array, with a new placeholder parameter IP__OP for actually creating or removing the jail. When jail creation fails, revert all non-exec commands in reverse order.
traversed in reverse order.
Make the parallelism limit a global instead of always passing it to run_command and finish_command. In the case of an empty command string, try to run any other strings the command may have. Replace JF_BACKGROUND with its sort-of opposite JF_SLEEPQ. Change j->comstring earlier to render JF_RUNQ unncessary. Change the if-else series to a more readable switch statement. Treat IP_STOP_TIMEOUT like a command, calling run_command which then calls term_procs. When the IP_STOP_TIMEOUT "command" finishes, it shouldn't mess with the parallelism limit. Make sufficient checks in finish_command and run_command so that the nonintuitive j->comstring null check isn't necessary to run them. Rename the "waiting" queue to "depend", because the "sleeping" and "runnable" queues are also used to wait for something.
IP__MOUNT_FROM_FSTAB internal parameter.
enum constants everywhere else.
Before this change if you wanted to suspend your laptop and be sure that your encryption keys are safe, you had to stop all processes that use file system stored on encrypted device, unmount the file system and detach geli provider. This isn't very handy. If you are a lucky user of a laptop where suspend/resume actually works with FreeBSD (I'm not!) you most likely want to suspend your laptop, because you don't want to start everything over again when you turn your laptop back on. And this is where geli suspend/resume steps in. When you execute: # geli suspend -a geli will wait for all in-flight I/O requests, suspend new I/O requests, remove all geli sensitive data from the kernel memory (like encryption keys) and will wait for either 'geli resume' or 'geli detach'. Now with no keys in memory you can suspend your laptop without stopping any processes or unmounting any file systems. When you resume your laptop you have to resume geli devices using 'geli resume' command. You need to provide your passphrase, etc. again so the keys can be restored and suspended I/O requests released. Of course you need to remember that 'geli suspend' won't clear file system cache and other places where data from your geli-encrypted file system might be present. But to get rid of those stopping processes and unmounting file system won't help either - you have to turn your laptop off. Be warned. Also note, that suspending geli device which contains file system with geli utility (or anything used by 'geli resume') is not very good idea, as you won't be able to resume it - when you execute geli(8), the kernel will try to read it and this read I/O request will be suspended.
…some cleaning up to do on existing features, but this is pretty much what the final product will look like.
avoid PCI power state transition from D0 to D3 for suspending case. Default is 1 or enabled.
is enabled by the bootloader.
Using a separate process group here is bad, since (for example) job control in the TTY layer prevents interaction with the TTY, causing the child process to hang. Mentioned on: current@ MFC after: 2 weeks