Much like PAM, not all implementations of libcrypt provide a pkg-config
file, and hence we can't find it using the old logic.
Let's fall back to the standard AC_SEARCH_LIBS-style check if the pkg-config-style
detection fails.
This fixes finding e.g. musl's libcrypt.
X-Gentoo-Bug: 827074
X-Gentoo-Bug-URL: https://bugs.gentoo.org/827074
We only need libcrypt if we're building _with_ SELinux and
_without_ PAM. We don't use libcrypt for general SELinux
with PAM.
This is mostly a correctness change as libcrypt should
generally be available (as opposed to the previous
change which fixed some real-world cases).
Fixes: f3f0fde861Fixes: #478
Clang was failing with:
```
/zroot/jenkins/workspace/update_ghsotbsd-13_poudriere_jail/sbin/openrc/../../contrib/openrc/src/rc/rc.c:70:2: error: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Werror,-Wstring-concatenation]
"when leaving single user or boot runlevels",
^
/zroot/jenkins/workspace/update_ghsotbsd-13_poudriere_jail/sbin/openrc/../../contrib/openrc/src/rc/rc.c:69:2: note: place parentheses around the string literal to silence warning
"override the next runlevel to change into\n"
^
```
This fixes#469.
While the s6-svscan runscript belongs to OpenRC, the user is required to
install s6 before it can actually be used, potentially leading to
confusion. Check for the existence of $command in start_pre and, if it does not
exist, bail out with an error that makes this observation.
X-Gentoo-Bug: 816978
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=816978
This github action runs a build on each of the following platforms on a
push or pull request.
- Ubuntu LTS with gcc and glibc
- Ubuntu LTS with clang and glibc
- Alpine with gcc and musl
This fixes#463.
strlen's return value isn't enough to be used
directly for (x)malloc; it doesn't include
the null byte at the end of the string.
X-Gentoo-Bug: 816900
X-Gentoo-Bug-URL: https://bugs.gentoo.org/816900Fixes: #459Fixes: #462
Currently, we run sv start immediately after linking the service.
The runsv process may not be up at the moment, as a result of which
openrc will mark the service as stopped, even though it may be brought up
by runit at the next scan.
This is documented in the gentoo wiki:
https://wiki.gentoo.org/wiki/Runit#OpenRC.27s_runit_integration_feature
This PR adds a timeout so that correct process state can be reported.
Before:
* Starting netdata-runit ...
fail: /run/openrc/sv/netdata: runsv not running
* Failed to start netdata-runit
After:
* Starting netdata-runit ...
fail: /run/openrc/sv/netdata: runsv not running
ok: run: /run/openrc/sv/netdata: (pid 9042) 0s
This fixes#253.
Fix the following error:
broadcast.c:41:21: error: '__UT_LINESIZE' undeclared (first use in this function); did you mean 'UT_LINESIZE'?
#define UT_LINESIZE __UT_LINESIZE
^~~~~~~~~~
Constant UT_LINESIZE is defined in <utmp.h> provided by musl.
Busybox timeout does not support the `-k` flag. As such, invoking fuser
from do_unmount never worked without this patch. This went unnoticed as
standard error is redirected to /dev/null. This patch fixes this by
simply removing the incompatible `-k` flag.
[Ariadne: the `-k` is redundant anyway, since we are sending the KILL
signal to begin with.]
Since musl 1.2 time_t is a 64 bit value, even on 32 bit systems. A
hotfix for printing the value is simply using PRIu64 from inttypes.h
in the format string.
This fixes#446.
