Not that I can think of. Upstart is slightly simpler than systemd to build configuration files for, but that's also because it doesn't have any advanced features like memory/processor/IO limits or the like. Additionally it doesn't even properly manage child processes... so you have to use wrappers to get Unicorn management working right in Upstart.
Upstart took years to add support for setuid/setgrp and still doesn't have basic features like a respawn delay which shipped in launchd (or 90s inetd) before upstart was released. There's still no integrated way to reliably kill malfunctioning child processes and the commands will block until success so you're going to need to kill -9 a lot when e.g. adjusting a script for a daemon which forks.
I was rooting for upstart for years but it's hard to take seriously as a project when basic sysadmin tasks are still gratuitously hard / unreliable.
That's unusafe in production: unless you have a very short-duration problem it'll retry a few times and then pretend you wanted the process stopped. Something like a down database or NFS server will still require you to restart everything in a cluster outside of upstart.
They should have copied prior art from launchd or some inetd implementations where the delay has a back off mechanism with some configurable min/max limits.
Agreed. The inability to specify a restart delay is just silly. It makes that functionality only useful for OOM type issues where the main process dies unexpectedly. Network transition type problems and you're going to have-a-bad-time.
Yeah – things like that or needing a number of major releases before getting reliable console support, setuid/gid, restart not implying start, etc. left me wondering if any actual sysadmins were involved in the development. Most of these would have been on my group's list of basic 1.0 requirements…
Upstart can set resource limits on anything setrlimit(2) offers, including memory and processor. It's not as flexible or reliable as systemd's use of control groups, though.
