Supercronic with LiteFS

1

I tried following the guide about setting up supercronic here: Crontab with Supercronic · Fly Docs

But since I am also using LiteFS, I am not really sure how to set this up. I added the processes section like this:

[processes]
app = “npm start”
cron = “supercronic /app/crontab”

but my app is not starting, all healthchecks fail. Before adding another machine for cron, I just had an empty processes section and it was working fine:

processes =

This is the last line of my Dockerfile:

CMD [“sh”, “-c”, “/usr/sbin/sshd -D -p $SSH_PORT & litefs mount”]

2

Hi… This CMD directive is actually being ignored, since the strings in the [processes] table override it.

Process groups are geared for centralized databases, and as such they rarely “just work” with LiteFS, :dragon:. So, it would probably help to consider the overall question of what your cron jobs really do…

If they’re intended only to SSH into the primary every 24hrs, then this will be relatively straightforward. But if they require direct access to the database then Supercronic will instead need to always be running uniquely on the current primary itself—hopping around and around as handovers occur, :cricket:—a fair amount of effort.

(Or something with litefs run, which is probably very inconvenient with Node.)

Aside: In this forum, you can enclose pasted text in triple backticks (```) to prevent Markdown’s auto-format magic from mangling things (like [] → ).

E.g.,

```text
  [processes]
    app  = "sh -c '/usr/sbin/sshd -D $SSH_PORT & litefs mount'"
             # beware of SIGINT gotchas in the above.
    cron = "supercronic /app/crontab"
```
3

Added litefs

4

Thank you for the quick reply. They definitely need direct access to the database, I want to run a job every minute that checks if some background db operations need to run. Seems like doing this with LiteFS is going to be very complicated. Is there another recommended way to do this?

5

Hm… There might be a middle ground where the cron Machine has read-only access to the database but then SSHes into the primary to perform occasional actual mutation operations (when they do need to fire). The following post from a year ago might give more of an idea of how that would go in terms of LiteFS configuration:

https://community.fly.io/t/litefs-with-more-than-one-processgroup/15829/2

(Caveat: you would also need to tweak lease.candidate; the original poster’s && syntax doesn’t actually work, if I recall correctly.)

Overall, the consensus is that LiteFS is not scintillating when it comes to background workers, even though lightweight ones, for example, can be made to work eventually.

Hope this helps a little!

Aside: Some people are recommending Turso as a more centralized approach to SQLite on Fly.io; I haven’t looked into that much myself, though…

6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.