Tasmanian Devil wrote:
> Has anybody an idea what I could do to find the cause of this
> "disappearing /dev/null"? Thank you in advance for your help!
Well, it doesn't disappear so much as having its permissions altered,
but I'm certain you are aware of that.
Are you sure it's OpenSSH? What other daemons are using to /dev/null
(fstat?)? It would make sense if some daemon thought it was a logfile or
somesuch and decided to 'secure' it...
Hm, fstat doesn't show much unusual, mainly httpd and mysql besides
the standard daemons. I have the same combination of daemons running
on older machines (GENERIC 4.0 -stable without ACPI though), but no
problem there.
The permissions of /dev/null change directly after (or maybe even
while) using SFTP, and not always.
It's not just permissions, it's no longer a character special (device)
file, it's a regular file. This usually happens when /dev/null is
deleted, and sooner or later something with root perms will write to it,
at which point it gets recreated as a regular file.
Sometimes I can log in several
times over a few hours without fixing /dev/null, and then again only
one single time. E.g. right now I can't reproduce the error. And if I
don't use SCP/SFTP at all, everything works fine, for weeks, so it
seems to be related to SCP/SFTP.
During that time, is /dev/null still a character special, or has it
turned into a regular file?
I suspect that something else (maybe a cron job?) is removing /dev/null
and the scp/sftp error is just a symptom.
You could try something like this running from cron regularly:
test -c /dev/null || echo /dev/null vanished or not character special
and see if/when it starts mailing you.
Probably it's only happening after
using SFTP (and SCP doesn't work afterwards), but unfortunately I'm
not sure as I don't transfer files that often.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
