Provide upstart skeleton?

[kvz]

At Transloadit, we're currently generating the following Upstart file to launch tusd:

$ cat /etc/init/tusd.conf
stop on runlevel [016]

respawn
respawn limit 10 5

limit nofile 32768 32768

pre-stop exec status "tusd" | grep -q "stop/waiting" && initctl emit --no-wait stopped JOB="tusd" || true

script
  set -e
  rm -f "/srv/shared/tusd-log-fifo"
  mkfifo "/srv/shared/tusd-log-fifo"
  ( logger --tag "tusd" <"/srv/shared/tusd-log-fifo" & )
  exec >"/srv/shared/tusd-log-fifo"
  rm -f "/srv/shared/tusd-log-fifo"
  exec bash -c "cd /srv/current \
    && source env.sh \
    && exec sudo -HEu transloadit-api2 PATH=\${PATH} LD_LIBRARY_PATH=\${LD_LIBRARY_PATH} \
      /srv/current/stack/bin/tusd \
        -host 127.0.0.1 \
        -port 1080 \
        -base-path /resumable/ \
        -hooks-dir /srv/current/api2/bin/tusd-hooks \
        -max-size 42949672960 \
        -s3-bucket tmp.transloadit.com \
      2>&1"
end script

Then our rsyslog is configured like so:

$ cat /etc/rsyslog.d/49-tusd.conf
if $programname == 'tusd' then /srv/shared/log/tusd.log
if $programname == 'tusd' then @logs.papertrailapp.com:34719
if $programname == 'tusd' then stop # no other actions to avoid duplicates

This handles things like logging (both to local file via syslog as well as centralized to papertrail), running tusd as a non-privileged user, injecting environments with a privileged user, and respawns.

Now this config may not work for everyone. I would also not be surprised if people in the tus community know better ways. And so the thought arises, maybe it's useful to offer a few community curated startup templates, initially for both Upstart and systemd (but that could later be expanded to support other platforms), so that the binary is easier deployed in production environments, and users run tus in a safer, and pretty much all in an identical way.

This could be provided by the tus community either in the form of:

• A developers's guide with some snippets in the best practices, ready for copy/paste.
• In a ./templates/ directory or similar
• In code, so that one could type tusd os_startup or similar, and it would ask some questions, and output the appropriate startup file, that the user could | sudo tee /etc/to/the/right/place (avoiding tusd writing itself and having to ever run it as root)

Thoughts?

[Acconut]

I am not able to maintain such an upstart skeleton for myself, so I feel quite uncomfortable with having something around which I do not understand well enough.

[Acconut]

What do you think if we add an entry to our newly created FAQ section linking to this specific issue for a template to use?

[kvz]

I think that's a good start! I don't think this issue will allow for pleasant iteration though, so i'd be even better to inline the snippet there, so that our peers can spot errors and send PRs against it. Of course, comments can be left here, but I probably wouldn't bother keeping track of a thread like that, vs a single item and latest version that one can look at.

[Acconut]

After thinking a bit more about this, we could add an entry in the newly created docs/ folder containing the upstart configuration alongside some explanation about why certain settings were chosen and how to actually use it. However, having never worked with upstart or systemd I do not see myself capable of writing some a document. Would you, Kevin, have some spare time to write a few sentences up?

[kvz]

Not on the short term, but I can add this to my todo. I feel we could already add the paste, and then iterate on it as we go, applying the McDonalds Theory