Upstart – How is it better or worse than the others?

When Upstart was first conceived by Canonical, the prevailing system was still sysvinit, which started everything in sequence and more or less stopped after that. It did make sure that the system closed down gracefully also. This made it necessary to have other solutions for hot-plugging devices such as USB sticks and similar. The main idea from the designers was to make it event-driven, this made it easy to handle the mentioned hot-plugging events. Upstart can also run unmodified sysvinit scripts, so you can migrate to Upstart with only an install. This project is in maintenance mode only so use this post as an interesting piece. You may run into this system in old updated systems.

How does Upstart differ?

Upstart has a model of starting any available job when the event happens. Compare this to systemd, that starts processes that have all the other systems running. The main difference is that Upstart is waiting for events and systemd is coordinating dependencies. Both systems can run regular scripts and both try to start in parallel. Because the differences are so small, Upstart scripts can usually just be called with a systemd service file. They can also, both run unchanged systemV files. In fact, both look for an old systemV file structure by default. The big difference is that Upstart looks for defined events to start anything. So if you want to add your own service, you need to figure out in which context you need your service. Usually this is easy since you will want something that runs, for example, on your desktop. The desktop starts with event runlevel 5, so you set that in your script. For systemd, in contrast, this is the graphical target. In upstart, you also have other events you can use such as mounting, mounted and keyboard request. These are handled with systemd through sockets and dbus.

How do you migrate scripts?

You have all Upstart scripts in /etc/init, their names are job name with a ‘conf’ extension. The scripts are not executable, they just point to one executable or more that should be run. In any Upstart scripts, you have defined on which event the script should start and when it should stop. You should also have pre-start and post-stop entries. These will prepare the environment and clean up after execution. A sample script is below

description "A simple script"
start on runlevel [2345]
stop on runlevel [06]
env SCRIPT_ENV_VAR=‘/path/to/file.config’
chdir /path/to/script/
exec bash

The ‘exec’ statement says what will happen when you start it manually. The start and stop directives defines when the script will start automatically. As you can see, you can also set the directory it will run in. There are many more aspects to Upstart but you should learn how to migrate out.

For this script to work in systemd, you need to create a service file.

Description=A simple script
Environment= SCRIPT_ENV_VAR =/path/to/file.config

Here you can see that the same things happen but with other keywords. The format is simple and to the point. Instead of having runlevels, you point at which target wants your script. This highlights that systemd is all about dependency and starting things for the specific environment. Note also that the ExecStart points to a global path, it never uses a local path.

Where does it excel?

Upstart was designed, for parallel behaviour but it was also designed to be small. If you find this anywhere still it will be in embedded systems and ChromeOS. Yes, ChromeOS had it. The reason is that it was built on top if Ubuntu from the beginning, at the time when Ubuntu had upstart as the default initial system. ChromeOS has since moved on to using Gentoo as their base.


Upstart is an interesting topic but mainly historical. You may need it only if you run into old systems. The most common alternative on Linux is now systemd. If you have reservations regarding systemd, you should look for other minimal systems. One interesting one is the suckless, sinit. It supports three signals and you must write all scripts for it yourself, or modify the scripts from someone else. This can be an interesting exercise but is only useful if you are working on a very minimal and specialised system.

ONET IDC thành lập vào năm 2012, là công ty chuyên nghiệp tại Việt Nam trong lĩnh vực cung cấp dịch vụ Hosting, VPS, máy chủ vật lý, dịch vụ Firewall Anti DDoS, SSL… Với 10 năm xây dựng và phát triển, ứng dụng nhiều công nghệ hiện đại, ONET IDC đã giúp hàng ngàn khách hàng tin tưởng lựa chọn, mang lại sự ổn định tuyệt đối cho website của khách hàng để thúc đẩy việc kinh doanh đạt được hiệu quả và thành công.
Bài viết liên quan

Hướng dẫn cấu hình bản ghi SPF, DKIM, DMARC nâng cấp bảo mật G Suite

Nhằm nâng cấp bảo mật của hệ thống G Suite trước các tình trạng email nặc danh (phishing email),...

Danh sách các nhà xe tuyến HCM đi Dak Lak Và Daklak đi Hồ Chí Minh Cập nhật mới nhất 2021

1 . Xe Dung Nghĩa HCM: (028) 38 461 776 BMT: (0262) 3 811 888 2. Xe Hiệp Trang HCM: (028) 38 55 39 44 – (028) 35...

Cách Nuôi account Ebay mới nhất 2021

Chào anh em hôm nay mình xin chia sẻ cách nuôi tài khoản Ebay hiệu quả vừa tạo một cách hiệu quả...
Bài Viết

Bài Viết Mới Cập Nhật


Mua Proxy v6 US Private chạy PRE, Face, Insta, Gmail

Mua shadowsocks và hướng dẫn sữ dụng trên window

Tại sao Proxy Socks lại được ưa chuộng hơn Proxy HTTP?

Mua thuê proxy v4 nuôi zalo chất lượng cao, kinh nghiệm tránh quét tài khoản zalo