We have a customer that runs several Postgres instances on the same repmgr-managed host. For security reasons, each service runs under its own username.
This leads to issues during repmgr node rejoin, as this command redirects output into a /tmp/node-rejoin.$TIMESTAMP file (where $TIMESTAMP are the seconds since the Unix epoch), so if two repmgr node rejoin commands are issued in the same second, the later one will fail as it cannot write into the logfile from the other process (umask being 0022, i.e. -rw-r--r--).
I guess there are two things that coiuld be done here: either add milliseconds (or microseconds?) to the timestamp to close down the race window considerably (making the logfile name longer) or maybe check whether repmgr can write to the file from node_rejoin_log and if not, re-try after a short timeout, before running the command itself.
We have a customer that runs several Postgres instances on the same repmgr-managed host. For security reasons, each service runs under its own username.
This leads to issues during
repmgr node rejoin, as this command redirects output into a/tmp/node-rejoin.$TIMESTAMPfile (where$TIMESTAMPare the seconds since the Unix epoch), so if tworepmgr node rejoincommands are issued in the same second, the later one will fail as it cannot write into the logfile from the other process (umaskbeing 0022, i.e.-rw-r--r--).I guess there are two things that coiuld be done here: either add milliseconds (or microseconds?) to the timestamp to close down the race window considerably (making the logfile name longer) or maybe check whether
repmgrcan write to the file fromnode_rejoin_logand if not, re-try after a short timeout, before running the command itself.