From owner-freebsd-questions@FreeBSD.ORG Sat Aug 25 05:56:59 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 67DFD16A41B; Sat, 25 Aug 2007 05:56:59 +0000 (UTC) Date: Sat, 25 Aug 2007 05:56:59 +0000 From: Kris Kennaway To: Norberto Meijome Message-ID: <20070825055659.GA42274@hub.freebsd.org> References: <46CEA517.8030204@passagen.se> <20070824202650.0a1bffd6@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070824202650.0a1bffd6@localhost> User-Agent: Mutt/1.4.2.1i Cc: User Questions , Roger Olofsson Subject: Re: FreeBSD and ImageMagick crashes OS? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2007 05:56:59 -0000 On Fri, Aug 24, 2007 at 08:26:50PM +1000, Norberto Meijome wrote: > On Fri, 24 Aug 2007 11:29:59 +0200 > Roger Olofsson wrote: > > > Turns out ImageMagick was called through php to resize the .JPG and most > > likely, the server runs out of memory/disk space. /var/tmp fills up and > > console spews as follows: > > > > Aug 22 19:29:49 rutilus kernel: vnode_pager_putpages: I/O error 28 > > Aug 22 19:29:49 rutilus kernel: vnode_pager_putpages: residual I/O 32768 > > at 62620 > > Aug 22 19:29:49 rutilus kernel: pid 29 (syncer), uid 0 inumber 49382 on > > /var: filesystem full > > :) having been bitten by that in several unix-like OS (pick any Linux distro, and freebsd too), i just remove /var/tmp and make a smylink to /tmp , which is big enough for my foreseeable needs. I like to keep my /var clean of tmp rubbish. > > and yes, configuring PHP and it's libraries helps too :) That's not an answer obviously. Error 28 is #define ENOSPC 28 /* No space left on device */ This seems like a bug to me: when a filesystem fills you shouldn't be getting this behaviour. Can you please follow the directions in the developers handbook chapter on kernel debugging, and when you trigger a hang, break to DDB from the console and force a dump, then file a PR and make the core file available to the developers. Unfortunately unless a developer can replicate the behaviour, providing access to a core is the only real debugging option. Thanks, Kris