Running Julia programs as a service/Unix daemon

Is there some package available similar to:

Writing a program to become a well-behaved Unix daemon is somewhat complex and tricky to get right, yet the steps are largely similar for any daemon regardless of what else the program may need to do.

We had a problem with a (Python) web service crashing and I fixed it with:

bash -c 'while true; do python3 ./my_web_server_script.py ; done &

It’s a bit of a hack, so I went looking if there’s a proper way, and the PEP seems to be it. I know the (pros and) cons of my way (e.g. if already started and using the port, and I try to starting this way, the new process tries to serve on the port, fails and retries endlessly; might actually be a pro, if the former process fails, and not started this way…).

The main pro is that that was simple, and you could use that line for julia, substituting python3.

About PEP 3143 -- Standard daemon process library | Python.org

This PEP addresses only Unix-style daemons

I don’t need more, but ideally some library could work cross-platform for Windows services, and whatever macOS does.

I tried to google for Julia found nothing but DaemonMode.jl I knew of (which is strictly for a different problem, while cross-platform in that case).

And API · AWSClusterManagers.jl

A cluster manager which spawns workers via a locally running Docker daemon service.

I’m not really up-to-speed on AWS[ClusterManagers], not using AWS, that it seems only made for (and maybe compatible clouds), nor have I used Docker [daemon service]. Is that the modern way to do cross-platform daemons/services? I think it is, but I want to avoid looking into Docker, for on-prem, unless is for sure simple and the future.

I was also thinking, if I should really be using this library from the PEP, for Python, could I use it with Julia with PyCall.jl? It’s not obvious that it would work e.g. because of signal handling, and PyCall.jl supports all libaries (claims “the ability to directly call and fully interoperate with Python”, so maybe I should just check…? My worry is less PyCall, rather looking into the library itself that may be non-modern way), that are not frameworks, and maybe frameworks too, but that’s I think a rare use-case.