6 ms·

Not a surprise, was there a compelling reason for upstart at all?

by jiggy2011 13y ago

ash 13y ago
Upstart was created before systemd. Edit: Upstart was a great sysvinit replacement, at least during those years before systemd appeared.
- dschulz 13y ago
  That's not compelling.
  - deleted 13y ago
    [deleted]
  - vacri 13y ago
    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.
- rodgerd 13y ago
  upstart was always a mediocre to terrible sysv replacement. The fact it couldn't handle such insignificant programs like postfix natively speaks volumes.
  - ash 13y ago
    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?
    - mercurial 13y ago
      > 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.
    - rodgerd 13y ago
      Sure, if you consider it "fine" that upstart is too broken to reliably run a reasonably standard and fairly important daemon in native mode.
- kazagistar 13y ago
  sysv init was created before upstart, so it clearly must be even better? Your argument makes no sense...
druiid 13y ago
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.
- pjscott 13y ago
  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.
- acdha 13y ago
  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.
  - CameronNemo 13y ago
    >still doesn't have basic features like a respawn delay What are you talking about? http://upstart.ubuntu.com/cookbook/#respawn-limit http://upstart.ubuntu.com/cookbook/#respawn-limit
    - acdha 13y ago
      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.
lmm 13y ago
Systemd isn't portable to non-linux. (And while you may not care about debian kfreebsd, some people do)
- rodgerd 13y ago
  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).
  - asdfs 13y ago
    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.
    - 0x006A 13y ago
      As long as you are willing to sign the copyright license agreement, which was one of the reasons systemd was started instead of improving upstart.
    - rodgerd 13y ago
      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.
  - kelnos 13y ago
    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.
    - slacka 13y ago
CameronNemo 13y ago
systemd breaks LXC and lmctfy. systemd is not event based (matter of taste, I guess, but I prefer Upstart's model).
- herokusaki 13y ago
  Looking at to the Arch wiki (https://wiki.archlinux.org/index.php/Lxc-systemd 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?
- deleted 13y ago
  [deleted]
- SEJeff 13y ago
  What are you talking about? CoreOS uses docker + systemd extensively and docker is just a pretty wrapper ontop of lxc. https://coreos.com/docs/launching-containers/launching/getting-started-with-systemd/ https://coreos.com/docs/launching-containers/launching/getti...
  - tszming 13y ago
    I don't use coreos/systemd but some people run into issues like this: https://github.com/dotcloud/docker/issues/3629 https://github.com/dotcloud/docker/issues/3629
    - ekidd 13y ago
      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.
      - 13y ago

Not a surprise, was there a compelling reason for upstart at all?

ash 13y ago

Upstart was created before systemd. Edit: Upstart was a great sysvinit replacement, at least during those years before systemd appeared.

dschulz 13y ago
That's not compelling.
- deleted 13y ago
  [deleted]
- vacri 13y ago
  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.
rodgerd 13y ago
upstart was always a mediocre to terrible sysv replacement. The fact it couldn't handle such insignificant programs like postfix natively speaks volumes.
- ash 13y ago
  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?
  - mercurial 13y ago
    > 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.
  - rodgerd 13y ago
    Sure, if you consider it "fine" that upstart is too broken to reliably run a reasonably standard and fairly important daemon in native mode.
kazagistar 13y ago
sysv init was created before upstart, so it clearly must be even better? Your argument makes no sense...

druiid 13y ago

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.

pjscott 13y ago
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.
acdha 13y ago
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.
- CameronNemo 13y ago
  >still doesn't have basic features like a respawn delay What are you talking about? http://upstart.ubuntu.com/cookbook/#respawn-limit http://upstart.ubuntu.com/cookbook/#respawn-limit
  - acdha 13y ago
    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.

lmm 13y ago

Systemd isn't portable to non-linux. (And while you may not care about debian kfreebsd, some people do)

rodgerd 13y ago
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).
- asdfs 13y ago
  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.
  - 0x006A 13y ago
    As long as you are willing to sign the copyright license agreement, which was one of the reasons systemd was started instead of improving upstart.
  - rodgerd 13y ago
    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.
- kelnos 13y ago
  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.
  - slacka 13y ago

CameronNemo 13y ago

systemd breaks LXC and lmctfy. systemd is not event based (matter of taste, I guess, but I prefer Upstart's model).

herokusaki 13y ago
Looking at to the Arch wiki (https://wiki.archlinux.org/index.php/Lxc-systemd 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?
deleted 13y ago
[deleted]
SEJeff 13y ago
What are you talking about? CoreOS uses docker + systemd extensively and docker is just a pretty wrapper ontop of lxc. https://coreos.com/docs/launching-containers/launching/getting-started-with-systemd/ https://coreos.com/docs/launching-containers/launching/getti...
- tszming 13y ago
  I don't use coreos/systemd but some people run into issues like this: https://github.com/dotcloud/docker/issues/3629 https://github.com/dotcloud/docker/issues/3629
  - ekidd 13y ago
    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.
    - 13y ago