From d2b77f8b3397b3ffbbade6e04e37b291105028aa Mon Sep 17 00:00:00 2001 From: Matthew Heon Date: Mon, 18 Feb 2019 16:20:02 -0500 Subject: Do not make renumber shut down the runtime The original intent behind the requirement was to ensure that, if two SHM lock structs were open at the same time, we should not make such a runtime available to the user, and should clean it up instead. It turns out that we don't even need to open a second SHM lock struct - if we get an error mapping the first one due to a lock count mismatch, we can just delete it, and it cleans itself up when it errors. So there's no reason not to return a valid runtime. Signed-off-by: Matthew Heon --- libpod/runtime_renumber.go | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) (limited to 'libpod/runtime_renumber.go') diff --git a/libpod/runtime_renumber.go b/libpod/runtime_renumber.go index 04abc84d1..125cf0825 100644 --- a/libpod/runtime_renumber.go +++ b/libpod/runtime_renumber.go @@ -6,9 +6,6 @@ import ( // renumberLocks reassigns lock numbers for all containers and pods in the // state. -// It renders the runtime it is called on, and all container/pod/volume structs -// from that runtime, unusable, and requires that a new runtime be initialized -// after it is called. // TODO: It would be desirable to make it impossible to call this until all // other libpod sessions are dead. // Possibly use a read-write file lock, with all non-renumber podmans owning the @@ -56,5 +53,5 @@ func (r *Runtime) renumberLocks() error { } } - return r.Shutdown(false) + return nil } -- cgit v1.2.3-54-g00ecf