aboutsummaryrefslogtreecommitdiff
path: root/src/start-stop-daemon/start-stop-daemon.c
AgeCommit message (Collapse)Author
2022-12-07start-stop-daemon: use a pipe to sync parent/child processesMike Gilbert
This fixes #557.
2022-09-06start-stop-daemon, supervise-daemon: set autogroup nicelevelMatt Whitlock
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.
2022-09-02Revert "start-stop-daemon: use vfork to avoid races"William Hubbs
This is broken, so revert it and reopen #532. This reverts commit 9e5ce59a21ed19a3829bae0b27d957c5fd0de74f.
2022-09-02start-stop-daemon: use vfork to avoid racesArusekk
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 5af58b45146a ("Rewrite the core parts in C. We now provide...") (or even before that), but it should have been only a minor issue before 45bd125dccdc ("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: 5af58b45146a ("Rewrite the core parts in C. We now provide...") Fixes #532.
2022-04-07start-stop-daemon: remove rc-prefix from file namesWilliam Hubbs
2022-04-06migrate fully to meson build systemWilliam Hubbs
- drop old build system - move shared include and source files to common directory - drop "rc-" prefix from shared include and source files - move executable-specific code to individual directories under src - adjust top-level .gitignore file for new build system This closes #489.