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 <andymenderunix_at_gmail.com> 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 <slitt_at_troubleshooters.com> wrote:
>
>> On Tue, 11 Oct 2016 11:53:38 +0200
>> Jan Bramkamp <crest_at_rlwinm.de> 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
>>
>>
>>
>
Received on Tue Oct 11 2016 - 22:09:02 UTC