Hi,
Don't you think it will be over engineering.
Like Simon said, Apache can be used as a file transfer app(it has
logging, loading, restarting).
Probably, his small app is an extension of some bigger go app.
His small app can use two different processes which runs under two
different user(you got system level isolation and North Korean hackers
are no more allowed to read unformulated files).
File server app usually never fails. Cron App usually fails, but logs
the error and works for the next cron job. Gocron doesn't seem to have
elegant error handling mechanism. The developer needs to handle them
/somehow/. Gocron will proudly fail if one tasks fails to do error handling.
1. CronApp runs under "cron_user". On success, file permission changes
to allow read to "Ftp_user".
2. Ftp_User simply sees a new file and displays them(delivers). For a
better file server, this one https://github.com/codeskyblue/gohttpserver
As both of these processes have clearly different responsibility, they
don't need to be aware of each other.
On 9/10/2016 15:18, Caleb Doxsey wrote:
Why would you do this manually?
You should use systemd to create a service. It will handle starting on
load, logging, restarting when it crashes, etc.
On Saturday, September 10, 2016 at 7:06:03 AM UTC-4, Simon Ritchie wrote:
> maybe gocron can schedule the http.ListenAndServe to run all the
time?
The classic solution (which is how the Apache web server does it)
is to have a shell script that loops forever, starting the web
server, waiting for it to finish and starting it again. So, if
the server crashes, the parent script starts it again. You set
the starter script up so that it is kicked off when the machine
starts up.
It sounds like this just moves the problem to the parent script,
but actually that doesn't do very much, so it's much easier to
make it (almost) never crash.
The problem then is to make the server stop when you need it to.
That's achieved by making the parent script a signal catcher. One
signal makes it kill its child and then stop. Another makes the
child reread its configuration files and reconfigure itself. You
have another script that sends the signals - the stop script. You
include a call to this in the stuff that is run when the machine
shuts down, so the web server is shut down tidily.
To get all that to hang together, the first parent script records
its PID in a file when it starts. The stop script reads the PID
from the file.
You could do worse than downloading Apache and stealing the
startup and shutdown scripts. They've been in use for twenty
years or more, so they are now fairly robust.
--
You received this message because you are subscribed to the Google
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to golang-nuts+unsubscr...@googlegroups.com
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
Warm Regards,
Asit Dhal
http://asit-dhal.github.io/
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
