linux-kernel - ZenIV (was: Re: Status of arm-soc.git for 3.2)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120104181703.GA11810@n2100.arm.linux.org.uk>
Date:	Wed, 4 Jan 2012 18:17:03 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Olof Johansson <olof@...om.net>, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Nicolas Pitre <nico@...xnic.net>
Subject: ZenIV (was: Re: Status of arm-soc.git for 3.2)

On Wed, Jan 04, 2012 at 10:00:16AM +0000, Russell King - ARM Linux wrote:
> Now... as for ZenIV (the machine which publically hosts my git tree).  It's
> developed a new problem over Christmas: apache has started regularly dying
> in a way that's not been seen before:
> [alert] (11)Resource temporarily unavailable: setuid: unable to change to uid: xx
> [error] server reached MaxClients setting, consider raising the MaxClients setting
> [alert] Child 17666 returned a Fatal error... Apache is exiting!
> [emerg] (43)Identifier removed: couldn't grab the accept mutex
> [emerg] (22)Invalid argument: couldn't grab the accept mutex
> ...
> I don't see any updates which would have caused this, so I'm going to put
> it down to increased server load over the Christmas period, possibly again
> caused by git's smart protocol being excessively resource intensive on the
> machine.

I've just checked the machine this evening - I restarted it at 8:57 and
it was dead again by 16:52.

I've now disabled all access to my git tree there, and restarted apache.
We will see whether that improves stability - I suspect it will do because
I reckon that the problem is that the smart git stuff is what's killing
the machine.  I've no idea how the kernel.org folk manage to run any
kind of service with this git stuff.

If that resolves the problem, I'll re-enable access but with the "smart"
stuff and gitweb disabled (I've seen gitweb taking ages accessing the
tree as well.)

I'm now convinced that git servers are only possible with 64-bit systems
with some multiple of 16GB of RAM on them - which is not something that
this machine can be.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/