On 05/09/14 07:42 AM, Craig Small wrote: > On Thu, Sep 04, 2014 at 09:21:52AM -0400, Daniel Dickinson wrote: >> I will have to further testing to confirm this, but from outside the >> jail I can see that procfs is mounted on jail's proc. Since FreeNAS >> runs on FreeBSD that looks to me like FreeBSD's procfs is mounted on >> jail's /proc and is likely why the mount of linprocfs from inside the >> jail (by freebsd-utils) fails (assuming of course the it's not actually >> a case of needing to hack on things so that linprocfs gets mounted prior >> to jail startup). > OK then, you might find its not a compatible procfs in any case then. > That would mean you'd need to use the native freebsd tools, which would > understand that partition better. > > - Craig > This bug can be closed. This issue was that linprocfs (the freebsd linux-compatibility layer procfs) wasn't getting mounted so there was no standard-linux-tool compatible procfs on /proc. I was able to fix this so that linprocfs was mounted instead of freebsd procfs and ps and friends all work properly now.
If linprocfs had not been the problem the solution wouldn't have been a simple switch to native tools (assuming freebsd ps and friends are even available in debian?) because even tools like start-stop-daemon and postfix's postmulti rely on linux-kernel-isms to determine the process name (and even start-stop-daemon that can work purely from PID is normally called with --exec or --name which requires knowing the process name). In any event once I tracked down the misbehaving jail mount the solution was easy enough (use the linux-compatible procfs). Perhaps longer-term for the kfreebsd-* ports it would be a good idea to adapt process querying/manipulating tools but my guess is it would likely require more work than it'd be worth. Regards, Daniel
signature.asc
Description: OpenPGP digital signature
