Actually, it seems to be happening every time the instance is restarted.
Just had it happen again:
----------. 1 nobody nobody 2960 Sep 5 09:19 errors
We have a 389DS instance that has started having a strange problem
when it
runs its backups -
[04/Sep/2014:01:05:01 -0500] - Backup finished.
[04/Sep/2014:05:55:01 -0500] - chown_dir_files: file
(/var/log/dirsrv/slapd-vadc-ldap2-prod/errors) chown failed (13)
Permission denied.
[04/Sep/2014:05:55:01 -0500] - chown_dir_files: file
(/var/log/dirsrv/slapd-vadc-ldap2-prod/errors.20140820-144326) chown
failed (13) Permission denied.
[04/Sep/2014:05:55:01 -0500] - chown_dir_files: file
(/var/log/dirsrv/slapd-vadc-ldap2-prod/errors) chown failed (13)
Permission denied.
[04/Sep/2014:05:55:01 -0500] - chown_dir_files: file
(/var/log/dirsrv/slapd-vadc-ldap2-prod/errors.20140820-144326) chown
failed (13) Permission denied.
[04/Sep/2014:05:55:01 -0500] - chown_dir_files: file
(/var/log/dirsrv/slapd-vadc-ldap2-prod/errors) chown failed (13)
Permission denied.
[04/Sep/2014:05:55:01 -0500] - chown_dir_files: file
(/var/log/dirsrv/slapd-vadc-ldap2-prod/errors.20140820-144326) chown
failed (13) Permission denied.
This is coming from the db2bak.pl backup script. Somehow our log files
are ending up with permissions --------- and then since they can't be
written to the instance crashes.
The only thing that has changed recently on this instance is that we
configured secure replication back to another server (it was already
receiving replication traffic from that server, so now they are able to
replicate back and forth to each other).
We are running
389-ds-base-1.2.11.25-1.el6.x86_64
on
2.6.39-300.26.1.el6uek.x86_64
any suggestions on why this instance has started behaving this way would
be appreciated.
thanks -
EJ
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users