jails Why does a jailed ps(1) suddenly require a kernel to be present? And then complain when it is?

[Jim L.]

In both cases:

find: /boot: No such file or directory

That doesn't give ps(1) any problems on 15.0:

# uname -a; find /boot; ps -a

FreeBSD r2d2.example.edu 15.0-STABLE FreeBSD 15.0-STABLE 15-jail-nul-delim-n281551-ff2129e6b5ee GENERIC amd64
find: /boot: No such file or directory
  PID TT  STAT    TIME COMMAND
57939  0  SJ   0:00.02 bash -l
57955 0 R+J 0:00.00 ps -a

But it does on 15.1-PRERELEASE:

# uname -a; find /boot; ps -a

FreeBSD listhost.example.edu 15.1-PRERELEASE FreeBSD 15.1-PRERELEASE 15-jail-nul-delim-n283204-1e7428f2e128 GENERIC amd64
find: /boot: No such file or directory
ps: /boot/kernel/kernel: No such file or directory

I've been routinely deleting /boot from jails for years.

So from the jailer host, I:

# rsync -a --delete /boot /jail/listhost/
# ps -a
ps: invalid core

The binaries are the same between the jailer and the jailed:

# sha256sum $(which ps) /jail/listhost$(which ps)

3fd4c5882a94ff8f3fb0cd3925e86b6b662746afac92118c563ac3321aec330b  /bin/ps
3fd4c5882a94ff8f3fb0cd3925e86b6b662746afac92118c563ac3321aec330b /jail/listhost/bin/ps

ps works fine on the jailer:

# ps -a

  PID TT  STAT    TIME COMMAND
 3508 v0  Is+  0:00.00 /usr/libexec/getty Pc ttyv0
 3509 v1  Is+  0:00.00 /usr/libexec/getty Pc ttyv1
 3510 v2  Is+  0:00.00 /usr/libexec/getty Pc ttyv2
 3511 v3  Is+  0:00.00 /usr/libexec/getty Pc ttyv3
 3512 v4  Is+  0:00.00 /usr/libexec/getty Pc ttyv4
 3513 v5  Is+  0:00.00 /usr/libexec/getty Pc ttyv5
 3514 v6  Is+  0:00.00 /usr/libexec/getty Pc ttyv6
 3515 v7  Is+  0:00.00 /usr/libexec/getty Pc ttyv7
94700  0  Ss   0:00.02 -bash (bash)
97547 0 R+ 0:00.00 ps -a

Is anyone else seeing this? Any suggested solutions?

Thank you!

 

[Alain De Vos]

running ps in a jail might need permissions .....

There is totally no need for a boot directory in a jail.
Al processes in the jail run on the kernel in the host

 

[Jim L.]

There is totally no need for a boot directory in a jail.

In every prior build I've used, that has been undeniably true. But not in 15.1-PRE.

In the meantime, I'll pull down a newer git tree and try a fresh build.

 

[Emrion]

Where did you get this 15.1-PRERELEASE?

 

[ShelLuser]

First: not sure what you mean with PRERELEASE, but second: running a development build is prone to cause weird situations from time to time because... it's a developer version which contains plenty of debug code (and sometimes unpolished bugs and/or glitches), so running into weird behaviour should be expected.

(edit)

There is totally no need for a boot directory in a jail.

Agreed, absolutely no technical need. However... we've been applying some (minor!) "security through obscurity" policies here and there and having a kernel can be a nice way to deceive some clueless script kiddies. Adding a kernel can sometimes have its uses

 

[Jim L.]

Where did you get this 15.1-PRERELEASE?

# cd /usr/src
# git checkout stable/15
# git pull

A more recent pull made no difference. The binary's details are:

# ls -l /bin/ps; md5sum /bin/ps
-r-xr-xr-x 1 root wheel 59440 Apr 24 07:15 /bin/ps*
5677dcdc45a2b37a84b459f86cecb45c /bin/ps

I did a little more testing in other environment and comparing against previous working binaries: (btw, top(1) is also kaput, "kvm_open: invalid core").

Perhaps the biggest clue (for someone) is that ps also fails in a chroot:

# chroot /jail/listhost/ bash -l
# top -a
kvm_open: invalid core
# ps -a
ps: invalid core

And just as further info:

The last known working binary of ps (under 15.0-STABLE) also does not work under 15.1-PRERELEASE:

(this is in a chroot, not a jail)

# ls -l .zfs/snapshot/xfer/bin/ps
-r-xr-xr-x 1 root wheel 59440 Apr 12 18:33 .zfs/snapshot/xfer/bin/ps*
# .zfs/snapshot/xfer/bin/ps -a
ps: invalid core
# md5sum .zfs/snapshot/xfer/bin/ps
4989ad13fc6389b1ea5e0ff07173be2c .zfs/snapshot/xfer/bin/ps
# md5sum /bin/ps
5677dcdc45a2b37a84b459f86cecb45c /bin/ps

 

[Jim L.]

First: not sure what you mean with PRERELEASE, but second: running a development build is prone to cause weird situations from time to time because... it's a developer version which contains plenty of debug code (and sometimes unpolished bugs and/or glitches), so running into weird behaviour should be expected.

Yes, I would expect that in -CURRENT, but I was under the impression that commits to -STABLE were vetted more closely. And yes, it's possible that someone just missed something and this problem will go away a day or two down the road.

 

[Charlie_]

First: not sure what you mean with PRERELEASE,

src - FreeBSD source tree

cgit.freebsd.org

 TYPE="FreeBSD"
-REVISION="15.0"
-BRANCH="STABLE"
+REVISION="15.1"
+BRANCH="PRERELEASE"
 if [ -n "${BRANCH_OVERRIDE}" ]; then
     BRANCH=${BRANCH_OVERRIDE}
 fi

second: running a development build is prone to cause weird situations from time to time because... it's a developer version which contains plenty of debug code (and sometimes unpolished bugs and/or glitches), so running into weird behaviour should be expected.

The code slush for 15.1R started a week ago and should be more stable than usual.