Hello lists,
From jail(3):
> The jail_getv() function takes a null-terminated list of name and value
> strings, and passes it to jail_get(2). It is the caller's responsibility
> to ensure that the value strings point to buffers large enough to hold
> the string representation of
[reordered parts of the reply for better reading flow]
On 05/18/2018 18:49, James Gritton wrote:
I would recommend skipping out on jail_getv(), which is really only
good for getting a few well-known parameters, and instead use the more
complete but more complex jailparam_init/get/export/free.
T
Hi!
I'm writing a jail management library [1], and am wondering if there's
any nice way to get notified of jail state changes (especially running
-> dying -> dead) as well as of parameter changes.
What are the opinions on adding a kevent(2) for these things?
Fabian
[1] https://github.com/fu
On 1/4/19 6:20 PM, Christian Barthel wrote:
I worked on something similar (not a library but more acting like a
daemon). The way I managed Jails was by forking a jail(8) process
and collecting the exit status. Not sure if that is possible for your
library case.
Yes, I've thought about doing
On 1/4/19 9:29 PM, Konstantin Belousov wrote:
On Fri, Jan 04, 2019 at 09:11:58PM +0100, Fabian Freyer wrote:
On 1/4/19 5:14 PM, Konstantin Belousov wrote:
No, kevent(2) is not suitable mechanism to notify about jail state changes.
If anything in the existing system can be reused for such
Hi all,
I'd like to call for testing of the kernel module kmod-devctl-jail [1],
which adds devctl(4) support for jail state changes. The aim is to
provide some logging and/or auditing support as well as providing jail
managers with a way to get notified of jail state changes.
I'm not yet cle
