this was reported by codeql's scan as a TOCTOU bug. while that's true in
theory, i don't believe it would've had any practical effect.
a better justification for this change might be the fact that it
upgrades from `utime` (which is depreciated by POSIX [0]) to `futimens`.
[0]: https://www.man7.org/linux/man-pages/man3/utime.3p.html#FUTURE_DIRECTIONS
malloc (called by xasprintf) is not async-signal-safe. beside, the
string here is constant, so there's no need to malloc it all.
eerrorx isn't async-signal-safe either (due to calling fprintf and exit)
but consequence of them are _typically_ not as grave as calling malloc
while it's internal state is inconsistent.
Bug: https://github.com/OpenRC/openrc/issues/589
From scan-build w/ clang-16.0.0_pre20230107:
```
../src/librc/librc.c:759:14: warning: Potential leak of memory pointed to by 'init' [unix.Malloc]
return false;
^~~~~
```
It's already initialised to false at the start and it's clear when reading
what the flow is.
While at it, fix some indentation and adjust whitespace to make more readable.
These become fine with C23 because () starts to mean (void) then, but for
previous language versions, it's deprecated, and it causes an annoying
warning when building with Clang by default.
Plus, GCC lacks specific flags to trigger what C23 *does* ban, so a lot
of people are going around building with -Wstrict-prototypes, so let's
just fix this to be consistent with the rest of the codebase anyway
to fend off false positive reports.
On systems with a very large RLIMIT_NOFILE, calling close() in a loop
from 3 to getdtablesize() effects an enormous number of system calls.
There are better alternatives. Both BSD and Linux have the closefrom()
system call that closes all file descriptors with indices not less than
a specified minimum. Have start-stop-daemon call closefrom() on systems
where it's implemented, falling back to the old loop elsewhere.
Likewise, calling fcntl(i, F_SETFD, FD_CLOEXEC) in a loop from 3 to
getdtablesize() raises a similar performance concern. Linux 5.11 and
onward has a close_range() system call with a CLOSE_RANGE_CLOEXEC flag
that sets the FD_CLOEXEC flag on all file descriptors in a specified
range. Have supervise-daemon utilize this feature on systems where it's
implemented, falling back to the old loop elsewhere.
1364e6631c exempted the write end of the
synchronization pipe from the close() loop in the child process, but
this is unnecessary, as the pipe is opened with O_CLOEXEC, and the child
process calls execvp() soon after the close() loop, with the intervening
code not needing the pipe. Indeed, the pipe only needs to remain open in
the child process until after the call to setsid(), which occurs well
before the close() loop. So, eliminate the needless carve-out from the
close() loop, in preparation for introducing closefrom().
dirfd is uninitialized at this point, and even if it were, it doesn't
make sense to use since the path is "/" -- the dirfd is ignored when
the path is absolute. Switch to AT_FDCWD to avoid all that.
The default behavior of check: false is going to change to true in the
future, see <https://github.com/mesonbuild/meson/issues/9300>.
Thus we are explicit about the desired behavior. The error in uname is
important but with test we check ourselves using returncode().
This fixes#556.
If supervise_daemon_args is not set *or empty*, it defaults to
`start_stop_daemon_args`. This is bad because supervise-daemon doesn't
accept the same options as `start-stop-daemon`. So if we set e.g.
`start_stop_daemon_args="--wait 50"`, but not `supervise_daemon_args`,
and the user adds `supervisor=supervise-daemon` to the corresponding
/etc/conf.d/<service> file, the service will fail to start due to
unrecognized option "wait".
It would be best to remove this fallback, but that might break some
existing scripts that depend on it. So this commit just changes it to
use `start_stop_daemon_args` as the default for `supervise_daemon_args`
only if `supervise_daemon_args` is not set at all, but not if it's
empty.
This at least simplifies workarounds; we can just add
`supervise_daemon_args="$supervise_daemon_args"` to init scripts.
This fixes#558.
Despite this being a 'deptree', it's actually
xmalloc'd in the same function (rc_deptree_update),
and so should be free'd, not rc_deptree_free'd,
as rc_deptree_load* wasn't used to allocate it.
```
[71/213] Compiling C object src/librc/librc.so.1.p/librc-depend.c.o
../src/librc/librc-depend.c: In function ‘rc_deptree_update’:
../src/librc/librc-depend.c:1077:9: warning: ‘rc_deptree_free’ called on pointer returned from a mismatched allocation function [-Wmismatched-dealloc]
1077 | rc_deptree_free(deptree);
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/shared/misc.h:29,
from ../src/librc/librc.h:57,
from ../src/librc/librc-depend.c:21:
In function ‘xmalloc’,
inlined from ‘rc_deptree_update’ at ../src/librc/librc-depend.c:775:12:
../src/shared/helpers.h:64:23: note: returned from ‘malloc’
64 | void *value = malloc(size);
| ^~~~~~~~~~~~
```
This fixes#563.
Starting with grep version 3.8, the hwclock init script logs warnings
about stray backslashes:
> hwclock | * Setting system clock using the hardware clock [UTC] ...
> hwclock |grep: warning: stray \ before -
> hwclock |grep: warning: stray \ before -
This is caused by the check for existence of the `--noadjfile` argument
in function `get_noadjfile()`.
Replacing the affected logic with an explicit argument denoting the
pattern as such resolves the issue.
Fixes#548
As described in "Why nice levels are a placebo and have been for a very
long time, and no one seems to have noticed"[1], the Linux kernel in its
default configuration on many Linux distributions autogroups tasks by
session ID and "fairly" allocates CPU time among such autogroups. The
nice levels of tasks within each autogroup are only relative to
other tasks within the same autogroup. Effectively, this means that the
traditional nice level is rendered moot for tools like start-stop-daemon
and supervise-daemon, which start each daemon in its own session and
thus in its own autogroup. Linux does provide a means to change the
niceness of autogroups relative to each other, so let's have start-stop-
daemon and supervise-daemon make use of this feature where available so
that -N,--nicelevel/SSD_NICELEVEL will actually do what the user
intends. On systems where autogroups are not supported or are disabled,
this commit introduces no change in behavior.
Note that the setsid() call in the child process of start-stop-daemon is
moved to much earlier. This is necessary so that the new process will be
assigned to a new autogroup before the autogroup nicelevel is set. To
avoid inadvertently acquiring /dev/tty as the controlling terminal of
the new session after setsid() has given up the controlling terminal
inherited from the parent process, tty_fd is opened before the call to
setsid().
[1] https://www.reddit.com/r/linux/comments/d7hx2c/why_nice_levels_are_a_placebo_and_have_been_for_a/
This fixes#542.
While refactoring the changes proposed in #533 a minor error was
introduced were the root service will now attempt to remount swap.
This will fail with the error message `mountinfo: 'swap' is not a
mountpoint`.
This fixes#546
Without this commit, the root OpenRC service remounts all mounted
filesystems (except /) with the options defined in /etc/fstab via
fstabinfo. It is presently unclear to me why / was excluded from
remounting in 497ff7ee41 and unfortunately
neither the commit nor the associated Bugzilla issue [1] provides
further information on this.
At Alpine, our initramfs does currently not remount / with all options
defined in /etc/fstab [2]. As part of the discussion on the Alpine side
of things we wondered why OpenRC does not remount / since this would be
the easier solution for us. For this reason, this commit changes the
behavior of the OpenRC root services accordingly to also remount / with
the options defined in /etc/fstab.
[1]: https://bugs.gentoo.org/401573
[2]: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/103
This fixes#533.
While running `rc-service start docker` on Gentoo,
I found that the command does not start the service 90% of the time,
with an enigmatic 'service crashed' message.
The root cause of this is apparently rc-service spawning a pty,
running start-stop-daemon inside that pty, and exitting,
before start-stop-daemon child process calls setsid(),
which results in the child process being killed with SIGHUP (SI_KERNEL).
Theoretically this bug was present ever since the file was created in
5af58b4514 ("Rewrite the core parts in C. We now provide...")
(or even before that), but it should have been only a minor issue before
45bd125dcc ("Use a pty for prefixed output instead of pipes for...").
Not sure why nobody has had the issue so far (it has been present for
almost 15 years).
As here setsid() is the last call before execve(), the most natural
locking mechanism is vfork(), as it gives back control to parent
process only after execve() or process termination.
So this way the bug can be fixed by adding a single letter. :-)
Another way to ensure this would be using an O_CLOEXEC file descriptor
or some custom lock, which would need to be released not before setsid().
Fixes: 5af58b4514 ("Rewrite the core parts in C. We now provide...")
Fixes#532.
