>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.
Indeed. You have two options here that don't require patching:
1. Manually reimplement the rotation logic in /appdata. That is,
modify your processor script so that after it has finished writing
your new archive, it checks whether your /appdata has more than
20 files, and remove the old ones if it does. This is easy enough to
do in shell or even execline.
2. Process and rotate archives normally in /run and sync them to
/appdata after a rotation. For this, you can simply fork a child
after xz has ended, wait one second, then do the copy:
!"if { xz } background { s6-sleep 1 sync-to-appdata }"
where sync-to-appdata does the copy you want.
That means there's a small race condition, but you can reduce the
window as much as you want by increasing the sleep duration. And if
you don't want any race condition at all, don't call sync-to-appdata
from the processor script, but from an inotifyd waiting for
the "processed" file to be renamed (IN_MOVE_FROM) - but that latter
solution is nonportable.
--
Laurent
Received on Mon Oct 30 2017 - 19:00:13 UTC