Re: s6 problems logging

[Peter Pentchev]

On Sun, Jan 27, 2019 at 02:27:10PM -0500, Roger Pate wrote:
> 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.

If it is not easy to change the program itself, the stdbuf(1)
utility in recent versions of coreutils might help (of course,
if you use some kind of minimal system, it may not always be
available).

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Essex: A simple command line interface for managing s6 services, using the s6 toolset

[Jonathan de Boyne Pollard]

The |cat| subcommand is the one that seems to get most people.  I have 
seen more objections to that in systemd's |systemctl| than to any of the 
others, because it really isn't concatenation as people are used to.  I 
provide it in my toolset because I provide migration paths for people 
familiar with systemd.  I would not have chosen |cat| myself, if I had 
had the choice.  (It is actually |grep| under the covers, not |cat|, for 
starters.)  If you are /not/ looking to have similar commands as a 
systemd migration path, which seems to be the case from the other 
subcommands that you have, you would probably do well to come up with a 
better name than |cat|.


I went with |reset| rather than |sync|. |preset| sets the /enable/ state 
from configuration information. |reset| sets the /start/ state from 
configuration information, and as the manual says can be thought of as 
"reset to however the service is configured to be at bootstrap" with 
respect to start/stop. |sync| is not a bad name, but |system-control| 
 can 
do /system/-level stuff (e.g. |poweroff|) as well as /service/-level 
stuff, and there is a definite quite different meaning to |sync| when 
one is operating at system level which would not be a good idea to 
overlap.  You're providing service management and not system management, 
and contrastingly are probably alright here.


Your |reload| is not what people have come to know and to think of by 
that name, and will probably confuse people. What people have come to 
know by that name is sending a "reload" signal (of some kind, the exact 
signal varies) to the service telling the service to /keep running/ but 
reload stuff. What you have is more akin to what people know as 
|condrestart| or |try-restart|, although it is not quite those either, 
because (for one thing) they do not have the side-effect of starting 
currently stopped services as your |reload| subcommand does.  See the 
Debian /Policy Manual/ 
 
and the Fedora wiki 
 
for the long standing meanings of the |try-restart| and |reload| 
subcommands.


Placing the generation of the information that your |reload| operates on 
actually in the |run| script itself is a bit of a layering violation.  
Really, a framework to detect changes to |run| scripts should have no 
effect on the |run| scripts contents themselves, certainly not the 
requirement that they be modified to inject special extra commands.  You 
end up with user problems, with users setting up vanilla |run| scripts 
that they get from elsewhere 
 
and then not being able to successfully employ your tools on top of 
that.  You end up with mechanism problems, with a /single change/ to a 
|run| script resulting in potentially /repeated/ termination signals (if 
|reload| is called more than once, which people inevitably /will/ do) 
until the part of the |run| script that regenerates the signature 
actually re-runs, and takes.


Observe how I designed service bundles.  They are layered on top of 
|supervise/| and |service/| directories.  Before/after orderings, 
wants/conflicts dependencies, and the rest are all /outwith/ the 
scripts, and do not require modifying them.  Only |system-control| has 
dealings in them.  The scripts, the lower-level |service-control| 
/|svc|, 
and indeed the |service-manager| 
 
itself, have no notion of /any/ of that.  Indeed, it is one of /two/ 
ways of deciding what services to run, the other of which would be 
adversely affected if all of the scripts had to incorporate tooling for 
the first mechanism.  Maintaining layering allows drop-in replacement, 
and the administrator a choice of the |system-control| way or a 
daemontools-style |service-dt-scanner| 
/|svscan| 
way.


Maintaining layering allows further forms of drop-in replacement, too.  
My nosh toolset does not require that |run| scripts use the toolset's 
own chain-loading utilities.  It is just as happy with |run| scripts 
that use execline, or the perp tools, or runit's |chpst|.  The service 
manager only cares that it's a program that it can |fexecve()|. Whereas 
your tooling forces execline for everything, because you've built it 
around having a snippet of execline code embedded in an execline script 
as a part of the mechanism.


For a restart-if-the-|run|-script-has-changed framework, I suggest a 
similar approach.  The simplest approach is surely to have a per-service 
|Makefile.essex|, or a set of redo |.do| scripts, that embodies the 
if-file-X-changed-take-action-Y