Upstart was an event-based replacement for the traditional System V init (sysvinit) system on Ubuntu, introduced to bring a modern and more flexible way of handling system startup and service management. It emerged in the mid-2000s, during a period when sysvinit’s age and limitations were becoming more apparent, especially with regard to concurrency and dependency handling. Upstart was developed by Canonical, the company behind Ubuntu, with the aim of reducing boot times, improving reliability, and making the system initialization process more dynamic. Though at first it seemed likely to become a standard across many distributions, Upstart eventually lost mindshare to systemd and ceased to be Ubuntu’s default init system.
↫ André Machado
I think it’s safe to say systemd won the competition to become the definitive successor to sysvinit on Linux, but Canonical’s Upstart made a valiant effort, too. However, with a troublesome license, it was doomed from the start, and it didn’t help that virtually every other major distribution eventually adopted systemd. These days, systemd is the Linux init system, and I personally quite like it (and the crowd turns violent). I find it easy to use and it’s never given me any issues, but I’m not a system administrator dealing with complex setups, so my experience with systemd is probably rather limited. It just does its thing in the background on my machines.
None of this means there aren’t any other init systems still being actively developed. There’s GNU Shepard we talked about recently, runit, OpenRC, and many more. If you don’t like systemd, there’s enough alternatives out there.
I don’t remember (and cant be bothered to look up) the details, but when I was looking at Upstart as a SysV init replacement for running my own apps/containers as services, the thing that stood immediately out was that the way config files specified dependencies (or was it the activation logic?) was completely backwards.
There is no mention of technical/design differences between Upstart and Systemd in the linked blog post, which I find a glaring omission…
I suggest reading this https://0pointer.de/blog/projects/systemd.html , especially the “upstart” section.
I have worked with systemd as part of my job (though on regular VMs and not on containers, for containers we use Kubernetes), and one of the best things about systemd is the way you specify dependencies: you just specify the dependencies your systemd service wants and systemd makes sure they are there before it starts your service. You don’t have to micromanage boot order. What’s “backwards” about it?
I think he was talking about upstart being backwards
Did it really fail? At one point being used in most major Linux distributions and for ChromeOS, that sounds rather successful. It’s just that another solution came after and replaced it, like it for example happened with PulseAudio. Likely for the same to happen to systemd at some point in the future.
Yes, I wouldn’t say that it failed. I believe it was inspired by macos’s launchd system. and systemd was inspired by it. The problem if you want to call it that, is that upstart was designed before cgroups existed. Cgroups gave the ability to completely manage services with zero possibility of escaping from the management. If it were built on cgroups and it handled dependencies better, I think it would have won the war. But systemd solved the edge cases that upstart couldn’t, and developed a whole ecosystem cleaning up rough bits of linux here and there, ticking off tons of people in the process.
Bill Shooter of Bul,
And to add on top of this… systemd was much more aggressive in their scope. Against all opposition they basically took over entire responsibilities for setting up networking, managing logs (syslog -> journal), scheduling tasks (cron -> timers), even the “desktop session” (x11 config and partially pam).
Of course most of us were concerned and tried to push back. But the convenience that systemd gave to enterprise vendors were undeniable.
I mean once systemd gets superseded by another solution, will we say systemd failed? Did pulseaudio fail when being superseded? Upstart at that point solved a lot of existing problems and was embraced and used by majority of Linux distributions and ChromeOS. That in my book is success. If for example technologies like Wayland, GTK, snapd, flatatpak … ever achieve that, that would be success. Upstart never meant to be as complex as systemd.
I totally agree with you other than the funny inclusion of Wayland on that list. There are a great many distros that practically define themselves by their rejection of systemd. Some yearn for simpler systems. Some, like Chimera Linux, simply think that a similar set of features could be better engineered.
It is fairly easy to find anti-Wayland chatter on Internet forums. However, I cannot think of a single distro that has drawn a line in the sand and said they are not going to move to Wayland. The question is simply when. From a market share perspective, most distros have migrated already.
It seems very, very likely that we are going to exit 2025 with more Linux desktop users using Wayland than are using systemd. But that is hardly because systemd is not successful.
I agree with you on systemd. It is tremendously successful and influential. Even with regards to those that reject it, their is no denying that systemd has resulted in quite a lot of innovation.
I also agree that tools like snap and GTK are nowhere near as universally adopted as systemd. Flatpak is dominating its niche so I could object to that too. However, I feel like it is in a space that has not picked a winner yet.
While perhaps an early scope of systemd was focused on replacing sysv (or whatever at the time) style service daemon startup…. it’s now “everything you need to have what you need for a userspace”. While, that sounds the same, it’s very different. And sometimes why it’s criticized for its bloat (increasing scope).
With that said, even the leaders of systemd get confused and complain about other people’s userspace “things” as not being adequate for “being there” before any other userspace process can run…. I’m serious. If you read that and didn’t understand the lunacy of it…. read it slowly. For example a DE is a massize userspace “thing”, but one could argue that in some cases it’s so important it should be there…. BEFORE anything else. And so the logic would be to incorporate the full DE into systemd. And while that might sound ridiculous, this is the exact logic applied to ever encompass more and more and more into systemd.
Again, systemd needs to control whatever is believed to be required to have a useful userspace experience. Filesystems, networking, …. maybe someday…. a whole desktop environment? Don’t laugh. I could see that coming.
I’m a Red Hat user since the mid-90s. Fedora user since Core 1. Current RHCE. So obviously I’ve been dealing with systemd since its early days. Once you accept it’s the reality and invest the time to learn it, it’s honestly not bad. But I think it adds a load of complexity that is almost entirely unnecessary for a lot of users, especially on the desktop.
I think people’s concern, fairly, is how it’s slowly subsuming all of linux. Everything from systemd-resolved to systemd-homed (!!!).
cmdrlinux,
Same. I’d like systemd more if it stuck to being a simple init system and left other tasks to more specialized daemons. Daemons should be administratively separate and not joined at the hip with the init system. We shouldn’t be forced to use systemd tooling to read and manipulate binary log files.
It works, but I think it would have pleased more people by sticking closer with unix simple tool philosophy.
Disagreed, i don’t want to learn the syntax of 20 different programs and where to put their config files, all those programs being inside systemd group make it standardized . and what’s difference between 20 binaries with different syntax and 20 binaries with standard syntax but you can download it all from the same repo?
vinnde,
All init systems offer a standard, systemd is just a different standard. Most normal users don’t have to look at their config files because their distros have applets to manage their network settings etc. If their needs require them to go to the command line, systemd doesn’t really change that.
Systemd is still 20 different programs though. In my view, they are not all better than what they replace. And nothing is stopping end-users from asking for more consistent interfaces. You do not have to let one utility suite eat the world to get simplicity (especially not if it is an over-engineered one). It is hard to use the BSD utils without coming away thinking that the GNU command-line is a bit of a step back–including using consistency as a measure. This is my opinion only of course (and a recent one as I have only just started using the BSD utils).
I have been using dinit and typing “dinitctl enable service_name” instead of “systemctl enable service_name” does not seem like much of a hardship. On RHEL, which is where @cmdrlinux started us, it is far more confusing that ‘systemctl’ and ‘service’ have a different argument order. Also, am I using NetworkManager, nmcli, systemd-network, or just ip on RHEL? Systemd is contributing to the choas, at least in the short-term.
I get what you are saying though. While diversity is one of the strengths of Linux, it is also a downside if you want to treat “Linux” as the operating system (with all the standardization that implies) instead of the individual distro being the OS that you have to learn (and maybe support).
Even the original design of systemd is quite puzzling. systemd has a number of different dependency relationships whose distinctions are so subtle as to make their rationale for implementation questionable. The systemd implementation of pid1 is rife with this design philosophy where code bloat and lack of discpiline in scope has bloated the whole works.
My experience with upstart was very positive. The couple of versions of ubuntu that I’ve used that had upstart (circa 2012) booted my PC blazingly fast.