Re: return to the begin of InputStream
On Wed, 9 Dec 2009, Eric Sosman wrote:
On 12/9/2009 10:49 AM, Tom Anderson wrote:
On Sat, 5 Dec 2009, Eric Sosman wrote:
(Marginally topical) [...]
Also, it's a *very* bad idea to purge /tmp blindly, even if you're
careful only to purge files that haven't been modified in a while. I
recall working with a server application that put files in /tmp and
mmap'ed them to share memory between its multiple processes. Since
simple paging I/O to and from a file opened a week ago doesn't change
the files' modification date, along came the customer's /tmp-purging
cron job and BLOOEY went the server ...
Hang on, the files were open, right? So how could they be deleted? Or is
the point that the directory entries were deleted, so when new processes
were spawned, they couldn't open the file? And since when did writing to
a file via an mmap not change its modification time, anyway?
(The topicality margin gets even thinner)
You're right: An open file can't be deleted. However, its directory
entry is removed. Then, when the application spawns a new process and
that new process tries to share memory with the others by opening and
mmap'ing the now-unfindable file, BLOOEY. (When the customer first
reported trouble, I immediately asked whether there was a cron job or
some such that periodically purged old files from /tmp. Customer
asserted -- vehemently and a bit angrily -- that OF COURSE there wasn't.
So we cobbled together some DTrace to monitor file deletions in /tmp,
and caught the non-existent cron job red-handed ...)
It's at moments like this that i start whistling the Dragnet theme tune.
As for file modification times, I confess an incomplete grasp of
exactly which operations do and do not update them. However, just
poking a new value into a page that's mmap'ed from a file is not enough
to update the time stamp. Can you imagine the overhead if every memory
write trapped to the kernel to update the time?
Right, but the kernel could update the mtime when it flushed pages to
disk. The timestamp would reflect the time of the flush, not the write to
the page, but that's how it is with buffered stream IO too. Or am i
misunderstanding again, and there was no writing to disk happening?
I take it you didn't have SysV shmget/shmat here?
Either way, i'd suggest the bad idea here was putting critical
long-lived files in /tmp. Yes, they're temporary, but not that temporary!
It wasn't my choice. It wasn't even my company's choice.
The third party who wrote the application chose to do things that
way, and even went so far as to include "do_not_delete" as part
of the files' names.
!
My company has a recent and hopefully short-lived tendency to put some
fairly non-temporary things in /tmp - various files created during the
lifetime of an app installation, like search indices, runtime
configuration, etc. It really ought to go in /var or somewhere like that,
but /tmp was the first place that sprang to mind, and since this is so far
just on development machines with fairly short-lived instances, it hasn't
yet gone terribly wrong.
tom
--
Astronomy's a fascinating subject. You look up ... and it's there. --
Patrick Moore