support for dynamic multiplexing of services #753
Conversation
Use the realpath of the target to locate which system directory it's in, using it as a base to load the config file. the service path is then normalized from the symlink without dereferencing it. Introduce a new variable for openrc-run, $RC_SYSCONFDIR, which points to the respective system directory of the base service. Signed-off-by: Anna (navi) Figueiredo Gomes <[email protected]>
Generate a new directory on the service dir, "multiplexed", which will hold all the symlinks we generate at runtime, and a new librc function, "rc_service_multiplex", which takes a basename or service path, and a variant name, then generated a symlink to the base service from the multiplex dir. This allows multiplexing services at runtime, possibly using data acquired at runtime, such as the name of an user or interface.
navi-desu
force-pushed
the
dynamic-multiplex
branch
from
c1a429e
to
1665840
Compare
|
currently working on how to make sure multiplexed services get added to the deptree properly probably gonna split the deptree generating function so we can also call it per-service |
|
Should the documentation also explain what "multiplexed services" are? |
openrc-run(8) kinda just mentions it, it's not new it's basically when you have a it is usually done as a symlink, e.g. yeah the docs need improving and doing this dynamically, would be creating that symlink as needed. so say some service does current major use case for this would be instantiating user.<username> automatically for user services though this feature is currently being debated if we include it at all or not, as i'm not sure it's useful at all outside user services |
generate a new directory on the service dir, "multiplexed", which will
hold all the symlinks we generate at runtime, and a new librc function,
"rc_service_multiplex", which takes a basename or service path, and a
variant name, then generated a symlink to the base service from the
multiplex dir.
this allows multiplexing services at runtime, possibly using data
acquired at runtime, such as the name of an user or interface.
this is the second of three patchsets for user services support
as an initial barebones implementation, it's useful only for generating
services without dynamically multiplexed dependencies, as this is what's
needed for bootstrapping the openrc user script in a new session.
a future patch may improve on it, possibly integrating it in dependency
resolution and on the rc-service tool.