/dev/null behaving strangely

Arthur Chance freebsd at qeng-ho.org
Wed Jun 7 17:58:34 UTC 2017

On 07/06/2017 18:43, Arthur Chance wrote:
> My main fileserver is showing very strange symptoms.
> It's running 10.3-RELEASE-p18, GENERIC kernel, amd64. I can't get a
> uname from it into this mail as this is from another box and neither ssh
> nor scp work to the file server.
> It started about 20 minutes ago when I got mail from cron
> ----
> From: operator at bede.home.qeng-ho.org (Cron Daemon)
> To: operator at bede.home.qeng-ho.org
> Subject: Cron <operator at arthur> /usr/libexec/save-entropy
> Date: Wed, 07 Jun 2017 18:22:00 +0100
> /usr/libexec/save-entropy: cannot create /dev/null: Permission denied
> ----
> This is now happening every 10 minutes as the cron job runs. However,
> running save-entropy from the command line (on the console, or over ssh
> before I rebooted) works without complaint. Since I rebooted I cannot
> ssh or scp to the file server, getting the errors
> arthur at arthur[7]> ssh root at fileserver
> Couldn't open /dev/null: Permission denied
> arthur at arthur[4]> scp fileserver:/tmp/t /tmp/t
> Couldn't open /dev/null: Permission denied

As a follow up, the ssh/scp problem was a completely unrelated screw up
involving /dev on this machine, a bad /devd.conf rule had chowned and
chmoded /dev itself, which wasn't helpful. Fixing that meant I could ssh
into the file server again. Here's the uname -a for the fileserver
(apologies for the line wrap)

root at fileserver:0# uname -a
FreeBSD fileserver.home.qeng-ho.org 10.3-RELEASE-p18 FreeBSD
10.3-RELEASE-p18 #0: Tue Apr 11 10:31:00 UTC 2017
root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

> ls -l /dev/null gives a possibly interesting result: on two other boxes
> I get
> root at arthur:3# ls -l /dev/null
> crw-rw-rw-  1 root  wheel  0x1f  7 Jun 18:05 /dev/null
> but on the file server the device number is 0xd rather than 0x1f (owner,
> group and permissions are identical). I'm not sure if this is
> significant. Rebooting the file server has had no effect on the problem,
> other than cutting off ssh access.
> The system disk is a relatively new SSD and smartctl shows no problems
> with it. devfs mounting on /dev is the default set up, and now jails are
> running to confuse things.
> Any ideas?

An amusing coincidence: log2(58) = 5.858 (to 0.0003% accuracy).

More information about the freebsd-questions mailing list