From 8b3f4ca6d3c28262ece7079eb77968be445f3cab Mon Sep 17 00:00:00 2001 From: William Brown Date: May 19 2020 00:28:17 +0000 Subject: Ticket 50989 - ignore pid when it is ourself in protect_db Bug Description: In protect_db.c, there are some cases (especially containers) where a pid number can be re-used. Following a bad shutdown, the lock files in /run/lock/{export,import,server}/* remain, and the pid they hold could be allocated to ourself. When this occurs, the server fails to start. Fix Description: If the pid of the lock file is our own pid, that is proof that the previous pid/lock file can not exist, and therfore it is safe to proceed with the startup. https://pagure.io/389-ds-base/issue/50989 Author: William Brown Review by: tbordaz (Thanks!) --- diff --git a/ldap/servers/slapd/protect_db.c b/ldap/servers/slapd/protect_db.c index ccde08b..c4d50d8 100644 --- a/ldap/servers/slapd/protect_db.c +++ b/ldap/servers/slapd/protect_db.c @@ -251,7 +251,19 @@ sample_and_update(char *dir_name) * didn't put it there */ continue; } - if (is_process_up(pid)) { + if (pid == getpid()) { + /* + * We have re-used our pid number, and we are now checking for ourself! + * + * pagure: https://pagure.io/389-ds-base/issue/50989 + * + * This situation is common in containers, where the process name space means we + * may be checking ourself, and have low pids that get re-used. Worse, we cant + * actually check the pid of any other instance in a different container. + * So at the very least in THIS case, we ignore it, since we are the pid + * that has the lock, and it's probably a left over from a bad startup. + */ + } else if (is_process_up(pid)) { result = (long)pid; } else { PR_snprintf(file_name, MAXPATHLEN, "%s/%s", dir_name, entry->name);