Monday, April 26, 2021

[389-users] Re: dsctl healthcheck bug - or bad at least a bad resolution

Something to note, as I just triggered this bug on a replica I built
today, this is a new bug.

I have 2 pretty much identical consumer only replicas. The bug triggers
56 times on the new one and not the old one. The replica is a consumer
only, and not a hub. Same ldif file (for db and suffix) to make like 9
of these boxes, this health check happens only on the new ones.

Old box version:
389-ds-base python3-lib389 389-ds-base-libs

New box version:

Trying to downgrade the box.. bah cant start 389 after the downgrade
lol. Rebuilding. downgrade (dont see any in between version from to .. Ok and downgrading helped! the dsctl healthcheck works!

Hope this helps,


On 4/15/21 2:39 PM, Mark Reynolds wrote:
> On 4/15/21 4:23 PM, Gary Waters wrote:
>>> These entries look fine.  I'm assuming you are running this on a hub
>>> or consumer, is that correct? Does it work correctly on the supplier
>>> replica?  I think the "nsslapd-state=referral on update" might be
>>> tripping up the healthcheck.
>> Yes I am using this as a hub. The same ldif I use to make the suffix
>> I use to make the suppliers and consumers, and they work fine (and
>> dsctl healthcheck says they are ok).  The setting of nsslapd-state
>> was set by the dsconf command I sent before. I checked a production
>> hub I have (which this one will eventually replace), and that is the
>> correct setting.
>> Perhaps this is an issue with dsctl's healthcheck then.
> There is definitely a bug, I was just trying to narrow it down. I'll
> try and look into this tomorrow...
>> -Gary
389-users mailing list --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines:
List Archives:
Do not reply to spam on the list, report it:

No comments:

Post a Comment