|-D||Start the jaildaemon in daemon mode. It will check for other instances of jaildaemon by sending a test command to the ipc socket.|
|When run in daemon mode, write the ID of the daemon process into the pidfile using the pidfile(3) functionality. Ignored in utility mode.|
|jaildaemon in utility mode passes commands to the jaildaemon daemon via unix domain socket, which defaults to /var/run/jaildaemon.pipe. You can pass an alternative with this option.|
|Start the jaildaemon in utility mode and pass the command, together with the jid and an optional proctitle to the jaildaemon daemon. When the utility detects no running jaildaemon daemon, an error is reported.|
|-j jid||The jail id of the jail jaildaemon daemon shall attach the probe process to.|
|Setting a proctitle on the probe process is useful to provide some information to scripts or users in the jail, what action sending the HUP signal triggers. The proctitle is visible via the ps(1) utility and signals can be sent to all processes matching the string with the pkill(1) utility when invoked with the -f option. (See EXAMPLES for more details.)|
daemon to respawn the probe process once the triggered command in the host
system has completed.
By default all commands start single shot processes; to avoid race conditions and multiple invocations of possibly non-reentrant scripts, probe processes kill themselves after receiving the HUP signal. Respawning is meant as an option for commands that do not shut down the jail.
Just like the
option, only the
daemon does not wait for the
to complete before re-spawning the probe process.
Use this option only if you know, what youre doing. Most shell scripts are not re-entrant, even if their authors think so and most programs that run long enough should not be started twice with identical parameters.
Probes normally run as user root and thus can only be signalled by root
inside the jail. For some use cases it is desirable to allow non-privileged
processes inside the jail to signal the probe. You can use this switch to
what uid to drop to after being jailed away. (Note that uids inside and
outside the jail are never guaranteed to match.)
Use this option only if you know, what youre doing. For most occasions it is a good idea to restrict signalling probes to the root user.
Exactly one of the -D or -c options must be specified, in daemon mode all options for the utility mode are ignored. In utility mode the -j parameter is mandatory.
The jaildaemon daemon normally is run from its rc(8) script on boot time. Invoke the daemon by hand using this command:
-D -p /var/run/jaildaemon.pid Start the daemon and write the daemons pid to the file /var/run/jaildaemon.pid. (This is the default pid file location.)
When the jaildaemon daemon is alive, you can start attaching probe commands to running jails.
While the first examples show you what is possible, the most simple way of scripting an action is to write a small wrapper script as shown in the third example.
-c ezjail-admin restart example.com-j 23-t EZJAIL_REBOOT Start a probe in jail with jid 23 (presumably a jail with the name "example.com") and assign it the commandezjail-admin restart example.com
The proctitle "EZJAIL_REBOOT" will be visible from within the jail, and a reboot can be triggered from a script inside the jail with the commandpkill -HUP -f EZJAIL_REBOOT
-c zfs snapshot jails/example.com@date +%s-j 42-r -t ZFS_SNAPSHOT Start a probe in jail with jid 42 (presumably a jail with the name "example.com") and assign it the commandzfs snapshot jails/example.com@date +%s
The proctitle "ZFS_SNAPSHOT" will be visible from within the jail and taking a zfs snapshot of the jails file system can be triggered from a script inside the jail with the commandpkill -HUP -f ZFS_SNAPSHOT
After the zfs snapshot command finished, a new probe with identical paramters is spawned and attached to the jail.
-c reload_routing_table.sh example.com-j 1-r -t UPDATE_ROUTING
.An Dirk Engling <email@example.com>.