April 2023 - 389-devel - Fedora Mailing-Lists

Please review: Issue 5743 - Disabling replica crashes the server #5746

by Pierre Rogier

https://github.com/389ds/389-ds-base/pull/5746 -- -- 389 Directory Server Development Team

1 month, 1 week

1
0
0 / 0

please review: PR 5745 - fix broken build from slapi_memberof PR

by Mark Reynolds

https://github.com/389ds/389-ds-base/pull/5745 -- Directory Server Development Team

1 month, 1 week

1
0
0 / 0

please review: PR 4739 - UI - Read/write replication monitor info to .dsrc

by Mark Reynolds

https://github.com/389ds/389-ds-base/pull/5739 -- Directory Server Development Team

1 month, 1 week

1
0
0 / 0

389 DS memory growth

by Nazarenko, Alexander

Hello colleagues, On March 22nd we updated the 389-ds-base.x86_64 and 389-ds-base-libs.x86_64 packages on our eight RHEL 7.9 production servers from version 1.3.10.2-17.el7_9 to version 1.3.11.1-1.el7_9. We also updated the kernel from kernel 3.10.0-1160.80.1.el7.x86_64 to kernel-3.10.0-1160.88.1.el7.x86_64 during the same update. Approximately 12 days later, on April 3rd, all the hosts started exhibiting memory growth issues whereby the “slapd” process was using over 90% of the available system memory of 32GB, which was NOT happening for a couple of years prior to applying any of the available package updates on the systems. Two of the eight hosts act as Primaries (formerly referred to as masters), while 6 of the hosts act as read-only replicas. Three of the read-only replicas are used by our authorization system while the other three read-only replicas are used by customer-based applications. Currently we use system controls to restrict the memory usage. My question is whether this is something that other users also experience, and what is the recommended way to stabilize the DS servers in this type of situation? Thanks, - Alex

1 month, 2 weeks

1
0
0 / 0

please review: PR 5724 - RFE - Add server config files to backup

by Mark Reynolds

https://github.com/389ds/389-ds-base/pull/5724 -- Directory Server Development Team

1 month, 3 weeks

1
0
0 / 0

Replication ends suddenly because of csn_time_difference?

by Harald Strack

Hi, we experiencing sudden stops of replication with this message in the logs: [27/Mar/2023:21:01:12.262842335+0200] - WARN - agmt="cn=IP"(xx-sso5:636) - clcache_load_buffer - bulk load cursor(64063f010000006a0000) islower than starting csn 6421e16e0000006a0000. Ending session. The Relevant Code seems to be here https://fossies.org/linux/389-ds-base/ldap/servers/plugins/replication/cl... /* safety checking, we do not want to (re)start replication before 344 * the inital computed starting point 345 */ 346 if (initial_starting_csn) { 347 csn_init_by_string(&limit_csn, initial_starting_csn); 348 if (csn_compare(&limit_csn, buf->buf_current_csn) > 0) { 349 char curr[CSN_STRSIZE]; 350 int loglevel = SLAPI_LOG_REPL; 351 352 if (csn_time_difference(&limit_csn, buf->buf_current_csn) > (24 * 60 * 60)) { 353 /* This is a big jump (more than a day) behind the 354 * initial starting csn. Log a warning before ending 355 * the session 356 */ 357 loglevel = SLAPI_LOG_WARNING; 358 } 359 csn_as_string(buf->buf_current_csn, 0, curr); 360 slapi_log_err(loglevel, buf->buf_agmt_name, 361 "clcache_load_buffer - bulk load cursor (%s) is lower than starting csn %s. Ending session.\n", curr, initial_starting_csn); 362 /* it just end the session with UPDATE_NO_MORE_UPDATES */ 363 rc = CLC_STATE_DONE; 364 } 365 } The loglevel is only set to SLAPI_LOG_WARNING if the replica is more one day (!) behind... However that is not the case, and there is also no time glitch between the servers. Do you have any idea what is causing the problem? br Harald

2 months

2
6
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel April 2023