Representative request.



  • Representative service request:

    On the new configured machine, /dev/null2 is not available. please create it.

    why does anyone need an additional null device?!!



  • Not an additional device. Someone made a typo, and now the soul tasked with deploying or debugging why it doesn't work as intended wants the device to exist..


  • Discourse touched me in a no-no place

    I hope that's true.

    Alternatively, there's software that will need two filenames passing in where those actually need to be null devices, but where the software behaves differently if the filenames are the same. Which would be a WTF.



  • Fixed?
    ln -s /dev/sda /dev/null2



  • maybe, somewhere in the past...
    However, on the "reference machine", I find this:

    XXXX1[XXXX]:/dev > ls -l | grep nul
    lrwxrwxr-x   1 root       sys              9 Jul  4 17:02 dtremote -> /dev/null
    crw-rw-rw-   1 bin        bin          3 0x000002 Aug 29 13:23 null
    crw-rw-rw-   1 root       sys          3 0x000003 Aug 29 13:23 null2
    crw-rw-rw-   1 root       root        72 0x000043 Jul 12 02:30 nuls


  • Oh boy... 😨
    Any chance it is a HP-UX machine?

    (Altough in the intertubes, null2 is a regular file, not a char device)


  • Discourse touched me in a no-no place

    @profke said:

    why does anyone need an additional null device?!!

    Because the first bit-bucket is full?


    Filed under ln -sf /dev/full /dev/null


  • Discourse touched me in a no-no place

    I'm reminded of one version of an ASP implementation for Apache running on Unix that I heard about years ago. It apparently managed to end up replacing the /dev/null device with an ordinary file, with “great fun” ensuing.


  • BINNED

    The evil ideas thread is ▶ ⬅ 🔄 over there.



  • An earnest, if someone inexperienced hell-desk drone from the other side of the world once thought that he would take some personal initiative in cleaning up a filesystem which was nearing 100% full.

    The next morning, while cleaning up the mess, I found a rather clever new method of removing files in root's .history:

    mv application-log-file /dev/null

    He apparently realized his mistake shortly after that because he tried to fix it:

    mv /dev/null application-log-file

    Strangely, that didn't do much to fix the problem, and the next process to write to /dev/null recreated it as a regular file. Fortunately someone whose experience with UNIX systems consisted of more that just watching Jurassic Park was able to mknod the problem away before the system crashed completely, and I spent the rest of the morning quietly addressing the flaws in our security policy which had allowed this to happen in the first place.



  • You should really consider using a cloud-based null service, like DAAS. If you run the numbers on how much you spend maintaining and upgrading your local /dev/null(s), you will almost certainly save money.



  • I don't trust the security of third-party null servers. I prefer to have a single server dedicated to a RFC863 daemon.



  • @DCRoss said:

    An earnest, if someone inexperienced hell-desk drone from the other side of the world once thought that he would take some personal initiative in cleaning up a filesystem which was nearing 100% full.

    The next morning, while cleaning up the mess, I found a rather clever new method of removing files in root's .history:

    mv application-log-file /dev/null

    He apparently realized his mistake shortly after that because he tried to fix it:

    mv /dev/null application-log-file

    Strangely, that didn't do much to fix the problem, and the next process to write to /dev/null recreated it as a regular file. Fortunately someone whose experience with UNIX systems consisted of more that just watching Jurassic Park was able to mknod the problem away before the system crashed completely, and I spent the rest of the morning quietly addressing the flaws in our security policy which had allowed this to happen in the first place.

    Sheesh. Not only moving a file to /dev/null (which I presume overwrites it), but then moving it back from /dev/null (which moves the file back, leaving a void where the bit bucket once was)?! Talk about someone in need of vigorous LART application!

    Also...I wonder why a system with a regular file for /dev/null would blow up? Wouldn't it just happily stuff data into that file, oblivious to the fact that the data's being written to disk? Or was / the FS that was filling up?


  • Discourse touched me in a no-no place

    @tarunik said:

    Also...I wonder why a system with a regular file for /dev/null would blow up? Wouldn't it just happily stuff data into that file, oblivious to the fact that the data's being written to disk? Or was / the FS that was filling up?

    Lots of things write to /dev/null. Really lots. Also, many things mmap() it as a source of zero pages. Losing it wreaks several different sorts of havoc at once. (It's also quite possible that it had ended up with permissions such that only root could open it; that'd happen very easily given that everything was up shit creek anyway.)

    As I said, “Fun!”



  • True story:

    Once upon a mail server, a long and complicated script began, as scripts are wont to do:

    LOGFILE=/var/log/something
    

    Fast forward in time. $LOGFILE got large, was deemed useless. $COW_ORKER replaced the line with

    LOGFILE=/dev/null
    

    without noticing that in some rare conditions (IIRC midnight on first day of month) the script would

    rm -f $LOGFILE
    

    Long before /dev use crossed a warning threshold, postfix stopped delivering mail. Nocturnal hilarity ensued. If we'd had a /dev/null2 we'd have used it immediately!


  • Discourse touched me in a no-no place

    @DCRoss said:

    Fortunately someone whose experience with UNIX systems consisted of more that just watching Jurassic Park

    You almost owed me a new keyboard...



  • @dkf said:

    Lots of things write to /dev/null. Really lots.

    Not many append to it, though.

    @dkf said:

    Also, many things mmap() it as a source of zero pages.

    If it's a real file and quite short, I can see that breaking horribly.


  • Discourse touched me in a no-no place

    @flabdablet said:

    If it's a real file and quite short, I can see that breaking horribly.

    Perhaps he meant /dev/zero?


  • Discourse touched me in a no-no place

    @PJH said:

    Perhaps he meant /dev/zero?

    Fun fact: both /dev/null and /dev/zero behave the same when you mmap() them. Which one people actually use… you gotta read their source…



  • @tarunik said:

    Or was / the FS that was filling up?

    On recent Linux distributions /dev/ is on a tmpfs so writing into it will consume the available RAM and swap.


Log in to reply