Even systemd have collapsed a few of the cgroup controllers into a
semi-unified hierarchy and uses this approach. We just take it to
the extreme and have collapsed all of them (like cgroup v2).
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Two major bugs: `if (!cg)` and missing `strdup(path)`.
Also convert to use std hash table for lookup of previous cpu load value
for a given cgroup path. The hash table is sized after the current num.
rows on the screen -- resize currently not supported. The value given
to hcreate() should be 25% greater than the estimated num of entries,
but we take a wild guess just to make sure we don't run out of space at
runtime.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Fix obvious refactor mistake in cpu.shares assignment
- For unified memory hierarchy we need to set .use_hierarch=1
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The ps command currently only lists processes in the three main control
groups: init, system, user. Kernel threads are not show at all.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
As of now, the default finit cgroup behavior is to use a unified
hierarchy of controllers under /sys/fs/cgroup/finit.
We mount cpu,cpuacct,cpuset,memory (if available) and gain the
ability to control our three major groups: init, system, user.
The default CPU share setup is ~10% for init and user, and 90% for
system. These are guaranteed CPU shares to ensure we do not starve
PID 1 or user processes. Support for configuring these limits will
be added in a later commit.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
With the new practise of keeping record of process pid files, we no
longer need to log/update when reading back the same PID we already
have on file.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The previous patch just added dynamic tracking of non-declared pid
files, so we no longer need to make stuff up.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Services that create their own PID files usually don't declare one with
Finit. This patch adds support to track those PID files anywayt at
runtime for the purpose of identifying match svc_t when a PID file is
removed, i.e. when a service exits.
- On IN_CREATE the pidfile.so plugin saves the pid file name in svc_t
- On ON_DELETE the pidfile.so plugin finds svc_t based on pid file
Quicker tracking and less dead code, win-win.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Transitioning to runlevel 0 or 6 handles graceful shutdown of any
managed run/task/sysv/services. So we can replace the old 2 sec delay
with a shorter one for any non-managed still lingering process.
Also, some minor cleanup.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
To aid with debugging, highlight if env file, binary, or both are the
missing component(s) and causing status 'missing'.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Protect against corner cases where pid conditions are not cleaned up.
We don't want such conditions to remain asserted when the process has
terminated.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When we try to start a service/run/task we call whichp() to see if the
binary exists, either tha absolute path given in the .conf file, or in
the $PATH we run with. If binary, or the env: file, doesn't exist we
now set svc_missing() state.
On `initctl reload` we unblock the service to be able to check again.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This patch fixes a few really hard problems wrt PID files:
1. Listening for IN_CREATE events means we get notified immediately by
the kernel when someone calls open()/fopen() on a PID file. Reading
the contents returns 0, thank you atoi() ... so we drop IN_CREATE
and instead look for IN_CLOSE_WRITE, there fixed it! Not quite ...
2. Some programs, like Zebra, and other Quagga/Frr daemons, don't
close() their PID files after creation. Instead they ftruncate()
and keep them open, and locked. Presumably to get a mechanism to
detect already running instances -- messes life up a bit for the
rest of us though. So we need to read files after IN_MODIFY too.
3. We also want to track IN_DELETE so we can deassert conditions when
services exit gracefully and clean up their PID files
The rest fo the commit is debug instrumentation changes.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Joachim Wiberg