On Oct 20, 2016 12:40 AM, "Andy Mender" <andymenderunix_at_gmail.com> 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. Also, the error appears on my
> Gentoo boxen alike.
> Below, an example snippet:
> "runsvdir: log: 2: exec 2: ./run not found: exec 3: not found"
> Curiously, ./log/run exists and gets executed, in addition to "exec" being
> built in the Shell
> and also being executed. Not sure what's going on...
Are you calling 'exec 2&>1' or 'exec 2>&1'? The first is either trying to
background the 2 program and redirect it's output to a file called 1, or
exec into a program called 2 and redirect both stderr and stdout to a file
called one (behavior is shell dependent). The second is redirecting stderr
to the location stdout is pointing, and is the command you want.
>
> Secondly, what is really the default service directory per upstream -
> /service, /var/service,
> /etc/service or another directory? The official docs online mention
> /service in the sv(8)
> manpage, but Void Linux uses /var/service and Debian uses /etc/service.
The
> sv(8)
> manpage for Debian mentions /etc/service, but there are no dates anywhere
> to confirm
> when was this changed. What it means in practice is that when doing "sv
> <command>
> service", if sv tries to look for the service dir in the wrong main
> directory, it will return
> an error: "service directory does not exist". This can be circumvented by
> calling the
> service dir via sv directly, as in "sv <command> /path/to/service/".
> However, I would like
> to know what's the current "vanilla" upstream to help the Devuan people
> better.
Daemontools' svscan originally used /service, so the daemontools compatible
layout (and as such the normal supervision default) is /service. However,
there is no hard requirement on the directory used since scanners will run
against any directory you give them (or CWD if omitted). In the case of
runit, runsvdir is given a path via the script inittab calls and the search
path that the sv command uses is set at compile time. In Debian, that path
is /etc/service.
>
> Other than that I think runit is great and the more I learn about it, the
> more I feel it can be
> used as the go-to supervision suite for Unices :).
Runit is pretty nice and has the added benefit of having binary packages
available. It isn't pushing the state of the art forward, for that you need
s6 or nosh, but for basic supervision needs and as an entry point into
learning about process supervision runit works great.
>
> Best regards,
> Andrzej
>
Cheers!
>
>
> On 17 October 2016 at 06:09, Andy Mender <andymenderunix_at_gmail.com> wrote:
>
> > Thank you for the links and the svlogd script. Great help indeed :).
> >
> > Best regards,
> > Andy
> >
> > On 16 Oct 2016 22:19, "Avery Payne" <avery.p.payne_at_gmail.com> 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 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 <avery.p.payne_at_gmail.com>
> > wrote:
> >
> >>
> >>
> >> On Sat, Oct 15, 2016 at 3:28 PM, Andy Mender <andymenderunix_at_gmail.com>
> >> 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 among supervisors. The use of
STDERR
> >> typically is left to the administrator to decide; more commonly, it's
> >> simply tied off into the STDOUT stream for ease of use.
> >>
> >>
> >>>
> >>> Another problem popped up on my Devuan box, though. I was trying to
add a
> >>> log directory with a ./run script inside to log dhcpcd per runit's
> >>> design.
> >>> However, runsvdir complaints that "exec: not found".
> >>>
> >>
> >> This is probably a problem with your shell. The shebang specified
might
> >> point to an actual sh and not something like bash, ash, dash, etc. I
don't
> >> have a reference handy but I suspect that you are seeing failure
messages
> >> for "exec" because the shell doesn't support that built-in.
> >>
> >> If you encounter this, change the first line to /bin/bash or /bin/ash
or
> >> /bin/dash and see if that resolves the issue.
> >>
> >>
> >>> The same run scripts work on Gentoo, which makes it even more
surprising.
> >>>
> >>
> >> Gentoo may be mapping /bin/sh to bash/ash/something else, but I don't
> >> know. I would suggest finding out.
> >>
> >>
> >>> Below the log/run script:
> >>> #!/bin/sh
> >>> exec chpst -u log svlogd -tt ./
> >>>
> >>
> >> I'll post a companion log script in a moment.
> >>
> >>
> >>> PS Earlier runsvdir was complaining that "log: user/group not found".
I
> >>> created the "log" group, thinking it might help somehow.
> >>>
> >>
> >> You shouldn't need to create the group normally, which may indicate a
> >> separate issue.
> >>
> >> Try this run script in your ./svcdef/dbus/log directory. It's lifted
> >> straight from the source at http://bitbucket.org/avery_pay
> >> ne/supervision-scripts as the ./svcdef/.log/run-svlogd script. Please
> >> note that you may need to change the group name after chown, and the
shell
> >> in the first line to meet your needs:
> >>
> >> #!/bin/shexec 2>&1# determine our parent's nameSVNAME=$( basename $(
echo `pwd` | sed 's/log//' ) )# bring up svlogd logging into a subdirectory
that has the parent's name.[ -d /var/log/$SVNAME ] || mkdir -p
/var/log/$SVNAME ; chown :adm /var/log/$SVNAME[ -d main ] || ln -s
/var/log/$SVNAME mainexec /usr/bin/svlogd -tt main
> >>
> >> If you are using Gentoo, I would recommend looking at Toki Clover's
> >> implementation at https://github.com/tokiclover/supervision.
> >>
> >> I hope this helps.
> >>
> >
> >
> >
Received on Thu Oct 20 2016 - 18:15:46 UTC