LOL, well I am trying to do drill test and see how resilience of runit
could be, this is one of the minor downfall.
And yes I did "killall -9 runsv" so simulate it have been kill by whatever
reason.
On Thu, Jun 23, 2016 at 9:37 AM, Colin Booth wrote:
> On Jun 22, 2016 5:39 PM, "Thomas Lau" @
>
On Jun 22, 2016 5:39 PM, "Thomas Lau" @
tetrioncapital.com >
wrote:
>
> here is the run script:
>
> #!/bin/sh
> exec 2>&1
> echo "*** Starting service ..."
> RUNASUSER="tlau"
> RUNASUID=$(getent passwd $RUNASUSER | cut -d: -f3)
> RUNASGROUPS=$(id -G $RUNASUSER | tr ' ' ':')
> exec chpst -u :$RUNAS
here is the run script:
#!/bin/sh
exec 2>&1
echo "*** Starting service ..."
RUNASUSER="tlau"
RUNASUID=$(getent passwd $RUNASUSER | cut -d: -f3)
RUNASGROUPS=$(id -G $RUNASUSER | tr ' ' ':')
exec chpst -u :$RUNASUID:$RUNASGROUPS /usr/bin/memcached -vvv -m 64
I just tested -P, doesn't help and I c
Very interesting that after I change to symlink, it works fine, thanks.
On Jun 22, 2016 11:55 PM, "Avery Payne" wrote:
>
> Hi,
>>
>> Thanks for replying. I don't use symlink, instead I put everything
>> directly
>> on /etc/service/test, then sv start test
>>
>> Try this:
>
> mkdir /etc/svcdef
Hi,
Thanks for replying. I don't use symlink, instead I put everything
directly
on /etc/service/test, then sv start test
Try this:
mkdir /etc/svcdef
mkdir /etc/svcdef/test
mkdir /etc/svcdef/test/log
Put a copy of your test service ./run file into the new directory:
cp /et
On Wed, Jun 22, 2016 at 8:08 AM, Avery Payne wrote:
> It almost sounds like you need to chain-load memcached using chpst. If
> memcached has internal code to change its process group then it is
> "escaping" supervision, which means that runsv is not in direct control of
> it. To fix this, your .
I am try to reproduce situation when runsv under some catastrophic
failure,
when runsv got killed, it will restart, but my test daemon "memcached"
still running on background, eventually it will start memcached twice.
How
could I avoid this from happening? Seems fault handling isn't that
grea
On 22/06/16 03:51, Thomas Lau wrote:
I am try to reproduce situation when runsv under some catastrophic failure,
when runsv got killed, it will restart, but my test daemon "memcached"
still running on background, eventually it will start memcached twice. How
could I avoid this from happening? See
On Tue, 21 Jun 2016 13:36:38 -0400
Steve Litt wrote:
> ... doesn't the bootloader config already contain the
> info to know which device, and isn't that device mounted before the
> initramfs does the switch_root or pivot_root? What do they need udevd
> for? They have the UUID, for gosh sakes.
On
