There's a known behavior in gentoo where /dev/null sometimes becomes a file. I set up a logger to note the status of /dev/null every 60 seconds, and lined the change up with the emerge of procps via genlop -l. Manually unpacking distfiles/procps-3.2.4.tar.gz and doing the make step repeats the behavior. This is likely an upstream bug, but I figure I'll file it here to get verification. Reproducible: Always Steps to Reproduce: 1.rm /dev/null; mknod /dev/null c 1 3; chmod 644 /dev/null 2.emerge =sys-apps/procps-3.2.4-r2 3.ls -l /dev/null == or 1. mkdir /var/tmp/work 2. tar zxvf /usr/portage/distfiles/procps-3.2.4 3. rm /dev/null; mknod /dev/null c 1 3; chmod 644 /dev/null 4. make 5. ls -l /dev/null Actual Results: Build finishes, /dev/null becomes a file in both examples, with permissions 644, 0 bytes in size. Expected Results: leave /dev/null as a device file, char, major 1, minor 3, perm 666. My system is a MIPS system. However, this is apparently a known behavior that is as-yet untraced. I verified with #gentoo-hppa that it did occur during an upmerge of procps on one person's system. Previously this may have been blamed on udev. However, I've seen this behavior before I started using udev. Procps otherwise operates properly as far as I can tell. There's a statement in the Makefile (grep /dev/null Makefile) that changes perms on /dev/null to 777 previous to its becoming a file by using gcc dummy.c -o /dev/null. This may be 'broken' behavior as well, but I'm unsure if it's on gcc's behalf. Last, as it occurs during the make (not make install) process of the vanilla sourceball from distfiles/, I suspect it's an upstream bug, and would affect most if not all architectures supported by gentoo-linux. Classifying it as major, as it changes a device node into a file.
Uh, I mean 666 /dev/null in my chmod's :-X
procps isnt the real issue ... it just comes up with it because it runs something like `gcc -o /dev/null` when testing compiler flags our toolchain is the real problem ... here's a way to test: $ echo "int main() { return(0); }" > test.c $ gcc -o /dev/null test.c you will either get an ugly error message and lose /dev/null, or you'll get no output
vapier: I can't reproduce that on x86_64 + devfsd or i686 + udev.
i know, but i can easily reproduce on my hppa / mips boxes
ok, solar grabbed a patch from mainline to fix binutils' ld which is now part of binutils-2.15.92.0.2-r8 ... so that fixed ld from eating /dev/null however, gcc's collect2 would still unlink the output file, so i wrote a small patch based upon the binutils one: http://viewcvs.gentoo.org/src/patchsets/gcc/3.4.3.20050110/gentoo/00_all_gcc_unlink_if_ordinary.patch?root=gentoo tested on my hppa and it no longer unlink's /dev/null ... so i'm adding this patch to our gcc-3.3.5.2005xxxx and our gcc-3.4.3.2005xxxx
