Hello again, I'm rewriting some of the standard sysvinit and openrc scripts to ./run scripts and I have some problems with dbus. I took the ./run script from Void Linux as the original runit documentation doesn't have an exemplary dbus script. Whenever I check the status of dbus via "sv status dbus", I get the following error: "warning: dbus: unable to open supervise/ok: file does not exist". This makes no sense, as both /etc/sv/dbus/supervise/ and /var/service/dbus/supervise/ contain the "ok" file. Below the run script from Void Linux: #!/bin/sh [ ! -d /run/dbus ] && install -m755 -g 22 -o 22 -d /run/dbus exec dbus-daemon --system --nofork --nopidfile
Not sure what's wrong and why this run script needs to contain so many operands. Best regards, Andy On 11 October 2016 at 21:24, Andy Mender <[email protected]> wrote: > > Andy, one more observation: I'd think twice about letting the systemd > > project set your expectations for init system requirements. They use > > cgroups for certain things, and advertise that as a great benefit. It's > > not. They make up the term "socket activation" and advertise that if > > an init system doesn't have it, that init system is ineffective. This > > is false. Follow the money: Plenty of people benefit from systemd > > displacing all other init systems, even if systemd is ineffective or > > effective only as long as programmers are given a million or so dollars > > a year to keep it running despite its crushing complexity. Do not let > > the systemd talking points influence the features YOU want in an init > > system. > > It's quite difficult not to get phased by something that's been all the > talk > for some years now. The pressure from the so-called majority is strong > after all... > > I personally prefer very minimalist approaches to init and system process > supervision, much like the ones used by CRUX Linux. However, I do > understand that bare Shell scripts are difficult to maintain and proper > supervisors are "there to be used". That's why these discussions, tons of > reading and a newly kindled fancy for runit and s6. For my personal use > it's enough that runit manages the most essential system daemons so that > I don't have to call "shutdown" or "reboot" from a terminal emulator :P. > > For testing the bare essentials, Gentoo serves me quite nicely. With USE > flags I have a good idea of what features are needed by which programs. > > Best regards, > Andy > > On 11 October 2016 at 18:15, Steve Litt <[email protected]> wrote: > >> On Tue, 11 Oct 2016 11:53:38 +0200 >> Jan Bramkamp <[email protected]> wrote: >> >> >> > Runit doesn't track dependencies directly, but it can handle them. >> > This is done by calling sv start $DEP_1 $DEP_2 etc. in the ./run >> > script. >> >> I've always done it differently, as shown in this run script: >> >> ================================================ >> #!/bin/sh >> if test_of_readiness_of_dep1; then >> exec this_daemon >> fi >> sleep 1 >> ================================================ >> >> So if $DEP_1 isn't ready, $THIS_DAEMON waits a second and then fails >> and is soon tried again. For a dependency that takes huge amounts of >> time, like dhcpcd, that sleep might be 15 instead of 1. >> >> Your method is obviously more efficient and straightforward than mine. >> My method theoretically could act like a bunch of ping pong balls on a >> bunch of set mousetraps, although in practice I've never seen any >> evidence of that. Your method sets off dependencies consecutively >> rather than trial and error, and would seem to be superior, with two >> exceptions: >> >> 1) My method can be used to test for any arbitrary definition of the >> dependency being "ready". For instance, my sshd service could run >> only after a successful ping of 8.8.8.8 or of google.com, thereby >> proving the network is up all the way to the Internet. This is much >> more specific than merely testing whether the networking system is >> running. >> >> 2) My method refuses to run $THIS_DAEMON if $DEP_1 is not functional, >> rather than starting $DEP_1 and assuming it will start correctly, >> instantly. My method refuses to run a daemon when its dependencies >> have serious problems. >> >> I'm wondering if our methods could be combined: >> >> ================================================ >> #!/bin/sh >> sv start $DEP_1 >> sleep $APPROPRIATE_SECONDS >> if test_of_readiness_of_dep1; then >> exec this_daemon >> fi >> sleep 1 >> ================================================ >> >> In the preceding, $APPROPRIATE_SECONDS is probably a small fraction >> like 0.1: Just enough time for $DEP_1 to become ready to do its job. >> >> SteveT >> >> Steve Litt >> September 2016 featured book: Twenty Eight Tales of Troubleshooting >> http://www.troubleshooters.com/28 >> >> >> >
