Re: Generic interrupt command?

[Roger Pate]

On Mon, Feb 4, 2019 at 10:09 PM John O'Meara  wrote:
> On Sat, Feb 2, 2019, 4:40 PM Steve Litt  wrote:
>> On Sat, 2 Feb 2019 21:08:10 + Colin Booth  wrote:
>>> s6-svstat -p /path/to/service | xargs kill SIGNAL
>>
>> Cool. That's all that's needed.
>
> Be careful, though. If the service is down, kill will use -1 for the PID,
> and will probably signal everything in your system except PID 1.

pid="$(s6-svstat -p /path/to/service)" && kill SIGNAL "$pid"
# avoid gratuitous xargs?

Re: s6 problems logging

[Roger Pate]

On Sun, Jan 27, 2019 at 1:56 PM Sean MacLennan  wrote:
> So it seems that s6-log does not like buffered output. I modified
> doorknob to vsnprintf into a buffer and then tried various output
> methods.

s6-log (or another program) has no idea about your buffered output.
Output cannot be read until it has been written, and data still in a
buffer has not been written.  Change your program to flush after
messages.  It is common for stdio to buffer stdout differently
depending on whether it is a terminal and to not make that distinction
for stderr.  In your terminal, compare "doorknob -fs" (stdout as
terminal) to "doorknob -fs | cat" (stdout as pipe) to see the
difference.

PS. You have "dump" twice where I think you mean "dumb", in your
Github description and in your README.

Re: s6, listen(8), etc.

[Roger Pate]

On Thu, Sep 1, 2016 at 8:34 AM, Laurent Bercot
 wrote:
>  OK, now let's have a look at LISTEN_FDS.

I also find these particular implementation details a poor choice.  I
was going to recommend a different environment convention, but then I
saw the pre-existing convention was copied exactly.

If I was Daniel, I'd create something better.  But I'm not sure
there's enough interest/need to warrant it.  (Daemons currently
written to expect LISTEN_FDS could have a chain-loaded conversion
program.)

Not that I'm particularly knowledgeable here; s6's fdholding seems
able to fill this niche already.

Re: HAProxy Hot Reconfiguration with s6

[Roger Pate]

On Wed, May 18, 2016 at 11:32 PM, Colin Booth  wrote:
> reload.sh:
> #!/bin/sh
> /usr/sbin/haproxy \
> -f /etc/haproxy/haproxy.cfg \
> -f /opt/haproxy-config/combined.cfg \
> -p /tmp/haproxy.pid \
> -sf $(sv s /opt/zsv/jboss/haproxy | awk '{print 
> substr($4,1,length($4)-1)}')
>
> A couple of notes: the -sf option to haproxy is fine with taking a
> null option so you don't need to worry about having two exec lines. If
> you're in a startup or crash restart situation, ./run skips all the
> pid detection stuff and while $HANDOFFPID is empty, like I said it
> doesn't matter. If you're reloading, reload.sh starts a daemonized
> copy of haproxy (this is important, I'll explain in a sec) having dug
> out the process ID of the supervised copy from the output of sv status
> and saving the current pid in a well-known location so that when runsv
> restarts haproxy it's able to re-acquire all its fds.
>
> So, the special note about daemonization. if you run haproxy in
> foreground mode (-db), the -p flag does nothing. Since I need to get
> the process id for a clean hand-back, I can either scrape the pid via
> /proc or ps, or daemonize. Yes there's the standard pidfile race, but
> I figure the 1-2 second turnaround between termination of the
> supervised copy and the give-back is short-enough that it isn't too
> bad.

I don't know HAProxy, but if you want to run from reload.sh without
daemonizing, would this work?

reload.sh:
#!/bin/sh
echo $$ > /tmp/haproxy.pid
exec /usr/sbin/haproxy \
-f /etc/haproxy/haproxy.cfg \
-f /opt/haproxy-config/combined.cfg \
-db \
-sf $(sv s /opt/zsv/jboss/haproxy | awk '{print substr($4,1,length($4)-1)}')