summaryrefslogtreecommitdiff
path: root/libpod/lock/shm/shm_lock_test.go
diff options
context:
space:
mode:
authorMatthew Heon <matthew.heon@pm.me>2019-02-15 09:59:11 -0500
committerMatthew Heon <matthew.heon@pm.me>2019-02-21 10:51:42 -0500
commita72025d6fd111bfa2dc4e1d22871966fec614f88 (patch)
tree72ae221f1926c9f3da0eef292522da55b9929b7f /libpod/lock/shm/shm_lock_test.go
parentca8ae877c12cbfa368d572ef6700d9e4a23d5b11 (diff)
downloadpodman-a72025d6fd111bfa2dc4e1d22871966fec614f88.tar.gz
podman-a72025d6fd111bfa2dc4e1d22871966fec614f88.tar.bz2
podman-a72025d6fd111bfa2dc4e1d22871966fec614f88.zip
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>
Diffstat (limited to 'libpod/lock/shm/shm_lock_test.go')
0 files changed, 0 insertions, 0 deletions