diff options
author | Matthew Heon <matthew.heon@pm.me> | 2019-02-15 09:59:11 -0500 |
---|---|---|
committer | Matthew Heon <matthew.heon@pm.me> | 2019-02-21 10:51:42 -0500 |
commit | a72025d6fd111bfa2dc4e1d22871966fec614f88 (patch) | |
tree | 72ae221f1926c9f3da0eef292522da55b9929b7f /libpod/lock/shm/shm_lock.c | |
parent | ca8ae877c12cbfa368d572ef6700d9e4a23d5b11 (diff) | |
download | podman-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.c')
0 files changed, 0 insertions, 0 deletions