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

29/12/2020
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]
respawn
env SCRIPT_ENV_VAR=‘/path/to/file.config’
chdir /path/to/script/
exec bash script.sh

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.

Unit]
Description=A simple script
[Service]
Environment= SCRIPT_ENV_VAR =/path/to/file.config
WorkingDirectory=/path/to/script
ExecStart=/usr/bin/bash script.sh
Restart=always
[Install]
WantedBy=multi-user.target

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.

Conclusion

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

Cách lựa chọn proxy provider tốt nhất cho nhu cầu của bạn.

Khi bạn cần sử dụng proxy để truy cập vào các trang web bị chặn hoặc giới hạn về địa chỉ...
27/02/2023

Thuê mua proxy Viettel ở đâu uy tín, chất lượng và giá tốt? 

Thuê mua proxy Viettel là nhu cầu đang được nhiều người dùng đặt ra. Được biết, đây là proxy được...
14/05/2024

Moodle [Part 1] – Triển khai hệ thống Moodle với Onet

Mục lục : Giới thiệu về Moodle – công cụ quản lý học tập trực tuyến hàng đầu Tính năng...
30/12/2020
Bài Viết

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

Reliable IPv4 and IPv6 Subnet Rental Services: The Perfect Solution for Global Businesses
23/12/2024

Tìm Hiểu Về Thuê Proxy US – Lợi Ích và Cách Sử Dụng Hiệu Quả
11/12/2024

Mua Proxy V6 Nuôi Facebook Spam Hiệu Quả Tại Onetcomvn
03/06/2024

Hướng dẫn cách sử dụng ProxyDroid để duyệt web ẩn danh
03/06/2024

Mua proxy Onet uy tín tại Onet.com.vn
03/06/2024