{"action":"created","issue":{"url":"https://api.github.com/repos/github/backup-utils/issues/176","repository_url":"https://api.github.com/repos/github/backup-utils","labels_url":"https://api.github.com/repos/github/backup-utils/issues/176/labels{/name}","comments_url":"https://api.github.com/repos/github/backup-utils/issues/176/comments","events_url":"https://api.github.com/repos/github/backup-utils/issues/176/events","html_url":"https://github.com/github/backup-utils/pull/176","id":136548211,"number":176,"title":"Prevent multiple restores","user":{"login":"snh","id":2051768,"avatar_url":"https://avatars.githubusercontent.com/u/2051768?v=3","gravatar_id":"","url":"https://api.github.com/users/snh","html_url":"https://github.com/snh","followers_url":"https://api.github.com/users/snh/followers","following_url":"https://api.github.com/users/snh/following{/other_user}","gists_url":"https://api.github.com/users/snh/gists{/gist_id}","starred_url":"https://api.github.com/users/snh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/snh/subscriptions","organizations_url":"https://api.github.com/users/snh/orgs","repos_url":"https://api.github.com/users/snh/repos","events_url":"https://api.github.com/users/snh/events{/privacy}","received_events_url":"https://api.github.com/users/snh/received_events","type":"User","site_admin":true},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2016-02-25T23:45:41Z","updated_at":"2016-03-02T23:34:07Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/github/backup-utils/pulls/176","html_url":"https://github.com/github/backup-utils/pull/176","diff_url":"https://github.com/github/backup-utils/pull/176.diff","patch_url":"https://github.com/github/backup-utils/pull/176.patch"},"body":"New version of #166 that traps SIGINT, SIGTERM, SIGHUP, and SIGQUIT to ensure that future restores aren't incorrectly blocked by a stale `/data/user/common/ghe-restore-status` file that incorrectly indicates a restore is still in progress.\r\n\r\nI would appreciate some advice on how best to handle a cluster scenario... At the moment this PR only checks the host specified as the restore host (either via `GHE_RESTORE_HOST` in the config file, or specified at the command line when running `ghe-restore`). \r\n\r\nThis is in part because this is the only place we currently maintain a `/data/user/common/ghe-restore-status` file.\r\n\r\nIn its current form this will prevent multiple restores in a cluster environment where the same host is specified as the restore host, but not where different hosts are specified that are part of the same cluster. For automated scenarios, which I believe is likely to be the most common scenario where multiple restores run at the same time, I imagine the same host is generally used.\r\n\r\n/cc @github/backup-utils @rubiojr "},"comment":{"url":"https://api.github.com/repos/github/backup-utils/issues/comments/191493409","html_url":"https://github.com/github/backup-utils/pull/176#issuecomment-191493409","issue_url":"https://api.github.com/repos/github/backup-utils/issues/176","id":191493409,"user":{"login":"snh","id":2051768,"avatar_url":"https://avatars.githubusercontent.com/u/2051768?v=3","gravatar_id":"","url":"https://api.github.com/users/snh","html_url":"https://github.com/snh","followers_url":"https://api.github.com/users/snh/followers","following_url":"https://api.github.com/users/snh/following{/other_user}","gists_url":"https://api.github.com/users/snh/gists{/gist_id}","starred_url":"https://api.github.com/users/snh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/snh/subscriptions","organizations_url":"https://api.github.com/users/snh/orgs","repos_url":"https://api.github.com/users/snh/repos","events_url":"https://api.github.com/users/snh/events{/privacy}","received_events_url":"https://api.github.com/users/snh/received_events","type":"User","site_admin":true},"created_at":"2016-03-02T23:34:07Z","updated_at":"2016-03-02T23:34:07Z","body":"> The issue here is that the restore host could be the load balancer public IP, not a cluster node, so we may land in a different server next time, rendering this check ineffective. You may be able use ghe-cluster-each to check for the file if not found in the current node. This will add some additional roundtrips and may still be a bit racey, but probably good enough.\r\n\r\nI'm wondering if a better approach would be to maintain `$GHE_REMOTE_DATA_USER_DIR/common/ghe-restore-status` on all cluster nodes? At the moment `ghe-store` only maintains it on the first server it lands on during a restore, so in theory if someone was to visit `http(s)://[hostname]/setup` during a restore, and hit a different node, it wouldn't be aware of the restore status, or even that a restore was underway? "}}