I'm reluctant to repeat this again but it appeared that under a squeeze version of PPC Linux Linux imac 2.6.32-5-powerpc on a machine that had 512Mb of ram I ran: dd if=/dev/zero of=empty.dat bs=1024M count=66 Then it swelled so that it''s RES become around 900+Mb and I couldn't kill it. I tried by ^C, ^Z on the spawning terminal I tried by kill, kill -9 from another terminal, even as root! The box ran but was extremely slow with 90% iowait times. This appeared to be lasting indefinitely i.e. minutes so the only way I could recover it was to issue a reboot which worked! This surely is a DoS type issue as I only ran it as a normal user. I was just trying to fill up the spare disk space with zero blocks to I could create an easily compressed disk image. Anyway I don't recomend people try to repeat this unless they are happy to reboot to get out of it, it could just be I was unlucky or that PowerPC is vulnerable to this issue. If not I would suggest perhaps reporting it as a vulnerability to be fixed. Thanks in advance for any comments. Andrew
On Sun, Feb 12, 2012 at 01:33:34PM +1100, Andrew Worsley wrote:
I'm reluctant to repeat this again but it appeared that under a squeeze version of PPC Linux Linux imac 2.6.32-5-powerpc on a machine that had 512Mb of ram I ran:
dd if=/dev/zero of=empty.dat bs=1024M count=66
that's 66GB in 1GB chunks, so all sorts of things will go wrong with that on a machine with 512MB of ram.
Then it swelled so that it''s RES become around 900+Mb and I couldn't kill it.
as it should - it should swell to 1024MB. you told it to. this is no different to allocating 1GB of ram on a 512MB machine. it's not something you want to do, nor is it something that the kernel's going to stop you doing, but it's not going to run fast.
I tried by ^C, ^Z on the spawning terminal
when the current 1GB of i/o has made it to disk(*) then the process would have got the signal and died. until then the process is in D state and unkillable whilst the kernel is writing what its been told to write. this is normal. if you want the dd to be killable in less time than it takes to write 512MB (all your ram) of buffered i/o to disk, then use direct i/o. eg. bs=10M oflag=direct cheers, robin (*) will take a long time if your machine's swap partition is on the same disk as the disk you are writing to.
On Sun, Feb 12, 2012 at 01:33:34PM +1100, Andrew Worsley wrote:
I'm reluctant to repeat this again but it appeared that under a squeeze version of PPC Linux Linux imac 2.6.32-5-powerpc on a machine that had 512Mb of ram I ran:
dd if=/dev/zero of=empty.dat bs=1024M count=66
that's 66GB in 1GB chunks, so all sorts of things will go wrong with that on a machine with 512MB of ram.
Then it swelled so that it''s RES become around 900+Mb and I couldn't kill it.
as it should - it should swell to 1024MB. you told it to.
this is no different to allocating 1GB of ram on a 512MB machine. it's not something you want to do, nor is it something that the kernel's going to stop you doing, but it's not going to run fast.
I tried by ^C, ^Z on the spawning terminal
when the current 1GB of i/o has made it to disk(*) then the process would have got the signal and died. until then the process is in D state and unkillable whilst the kernel is writing what its been told to write. this is normal.
if you want the dd to be killable in less time than it takes to write 512MB (all your ram) of buffered i/o to disk, then use direct i/o. eg. bs=10M oflag=direct
(part of) The OP's point was that an ordinary user can do this which bogs the system right down for everyone else... I assume appropriate use of ulimit would take care of this. James
James Harper <james.harper@bendigoit.com.au> wrote:
(part of) The OP's point was that an ordinary user can do this which bogs the system right down for everyone else... I assume appropriate use of ulimit would take care of this.
Under Debian, the right place to set this appears to be /etc/security/limits.conf
On Sunday 12 February 2012 13:33:34 Andrew Worsley wrote:
Linux imac 2.6.32-5-powerpc
That's a very old kernel (December 2009), have you replicated it on a current kernel to see if it's been addressed in the 2 years since? It sounds a little like you might have run into an issue with the OOM killer, you may want to run your system without overcommit enabled, I have in /etc/sysctl.conf on most systems I run: # Stop OOM'ing vm.overcommit_memory = 2 vm.overcommit_ratio = 99 cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP
participants (5)
-
Andrew Worsley -
Chris Samuel -
James Harper -
Jason White -
Robin Humble