Kolab Hanging after 24 hours and 389 directory server not starting

[Lebmann, Paul]

Am 2015-10-21 23:43, schrieb Andy Kopciuch:
> On Wednesday October 21 2015 22:21:16 Peter Jennings wrote:
>> Andy
>> 
>> I ran the following:
>> 
>> root at mail:~# systemctl unmask dirsrv.service
>> root at mail:~# systemctl start dirsrv.service
>> Failed to start dirsrv.service: Unit dirsrv.service is masked.
>> root at mail:~#
>> 
>> then i ran
>> 
>> root at mail:~# systemctl mask dirsrv.service
>> Created symlink from /etc/systemd/system/dirsrv.service to /dev/null.
>> root at mail:~# systemctl unmask dirsrv.service
>> Removed symlink /etc/systemd/system/dirsrv.service.
>> root at mail:~# systemctl start dirsrv.service
>> Failed to start dirsrv.service: Unit dirsrv.service is masked.
>> root at mail:~#
>> 
>> the same thing happens.
>> 
> 
>> From reading online ... last wild stab in the dark ... maybe manually 
>> symlink
> the service file :
> 
> ln -sf /usr/lib/systemd/system/dirsrv.service 
> /etc/systemd/system/multi-
> user.target.wants/
> 
> (paths might need altering?) ... I'm not sure ... I just copied and 
> pasted,
> changed the service name.
> 
> If that doesn't work ... then you'll need to file a bug report with 
> debian
> directly.   Maybe the sysytemd unmask is not working properly?   I 
> can't
> really say.
> 
> Re-install / restore from backup, which I assume you are trying to 
> avoid.
> 
> 
> Andy

Hi

On my Debian Jessie / Kolab 3.4 installation I have a quite similar 
behavior.

dirsrv-admin.service  loaded active exited
dirsrv-snmp.service   loaded failed failed
dirsrv at admin.service  loaded failed failed
dirsrv at kolab.service  loaded active running

and:
dirsrv-snmp.service   enabled
dirsrv.service        masked
dirsrv at .service       enabled
dirsrv.target         enabled

since my installation works I stopped poking around the not running 
dirsrv services. I guess Kolab uses for its configuration 
dirsrv at kolab.service and therefore it works.
Do you have a similar service available?
Maybe it is your "dirsrv at mail.service" service.
Did you check if something is listening on the ldap port?
I guess it'd make sense, if it is not possible to start dirsrv if some 
other instance of dirsrv is already listening on port 389.

Concerning your other problem: I had it to, and the logrotate solution 
you were already told did it for me.

I don't think reinstallation / restoring is the way to go. When I tried 
to reproduce a problem with sieve on a VM I did get the same behavior of 
dirsrv.service. So the situation is reproduceable with the OS / Kolab 
combination. I'm just not sure if it is an error since Kolab works 
flawlessly for me and something is running on Port 389 and acts as the 
ldap server for Kolab

regards

Paul