Improve multi-platform detection of simultaneous ghe-backup runs#435
Conversation
snh
left a comment
snh
left a comment
There was a problem hiding this comment.
For reference, we removed the use of -o to obtain the full command with arguments in #341 for portability reasons. This latest issue appears to be an unintended consequence due to another portability issue that was introduced as a result of #341.
I think the approach @taz is recommending is the safest from a portability point of view, and while there may be a small chance of false positives, this is countered by the fact this will result in less false negatives.
lildude
left a comment
lildude
left a comment
There was a problem hiding this comment.
Seems like the best approach to take to stop chasing variations of ps output without going into the realms of trying to handle all scenarios. LGTM.
|
Just realised, this also addresses https://github.com/github/backup-utils/issues/184 |
…s-translog-setting Backport 378 for 3.8: Replace deprecated translog flush setting in ES
3 participants
This change corrects an issue where the PID provided by the
in-progressfile isn't correctly identified on Ubuntu systems. Theps -p PIDcommand returnsbashinstead ofghe-backup, which results in the subsequentgrepnot returning a match.After this change
ghe-backupwill stop if any process is found on the reported PID. As this could (rarely) result in false matches, a message has been added to warn the admin and recommend they examine the PID to see if it is indeed related and if not, remove the stalein-progressfile.False positives here should only occur if the
in-progressfile is left behind for some reason, and another process starts on the same PID thatghe-backupused in its previous run.The message is similar to the one presented when a legacy
in-progresssymlink is detected./cc @github/backup-utils for review.