I found the solution to my problem (was suggested in this ml yesterday). /etc/logrotate.d/sogo contained a post-rotate script which tried to restart sogo via its own init-script. This restart made sogo "crash" (well, not really a crash, as it shutdown gracefully, but not the expected outcome of a restart anyhow). I did not find out what causes this problem yet, as manually restarting sogo via init-script works as expected. But removing the post-rotate-part will fix the problem of sogo being offline after a log-rotate occurred. Just posting it here for documentary reasons.
cheers,
Michael
On 11.03.2011 10:34, Michael Noack wrote:
> Thanks for your reply.
>
> Actually it is shutdown 3 hours later, which is strange, because there
> should be no cron-script running at that time. However your comment made
> me check cron.daily again. Apparently a script got auto-generated on
> install there. It contains the following:
>
> #!/bin/sh
> SOGOSPOOL=/var/spool/sogo
> /usr/sbin/tmpreaper 24 "$SOGOSPOOL"
> find "$SOGOSPOOL" -mindepth 1 -type d -empty -exec /bin/rmdir -p {} \;
> 2> /dev/null
>
> As far as I understand that script, it should clear sogos spool of files
> which were not accessed for at least 24 hours. Executing it manually
> does not kill sogo. But on the other hand sogo has not yet run for 24
> hours again. Could sogo-spool not being touched for 24 hours, than
> deleted be the reason for sogos shut-down? How can tmpreaper even affect
> sogo by deleting something in /var/spool/sogo, considering this dir is
> empty?
>
> cheers,
> Michael
>
>
> On 10.03.2011 20:48, Wolfgang Sourdeau wrote:
>> Hi Michael,
>>
>>
>> SOGo will restart after its log files have been rotated (via
>> logrotate). As you can see it's being relaunched right after being
>> shutdown.
>> Your problem is that 3 minutes later it is shut down again. But there
>> is no way for us to know why without looking at your system. It's most
>> likely due to a maintenance script.
>>
>>
>> W.
>>
>
signature.asc
Description: OpenPGP digital signature
