/dev/null was a regular file?

[beavers]

Earlier today I applied a snapshot and rebooted, then postgresql failed to start at boot. Tried starting it manually and it gave me a message about failing to write to /dev/null. So I looked, and:

# ls -AlF /dev/null                                                      
-rw-rw----  1 root  bin  -   2,   2 Jul 23 08:35 /dev/null

(I think it was owned by the bin group, I'm recreating that from memory.) So I figure, oh the world can't write to it, and I `chmod 0666 /dev/null` and fire up postgres again, no trouble. But I think to myself, wait, isn't it supposed to be some kind of device file? So then I:

# rm /dev/null
# cd /dev
# ./MAKEDEV all
# ls -AlF /dev/null
crw-rw-rw-  1 root  wheel  -   2,   2 Jul 23 09:08 /dev/null

Ah, that looks better.

After some reflection I'm a little concerned. Could something nefarious (or quite possibly, something hamfisted I did) have caused /dev/null to become a regular file?

[PapaParrot]

I don't know, but this is short and the way I interpret, it should behave like a regular file:
'man null'

parrot$ man null
NULL(4) Device Drivers Manual NULL(4)

NAME
null - the null device

DESCRIPTION
The null device accepts and reads data as any ordinary (and
willing) file, but throws it away. The length of the null
device is always zero.

FILES
/dev/null

I don't know and can not guess how your first example got that way, the second one looks the same as mine, and I have not changed anything , all though not a recent snpashot, it is a failrly recent fresh install.

parrot$ ls -AlF /dev/null
crw-rw-rw-  1 root  wheel    2,   2 Jul 23 21:08 /dev/null
parrot$

[jggimi]

Another method is to use MAKEDEV std to re-create the correct special file. See MAKEDEV(8).

I cannot tell you how you overlaid the special file.