[Systems] [Fwd: [Systems-logs] Cron <mirrorbrain at sunjammer> ulimit -c unlimited ; mirrorprobe -t 20]

Peter Pöml peter at poeml.de
Thu Sep 30 07:57:12 EDT 2010

Hi Sascha, Bernie,

I can't remember seeing a reply from you on these matters. Can I assume that you could fix the issue? I'd be happy to hear that, and I'd be happy to assist if not.

Best regards,

Le 16.09.2010 à 14:53, Sascha Silbe a écrit :

> Excerpts from Peter Pöml's message of Wed Sep 15 23:46:33 +0200 2010:
>> What are these processes? Could you share the output without "|wc -l"?
> All entries look like this (with "ps aux|grep mirrorbrain"):
> postgres   606  0.0  0.0 106492 13460 ?        Ss   08:16   0:00 postgres: mirrorbrain mirrorbrain idle                                                                     
> The PIDs are rapidly increasing (about 2Hz).
> There's nothing running as user mirrorbrain and no PostgreSQL processes
> running other than those for mirrorbrain and 6 special purpose ones
> (autovacuum, wal writer etc.).
> Nothing useful in /var/log/postgresql/postgresql-8.3-main.log and
> neither in /var/log/syslog.
> Where (or as which user) does mirrorbrain run?
>>>> -------- Forwarded Message --------
>> [...]
>>> I'm getting one of these every 5 minutes. Disabling the cron job until
>>> we fix the issue.
>> What do you get -- the backtrace, shown below, that indicates
>> "connection limit exceeded"?
> Yes.
>> The source is a usage of too many connections (probably about 100, if
>> you use the PostgreSQL defaults). I cannot tell you the reason yet. But
>> if you can provide details, I will understand it and can tell you more.
> Is there anything else you need?
> Thanks for looking into it, BTW!
>> One thing I can already say. For all cron jobs which are run
>> periodically and might not complete within the interval they are
>> scheduled for, it is advantagous to run them under a locking wrapper.
> At least some cron daemons do not run the same job in parallel if it
> takes longer than its frequency. Not sure what Vixie cron does, I would
> have to dive into the source (the documentation doesn't specify
> behaviour in this case).
> However it isn't our problem: The cron job is deactivated and we still
> get the same error (at least in the logs - no idea who/where the client
> is).
> Sascha
> -- 
> http://sascha.silbe.org/
> http://www.infra-silbe.de/

More information about the Systems mailing list