openrc.git/src/librc, branch dynamic-deptree

librc-depend.c: dynamically generate services for multiplexed services.

2024-07-20T01:19:56+00:00

when generating back references, attempt to instantiate missing services. Signed-off-by: Anna (navi) Figueiredo Gomes

librc-depend.c: split update function into subfunctions

2024-07-20T01:19:47+00:00

in preparation for dynamic service discovery, modularize the dependency tree generation and update into distinct functions. also helps with readability. Signed-off-by: Anna (navi) Figueiredo Gomes

librc-misc.c, rc.c, rc-status.c: fix memory leaks

2024-07-20T01:15:17+00:00

Signed-off-by: Anna (navi) Figueiredo Gomes

librc, openrc-pam: instantiate user. service automatically

2024-07-20T01:15:17+00:00

it's created in /run/openrc/dynamic and linked to the service in /etc at login. Signed-off-by: Anna (navi) Figueiredo Gomes

librc/librc-depend.c: small refactor

2024-07-20T01:15:17+00:00

some changes for code redability, and fixing leaking the whole internals of the deptree at the end of rc_deptree_update. Signed-off-by: Anna (navi) Figueiredo Gomes

openrc: dynamic paths for user services

2024-07-19T18:40:28+00:00

add two api functions, `rc_service_dir` and `rc_sysconf_dir`, both are generate paths (and sub-paths) for resources, and meant to replace the hardcoded variables like `RC_SVCDIR`. those functions differ by dynamically switching between the system path, or the user path, set in their home folder or runtime directory. this lays out the intial support for user services. Signed-off-by: Anna (navi) Figueiredo Gomes

librc: avoid using fixed-size buffers for paths

2024-06-03T19:50:37+00:00

Use heap allocations instead. This avoids warnings: ``` ../src/librc/librc.c: In function ‘rc_service_mark’: ../src/librc/librc.c:817:58: warning: ‘/’ directive output may be truncated writing 1 byte into a region of size between 0 and 4095 [-Wformat-truncation=] 817 | snprintf(was, sizeof(was), "%s/%s/%s", | ^ ../src/librc/librc.c:817:25: note: ‘snprintf’ output 3 or more bytes (assuming 4098) into a destination of size 4096 817 | snprintf(was, sizeof(was), "%s/%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 818 | file, dir->value, base); | ~~~~~~~~~~~~~~~~~~~~~~~ ../src/librc/librc.c:822:58: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=] 822 | snprintf(was, sizeof(was), "%s/%s", file, dir->value); | ^ ../src/librc/librc.c:822:25: note: ‘snprintf’ output 2 or more bytes (assuming 4097) into a destination of size 4096 822 | snprintf(was, sizeof(was), "%s/%s", file, dir->value); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ```

Skip already processed files in rc_service_daemon_set

2023-11-14T20:35:23+00:00

Fixes the problem described in https://bugs.gentoo.org/916947 - start-stop-daemon hangs in infinite loop when stopping some daemons on linux 6.6+ It appears linux 6.6 reworked tmpfs, and since then it triggers this problem in openrc: when iterating over files via readdir, running rename on a file could result in reading the same file again with next readdir call. The Open Group manual for readdir explicitly states "If a file is removed from or added to the directory after the most recent call to opendir() or rewinddir(), whether a subsequent call to readdir() returns an entry for that file is unspecified.". Linux man page don't seem to mention that, but don't seem to say anything to contradict that either. So I presume we can't rely on some specific behaviour here. Bug: https://bugs.gentoo.org/916947

librc: allow overriding rc_interactive on kernel command line

2023-05-11T01:39:25+00:00

This was originally introduced in 14625346c07a2a66fe77ce578c9423918bec1d97 with an example list (just one for rc_parallel) of options. Let's add in rc_interactive as it's a pretty obvious thing one might want to override. See https://forums.gentoo.org/viewtopic-p-8694588.html.

Rename attribute macros to namespaced RC_*

2023-04-19T20:44:51+00:00

This conflicts with linux-headers which uses __unused for some padding members on ppc64le at least. Closes: https://github.com/OpenRC/openrc/issues/622