General discussion on installation and configuration of SOGo

Text archives Help

Re: [SOGo] cron errors

Chronological Thread 
  • From: Fabrice Rossi < >
  • To:
  • Subject: Re: [SOGo] cron errors
  • Date: Sun, 21 Dec 2014 20:56:54 +0100

Hi Christian,

Le 21/12/2014 14:13, Christian Rößner a écrit :
> I get many mails like these:
> 2014-12-20 19:08:01.348 sogo-tool[18222] Failed to create lock
> directory '/home/sogo/GNUstep/Defaults/.lck/.GNUstepDefaults.lck‘ -
> 2014-12-20 17:40:01.575 sogo-tool[16782] Failed to create lock
> directory '/home/sogo/GNUstep/Defaults/.lck/.GNUstepDefaults.lck' -
> /home/sogo/GNUstep/Defaults/.lck/.GNUstepDefaults.lck

Me too (see

> Why does the cron.d/sogo task produce such messages? And what can I
> do to fix this issue? I don’t want to add >/dev/null 2>&1 ;-)

As far as I know, this is a load problem. If I get it correctly, the
standard GNUstep library is using a classical directory based locking
pattern. As mkdir is atomic in many systems, it can be used by a process
to acquire a look on something. The library is using some kind of back
off strategy when it cannot acquire the lock (i.e. create the
directory). On a loaded system, this can prove complicated and thus lead
to the messages your are observing. All of this is educated guess as I
don't understand Ojective C enough to read the sources and verify my claims.

I did fix the problem by replacing the two concurrent calls to
sogo-ealarms-notify and usr/sbin/sogo-tool expire-sessions in the cron
by a single sequence. That is, I use:

* * * * * sogo /usr/sbin/sogo-ealarms-notify &&
/usr/sbin/sogo-tool expire-sessions 60

This has removed the locking problem, even under heavy load.

Hope that helps.

Best regards,


  • [SOGo] cron errors, Christian Rößner, 12/21/2014
    • Re: [SOGo] cron errors, Fabrice Rossi, 12/21/2014

Archive powered by MHonArc 2.6.18.

Top of page