Re: Runit questions

2016-10-20 Thread Colin Booth
On Oct 20, 2016 12:40 AM, "Andy Mender" wrote: > > Dear colleagues, > > I verified my svlogd logging problems on Debian/Devuan and it turned out > that the error > I was getting was non-specific and did not really interfere with either > daemon supervision > by runsv or generating logs via svlogd.

Re: Runit questions

2016-10-20 Thread Andy Mender
Dear colleagues, I verified my svlogd logging problems on Debian/Devuan and it turned out that the error I was getting was non-specific and did not really interfere with either daemon supervision by runsv or generating logs via svlogd. Also, the error appears on my Gentoo boxen alike. Below, an ex

Re: Runit questions

2016-10-16 Thread Andy Mender
Thank you for the links and the svlogd script. Great help indeed :). Best regards, Andy On 16 Oct 2016 22:19, "Avery Payne" wrote: I hate using webmail. It always eats your formatting. The script shows up as a block of text in the mailing list because of this; just click the link for the proj

Re: Runit questions

2016-10-16 Thread Avery Payne
I hate using webmail. It always eats your formatting. The script shows up as a block of text in the mailing list because of this; just click the link for the project and look for the run-svlogd script. You'll find what you need there. On Sun, Oct 16, 2016 at 1:16 PM, Avery Payne wrote: > > > O

Re: Runit questions

2016-10-16 Thread Avery Payne
On Sat, Oct 15, 2016 at 3:28 PM, Andy Mender wrote: > Hello everyone, > > I managed to solve some of my problems. It turned out that my terminal was > being spammed > with erroneous output, because I didn't add the "exec 2&>1" redirection to > my ./run files. > This behavior is fairly consistent

Re: Runit questions

2016-10-15 Thread Andy Mender
Hello everyone, I managed to solve some of my problems. It turned out that my terminal was being spammed with erroneous output, because I didn't add the "exec 2&>1" redirection to my ./run files. Another problem popped up on my Devuan box, though. I was trying to add a log directory with a ./run

Re: Runit questions

2016-10-13 Thread Avery Payne
On Tue, Oct 11, 2016 at 3:09 PM, Andy Mender wrote: > Hello again, > > I'm rewriting some of the standard sysvinit and openrc scripts to ./run > scripts > I would look around a bit. There are little pockets of pre-written scripts out there, you just need to dig them up. Some of the scripts on

Re: Runit questions

2016-10-13 Thread Steve Litt
On Thu, 13 Oct 2016 12:16:52 +0200 Andy Mender wrote: > I was recently trying to convert my OpenRC-based Gentoo installation > into one based on runit. However, I noticed that it's quite easy to > send runsvdir or runsvchdir into an infinite loop when there is > something wrong with a service dir

Re: Runit questions

2016-10-13 Thread Andy Mender
I was recently trying to convert my OpenRC-based Gentoo installation into one based on runit. However, I noticed that it's quite easy to send runsvdir or runsvchdir into an infinite loop when there is something wrong with a service directory or the runlevel dir selected through runsvchdir is missin

Re: Runit questions

2016-10-12 Thread Colin Booth
On Tue, Oct 11, 2016 at 9:11 PM, Jonathan de Boyne Pollard wrote: > Colin Booth: >> >> --system loads the system defaults. > > Actually, it tells it that it is a system-wide broker rather than a > per-session or per-user broker. Interesting. Then the manpage is lying: --system U

Re: Runit questions

2016-10-11 Thread Jonathan de Boyne Pollard
Colin Booth: --system loads the system defaults. Actually, it tells it that it is a system-wide broker rather than a per-session or per-user broker.

Re: Runit questions

2016-10-11 Thread Colin Booth
On Oct 11, 2016 4:07 PM, "Steve Litt" wrote: > > On Wed, 12 Oct 2016 00:09:02 +0200 > Andy Mender wrote: > > > 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 > > Lin

Re: Runit questions

2016-10-11 Thread Steve Litt
On Wed, 12 Oct 2016 00:09:02 +0200 Andy Mender wrote: > 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

Re: Runit questions

2016-10-11 Thread Colin Booth
On Oct 11, 2016 3:09 PM, "Andy Mender" wrote: > > 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 sc

Re: Runit questions

2016-10-11 Thread Andy Mender
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 dbu

Re: Runit questions

2016-10-11 Thread Andy Mender
> 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 s

Re: Runit questions

2016-10-11 Thread Steve Litt
On Tue, 11 Oct 2016 16:36:08 +0200 Andy Mender wrote: > Dear Jan, Laurent, > > Thank you kindly for answering my questions and clarifications :). I'm > slowly starting to have a general idea of how to use runit, > but I will definitely have streams of questions in the nearest > future. As far as

Re: Runit questions

2016-10-11 Thread Steve Litt
On Tue, 11 Oct 2016 11:53:38 +0200 Jan Bramkamp 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: ===

Re[4]: Runit questions

2016-10-11 Thread Laurent Bercot
the point is to avoid extensive scripting hodgepodge within run scripts to avoid replicating System V init limitations, correct? The point of supervision is to provide a reliable environment for running long-lived processes. The fact that most of the scripting hodgepodge can be avoided is a na

Re: Re[2]: Runit questions

2016-10-11 Thread Charles Duffy
Correct, cgroups can be used from any process supervision system. As for socket activation, this too can be implemented on top of a traditional supervision system, with no need for it to be baked into the core. See http://smarden.org/ipsvd/ for an example implementation. Granted, this one doesn't

Re: Re[2]: Runit questions

2016-10-11 Thread Andy Mender
Dear Jan, Laurent, Thank you kindly for answering my questions and clarifications :). I'm slowly starting to have a general idea of how to use runit, but I will definitely have streams of questions in the nearest future. As far as I understood, the point is to avoid extensive scripting hodgepodge

Re[2]: Runit questions

2016-10-11 Thread Laurent Bercot
>> 2. If several services rely on a common daemon, like dbus or udev/eudev, is >> the said daemon launched multiple times? No. One service directory = one daemon instance. If you have a service directory for dbus-daemon, it will be launched once, no matter how many times you "sv up" that serv

Re: Runit questions

2016-10-11 Thread Jan Bramkamp
On 11/10/16 09:33, Andy Mender wrote: Hello, I am a "journeyman" UNIX user, currently trying to implement runit as a substitute for systemd on a number of GNU/Linux distributions. I already have the ./run service scripts per the original documentation for runit (http://smarden.org/runit/). Howev

Runit questions

2016-10-11 Thread Andy Mender
Hello, I am a "journeyman" UNIX user, currently trying to implement runit as a substitute for systemd on a number of GNU/Linux distributions. I already have the ./run service scripts per the original documentation for runit (http://smarden.org/runit/). However, I don't fully understand how logging