Re: s6-log configure "current" dir separate from archive dir

From: Brad Grissom <brad_at_bradgrissom.com>
Date: Mon, 30 Oct 2017 08:46:37 -0600

Thanks for the execline processor Laurent. It appears I lose my n20 and
S15728640 ability from my original line:

s6-log -b n20 s5242880 S15728640 !"xz" /appdata

Meaning now my /appdata directory could fill up. In order to get my cake
and eat it too (not have /appdata fill up), I thought maybe a execline
processor that runs rsync or some such thing. The idea being to mirror the
archive files from my RAM-disk in /run to my archive in /appdata.

By the way my C hack to s6-log would be to rename "current" (and
"previous", "lock", etc.) to say "link/current" and then make a symlink:

/appdata $ ln -s /run link

Thanks to John O'Meara for the bitbake repo reference. And thanks to
Laurent for the execline example, I think I have what I need to achieve my
goals.

~~Brad Grissom

On Fri, Oct 27, 2017 at 12:11 PM, Laurent Bercot <
ska-supervision_at_skarnet.org> wrote:

> My RAM-disk is in /run and logging to two separate dirs is of no help
>> because "current" is duplicated in both:
>>
>
> Hi Brad,
> What you want can be achieved by simply writing the output of the
> processor to your archived files directory, ignoring the processor's
> original stdout. This will create an empty archive in the logdir,
> which you can rotate away immediately by telling s6-log you don't
> want any archived files in the logdir (via n0).
> So I would do something akin to this:
>
> s6-log -b n0 s5242880 !./data/processor /run/yourlogdir
>
> And ./data/processor, if you want to keep s6-log's naming scheme,
> could look like:
>
> #!/bin/execlineb -P
> # s6-clock is from s6-portable-utils
> backtick -n NOW { s6-clock }
> importas -u NOW NOW
> redirfd -w 1 /appdata/yourarchivedir/${NOW}.s
> xz
>
> You can also fit the whole script into the !processor argument in
> the s6-log command line; I just separated it for better readability.
>
>
> Also, as a side note, I've ported skalibs, execline, and s6 to the embedded
>> build system Yocto (OpenEmbedded/BitBake) for use on embedded ARM systems.
>>
>
> Nice! Thanks a lot for this.
>
>
> I could submit a
>> pull request, but I'm not sure where to submit them. I suppose the
>> respective .bb files could be checked into each repository. This would be
>> Laurent's call.
>>
>
> My position is that the original repository and tarballs should only
> contain mechanism, not policy - so they shouldn't contain distribution-
> specific files: upstream should remain agnostic. If I started including
> files to accommodate one distribution, I would need to cater to *all*
> distributions, in the name of fairness; that is a burden that no
> upstream can reasonably shoulder, so no upstream does, and so they
> favor some distributions over others, and that increases fragmentation
> of the free software base - which is incredibly damaging. I do not
> want to add to that problem.
>
> So, despite sincerely appreciating your work on bitbake files, I
> just cannot add them to the upstream repositories. The right place
> to store those files is in distributions using Yocto, just as the right
> place to store APKBUILD files is in Alpine's aports system, the
> right place to store debian/ information is in Debian packages, and
> so on.
>
> If the idea of a repository hosting build recipes for skarnet.org
> packages for various distro-building systems appeals to some
> people, it's certainly be possible to create one. However, it would
> definitely have to be community-based - I can create it and give
> push rights, but people need to actually contribute and maintain
> the recipes. :)
>
> --
> Laurent
>
>
Received on Mon Oct 30 2017 - 14:46:37 UTC