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.
There are no working ports of upstart to non-linux, and up until 2 months ago no-one was even trying to. It's about as portable as systemd (i.e. with a bunch of work and if you don't mind forking it).
The difference is that upstream for upstart is open to BSD/Hurd/etc. ports, whereas upstream for systemd is pretty strongly opposed to them and it does not seem they would assist in the effort.
The upstream is GPL + CLA. From a Debian perspective that's something of a non-starter. You could fork it, but then you're in the same position as you would be with systemd.
Moreover systemd has defined a bunch of stable interfaces; one could choose to expose equivalent interfaces in the HURD rather than port. Upstart seems to be in the "implementation = interface" camp.
systemd fairly strongly depends on linux cgroups for process monitoring and management, no? I don't believe there's a suitable analog in any of the BSDs.
BSD has jails and rctl for controlling users resources limits and other analogous tools for process monitoring. The issue is systemd was not designed with portability in mind. Taking full advantage of Linux's features is fine for some distros, but Debian's philosophy has always been grounded in stability and portability.
upstart was always a mediocre to terrible sysv replacement. The fact it couldn't handle such insignificant programs like postfix natively speaks volumes.
> When I wrote "replacement", I didn't mean that all sysv scripts must be replaced. Postfix sysv script works fine with upstart, doesn't it?
I'm honestly not sure if you are making fun of upstart or if you're trying to say that having to keep a sysv compatibility mode around because upstart is not able to handle an extremely common daemon is somehow acceptable.
The 'compelling' reason was "sysv has a ton of problems". Upstart was an earlier attempt to resolves those problems - whether it does those well or not doesn't mean that there wasn't a compelling reason to create it.
Well, that involves running a weird nested stack: The CoreOS systemd, wrapped around a bunch of docker instances, one of which is trying to run the arch Linux systemd inside the container as well.
For what it's worth, Docker containers are generally not complete running machines with their own init system. Instead, they're typically a single top-level process running in an isolated container. Basically, they work more like a Heroku app than complete EC2 machine image.
systemd post 204 requires that it is the only cgroups writer, and tramples over every other writer. Some have said that this is because of a decision by upstream kernel maintainers to allow only one cgroups writer, but this decision has not yet happened. Do you know what version of systemd coreOS uses?
Looking at to the Arch wiki (https://wiki.archlinux.org/index.php/Lxc-systemd) it seems like LXC can be at least partially reconciled with systemd. Are there any features of LXC that absolutely can't be made to work with systemd?
