Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auter Pre & Post Snapshot conflict (with timestamps) #237

Open
solo786 opened this issue Jul 22, 2020 · 3 comments
Open

Auter Pre & Post Snapshot conflict (with timestamps) #237

solo786 opened this issue Jul 22, 2020 · 3 comments

Comments

@solo786
Copy link

solo786 commented Jul 22, 2020

BUG:

Auter is configured to run and apply updates before midnight say at 11:30pm on 20th July 1997 , it creates its .pre snapshot files before midnight passes and auter is then instructed to post midnight reboot (18th July 1997), on reboot the .post snapshot fails and is unable to run since its looking for the same timestamp .pre entries ( from the previous day) to check against which it believes does not exist.becuase a new day has already come into effect.

@solo786 solo786 changed the title Auter Pre & Post Snapshot conflict Auter Pre & Post Snapshot conflict (with timestamps) Jul 22, 2020
@solo786
Copy link
Author

solo786 commented Jul 22, 2020

closing this off moving it to auter manager.

@solo786 solo786 closed this as completed Jul 22, 2020
@mark-hyde mark-hyde reopened this Apr 5, 2023
@mark-hyde
Copy link
Contributor

I think this belongs here rather than auter-manager so I'll re-open it and we'll have a look at the issue when we have the opportunity.

@mark-hyde
Copy link
Contributor

I think that this is related to the contrib/configsnap scripts rather than the main auter script.

In the README.md for that contrib it says:
"""
The tag has been set to auter-configsnap-$(date +%Y-%m-%d)

Note that this will need to be adjusted if updates span over the change of a day ie: apply runs at 23:00 reboot runs at 02:00

"""
So the solution to avoid the issue here would be to either schedule the phases at the start of the day rather than the end (avoiding the issue) OR to edit your version of the configsnap scripts to calculate a different tag which is invariant over the period of the maintenance.

(For example, you could generate the tag using a different timezone than the server is running in where both times to be compared are in the same day.)

e.g
If server time is in UTC then you could calculate the date to be used in US/Central time.

start time 23:30 
Calculate epoch seconds for that time:
# TZ=UTC date -d '1997-07-20 23:30:00' +%s
869441400
Convert epoch seconds to date in US/Central timezone
# TZ='US/Central' date -d @869441400 +%Y-%m-%d
1997-07-20
(so start day stays the same)

End time 00:30 next day:
Calculate epoch seconds for that time:
# TZ=UTC date -d '1997-07-21 00:30:00' +%s
869445000
Convert epoch seconds to date in US/Central timezone
TZ='US/Central' date -d @869445000 +%Y-%m-%d
1997-07-20

configsnap tag could thus be set to auter-configsnap-$(TZ='US/Central' date +%Y-%m-%d) which would generate the same date string for both 11:30pm and 00:30am on a UTC based server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants