Filespooler is designed to work well in automated situations, including when started from cron or systemd. It is a fairly standard program in that way. I’ll discuss a few thoughts here that may help you architect your system.
Generally, the command you would schedule is
fspl queue-process so that’s the assumption here.
By default, Filespooler produces no output itself on success. The commands it executes may, and Filespooler may also when error conditions occur. This can make it a nice match for cron, which would send emails on output.
One thing to consider is that if you run
fspl queue-process frequently – say every 5 minutes – if you have a job that causes an error, that could cause you to get an email every 5 minutes. You may want some other method of detecting failure – for instance, periodically looking for the presence of jobs in the queue after running queue-process, or perhaps not masking the queue-process output once a day.
Filespooler is designed such that only one
fspl queue-process can run at a time (on a given machine, anyhow). This is helpful in the sense that if a long running job spills over into your next execution, it the next execution will immediately fail with an error rather than cause corruption.
Filespooler itself is very lightweight, but the jobs you execute may not be. If you are using systemd timers, the accompanying .service file can contain
ConditionACPower=true which will only run the queue processor when your mobile device is charging. Very nice.
You may have various considerations for how to handle the output of the commands you execute. See Handling Filespooler Command Output for ideas.
Links to this note
Filespooler lets you request the remote execution of programs, including stdin and environment. It can use tools such as S3, Dropbox, Syncthing, NNCP, ssh, UUCP, USB drives, CDs, etc. as transport; basically, a filesystem is the network for Filespooler. Filespooler is particularly suited to distributed and Asynchronous Communication.