Age | Commit message (Collapse) | Author |
|
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 <navi@vlhl.dev>
|
|
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
|
|
|
|
There are no semantic changes in this commit.
Suggested-by: Mike Frysinger <vapier@gentoo.org>
See: https://github.com/OpenRC/openrc/pull/435#pullrequestreview-727035394
|
|
This makes the URIs shorter and dynamic: whatever the default branch
the repo uses will be used.
|
|
Fixes: #471
Fixes: #473
|
|
The previous fix excludes PIDs of processes running in a different namespace
regardless of whether the PID has been explicitly stored in a PID file mentioned
in the --pidfile parameter. The correct behavior is to only exclude the pid if
it is not stored in a pidfile.
X-Gentoo-Bug: 776010
X-Gentoo-Bug-URL: https://bugs.gentoo.org/776010
|
|
This fixes #313.
|
|
I am removing this on the advice of a member of the Gentoo toolchain
team. It was explained to me that this doesn't offer any significant
benefits to OpenRC.
If anyone ffeels differently, please open a pull request reverting
this and adding an explanation of what it does and how to know which
functions to mark hidden in the future.
This fixes #301.
|
|
This fixes #299.
|
|
This reverts commit 084877eb52971faf8f52c780ddd08ed9af140eb6.
The mentioned commit caused some systems to have some services reported
as crashed.
This fixes #297.
This fixes #298.
|
|
readlink(3) does not nul-terminate the result it sticks
into the supplied buffer. Consequently, the code
rc = readlink(path, buf, sizeof(buf));
does not necessarily produce a C string.
The code in rc_find_pid() produces some C strings this way
and passes them to strlen() and strcmp(), which can lead
to an out-of-bounds read.
In this case, since the code already takes care to
zero-initialize the buffers before passing them
to readlink(3), only allow sizeof(buf)-1 bytes to
be returned.
(While fixing this issue, I fixed two other locations that
used the same problematic pattern.)
This fixes #270.
|
|
The contents of /proc/<pid>/cmdline are read into
a stack buffer using
bytes = read(fd, buffer, sizeof(buffer));
followed by appending a null terminator to the buffer with
buffer[bytes] = '\0';
If bytes == sizeof(buffer), then this write is out-of-bounds.
Refactor the code to use rc_getfile instead, since PATH_MAX
is not the maximum size of /proc/<pid>/cmdline. (I hit this
issue in practice while compiling Linux; it tripped the
stack-smashing protector.)
This is roughly the same buffer overflow condition
that was fixed by commit 0ddee9b7d2b8dea810e252ca6a95c457876df120
This fixes #269.
|
|
|
|
|
|
Ignore namespaces if there are errors reading either the pid namespace
for the current process or the process we aare testing.
This fixes https://github.com/openrc/openrc/issues/180.
|
|
X-Gentoo-Bug: 634634
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=634634
|
|
In the past, OpenRC was a hybrid of a centralized and file-scope
license/copyright structure.
I followed the instructions from the Software Freedom Law Center [1] to
convert to a Centralized structure where possible, for easier future
maintenance.
[1] https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
|
|
This also fixes breakage of GNU/hurd builds introduced by commit 3f82edbeb92.
|
|
|
|
librc: Fix C90 warning (mixed declaration and code)
rc: Fix warning about discarding const qualifier
Fixes #45.
|
|
This fixes a double free of the pidfile variable. For discussion of this
issue, see the bug.
X-Gentoo-Bug: 531600
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=531600
|
|
Fixes #28.
X-Gentoo-Bug: #527370
X-Gentoo-Bug-Url: https://bugs.gentoo.org/show_bug.cgi?id=527370
|
|
We are bundling this to allow building on musl-based systems since musl
does not include <sys/queue.h>.
|
|
It is necessary to check for both the kernel and c library because
__FreeBSD_kernel is also defined on native FreeBSD [1].
[1] http://sourceforge.net/p/predef/wiki/OperatingSystems/
|
|
Check for __FreeBSD_kernel instead of __GLIBC__ in source files.
note from William Hubbs:
I was told this is a better check for GNU/kFreeBSD than checking the
C library the source is being compiled against.
GNU/kFreeBSD than checking which library we are using.
|
|
X-Gentoo-Bug: 524388
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=524388
|
|
|
|
Thanks to info and testing done by Daniel Robbins <drobbins@funtoo.org>,
there is now a fix for this. Below is his description of the steps
OpenRC needed to use.
1) See if /proc/<pid>/status exists
2) If it does, see if it has a "envID:" field
3) If it does, see if "envID:" is set to "0"
4) If so, then it's one of the host's processes and should be a
candidate for the list. Otherwise, it is one of the container's
processes and should be ignored.
This should fix the bug and allow start-stop-daemon to work properly on
OpenVZ hosts.
X-Gentoo-Bug: 376817
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=376817
|
|
This is just a minimal port to get Debian up and running; the rest will
be done later.
|
|
|
|
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
maybe working better with interpreted scripts.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Gentoo #218028.
|