Move RenumberLocks into runtime init

We can't do renumbering after init - we need to open a
potentially invalid locks file (too many/too few locks), and then
potentially delete the old locks and make new ones.

We need to be in init to bypass the checks that would otherwise
make this impossible.

This leaves us with two choices: make RenumberLocks a separate
entrypoint from NewRuntime, duplicating a lot of configuration
load code (we need to know where the locks live, how many there
are, etc) - or modify NewRuntime to allow renumbering during it.
Previous experience says the first is not really a viable option
and produces massive code bloat, so the second it is.

Signed-off-by: Matthew Heon <matthew.heon@pm.me>

1 files changed, 20 insertions, 0 deletions

diff --git a/libpod/options.go b/libpod/options.go
index 06737776b..4a3dd582d 100644
--- a/libpod/options.go
+++ b/libpod/options.go
@@ -394,6 +394,26 @@ func WithDefaultInfraCommand(cmd string) RuntimeOption {
 	}
 }
 
+// WithRenumber instructs libpod to perform a lock renumbering instead of a
+// normal init.
+// When this is specified, no valid runtime will be returned by NewRuntime.
+// Instead, libpod will reinitialize lock numbers on all pods and containers,
+// shut down the runtime, and return.
+// Renumber is intended to be used from a dedicated entrypoint, where it will
+// handle a changed maximum number of locks and return, with the program
+// exiting after that.
+func WithRenumber() RuntimeOption {
+	return func(rt *Runtime) error {
+		if rt.valid {
+			return ErrRuntimeFinalized
+		}
+
+		rt.doRenumber = true
+
+		return nil
+	}
+}
+
 // Container Creation Options
 
 // WithShmDir sets the directory that should be mounted on /dev/shm.