fill /tmp and freeze - BSD

This is a discussion on fill /tmp and freeze - BSD ; 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 ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: fill /tmp and freeze

  1. fill /tmp and freeze

    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.


  2. Re: fill /tmp and freeze

    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

  3. Re: fill /tmp and freeze

    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



  4. Re: fill /tmp and freeze

    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

  5. Re: fill /tmp and freeze

    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


  6. Re: fill /tmp and freeze

    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.


  7. Re: fill /tmp and freeze

    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

  8. Re: fill /tmp and freeze

    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


  9. Re: fill /tmp and freeze


    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?


  10. Re: fill /tmp and freeze

    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

+ Reply to Thread