bas wrote:
> This is a basic UNIX question. Every once in a while I fill /tmp and
> my fBSD machine freezes -- like it has just now. I thought the whole
> point of having separate partitions was to prevent this. I can't stop
> the responsible process (ImageMagic), or even shell in from my laptop
> to do a clean restart -- nada. I know I can set TMPDIR to a directory
> in a larger partition, and take other measures to prevent filling /tmp.
> My questions are simply (1) why filling a non-root partition freezes
> the machine; and (2) whether I was mistaken to believe that making
> separate partitions was supposed to prevent such freezes.

1. I can't recall filling /tmp locking up a machine, although I don't
think I've filled /tmp on FreeBSD 6.x, either.

2. Don't think so. Putting /tmp on a separate partition is more likely
to make it easier to clear. It would also help avoid damage in
emergencies, keeping temporary files separate from real data.

--
Warren Block * Rapid City, South Dakota * USA

Warren Block wrote:
> 1. I can't recall filling /tmp locking up a machine, although I don't
> think I've filled /tmp on FreeBSD 6.x, either.

This machine is 6.2-prerelease, but I'm pretty sure I've had this
experience going back to the 4.x days. I remember because it took me a
while to figure out that ImageMagic was filling /tmp and I had to set
TMPDIR to somewhere else.

>
> 2. Don't think so. Putting /tmp on a separate partition is more likely
> to make it easier to clear. It would also help avoid damage in
> emergencies, keeping temporary files separate from real data.

So the point is easier recovery rather than preventing a freeze?
That's a good reason too, of course.

>
> --
> Warren Block * Rapid City, South Dakota * USA

On 2007-01-03, bas wrote:
> Warren Block wrote:
>> 1. I can't recall filling /tmp locking up a machine, although I don't
>> think I've filled /tmp on FreeBSD 6.x, either.
>
> This machine is 6.2-prerelease, but I'm pretty sure I've had this
> experience going back to the 4.x days. I remember because it took me a
> while to figure out that ImageMagic was filling /tmp and I had to set
> TMPDIR to somewhere else.

It's definitely incorrect behaviour, so you should look into it further.

Kris

Kris Kennaway wrote:
> On 2007-01-03, bas wrote:
> > Warren Block wrote:
> >> 1. I can't recall filling /tmp locking up a machine, although I don't
> >> think I've filled /tmp on FreeBSD 6.x, either.
> >
> > This machine is 6.2-prerelease, but I'm pretty sure I've had this
> > experience going back to the 4.x days. I remember because it took me a
> > while to figure out that ImageMagic was filling /tmp and I had to set
> > TMPDIR to somewhere else.
>
> It's definitely incorrect behaviour, so you should look into it further.
>
> Kris

Google shows that it is a common bug on several operating systems:
http://www.imagemagick.org/pipermail...ay/001305.html
I have certainly seen it mentioned for FreeBSD previously.

--

Michel TALON

Michel Talon wrote:
>
> Google shows that it is a common bug on several operating systems:
> http://www.imagemagick.org/pipermail...ay/001305.html
> I have certainly seen it mentioned for FreeBSD previously.

Oh, it didn't occur to me to search for a way that a bug in an
application could freeze the OS. That's interesting, thanks.

On 2007-01-05, Michel Talon wrote:
> Kris Kennaway wrote:
>> On 2007-01-03, bas wrote:
>> > Warren Block wrote:
>> >> 1. I can't recall filling /tmp locking up a machine, although I don't
>> >> think I've filled /tmp on FreeBSD 6.x, either.
>> >
>> > This machine is 6.2-prerelease, but I'm pretty sure I've had this
>> > experience going back to the 4.x days. I remember because it took me a
>> > while to figure out that ImageMagic was filling /tmp and I had to set
>> > TMPDIR to somewhere else.
>>
>> It's definitely incorrect behaviour, so you should look into it further.
>>
>> Kris
>
> Google shows that it is a common bug on several operating systems:
> http://www.imagemagick.org/pipermail...ay/001305.html
> I have certainly seen it mentioned for FreeBSD previously.

OK, but I guess no-one ever bothered to gather the required debugging
information to proceed (process backtraces, lock status,
etc)...perhaps the OP will do so.

Kris

Kris Kennaway wrote:
>
> OK, but I guess no-one ever bothered to gather the required debugging
> information to proceed (process backtraces, lock status,
> etc)...perhaps the OP will do so.

I suspect that it is simply that imagemagic continually spams the OS for
writing in /tmp, while the OS continually spams syslog to log that
filesystem is full. Both succeed pretty well in monopolizing all the
machine resources.

>
> Kris

Kris Kennaway wrote:
> OK, but I guess no-one ever bothered to gather the required debugging
> information to proceed (process backtraces, lock status,
> etc)...perhaps the OP will do so.
>
Will give it a shot next weekend. I suppose I start with the handbook,
chp 11?

On 2007-01-08, Michel Talon wrote:
> Kris Kennaway wrote:
>>
>> OK, but I guess no-one ever bothered to gather the required debugging
>> information to proceed (process backtraces, lock status,
>> etc)...perhaps the OP will do so.
>
> I suspect that it is simply that imagemagic continually spams the OS for
> writing in /tmp, while the OS continually spams syslog to log that
> filesystem is full. Both succeed pretty well in monopolizing all the
> machine resources.

Yeah, it could be something like that. There is code to coalesce
repeated identical syslog messages, but that can be defeated if
e.g. they are alternating between different processes.

Kris