What is upstart linux

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

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

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.

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.

About the author

Mats Tage Axelsson

I am a freelance writer for Linux magazines. I enjoy finding out what is possible under Linux and how we can all chip in to improve it. I also cover renewable energy and the new way the grid operates. You can find more of my writing on my blog.

Источник

SysV, Upstart, systemd в роли ассортимента граблей Debian/Ubuntu

Знаете, чем я сейчас занимаюсь? Пишу стартовые скрипты для systemd, и это меня бесит.

Вроде бы как мы берем операционную систему для того, чтобы экономить время на таких вещах. Вроде как пакеты должны были облегчить нам жизнь. Весьма возможно, что мой выбор операционной системы был плох, но до сегодняшнего дня жить в области Debian/Ubuntu мне было вполне комфортно.

С другой стороны, «было» — это условность. Все мы часто находимся в относительном неведении относительно того, как устроена наша операционная система. А однажды увидев код /usr/sbin/service ты уже не можешь развидеть его. Так же как и пользоваться этим инструментом.

Наверное, нужно вернуться обратно. Чтобы понять, как мы оказались в такой заднице со смесью SysV и systemd, приправленной Upstart.

TL; DR: автор ноет по поводу зоопарка из SysV, Upstart и systemd в современных дистрибутивах Debian/Ubuntu.

Казалось бы, что может быть проще? В директории /etc/init.d/ находится файл с именем службы, он отвечает за запуск и остановку. Мы делаем /etc/init.d/service stop или /etc/init.d/service start и все работает отлично.

Операционная система делает то же самое, только в зависимости от runlevel, два — так два, буду последовательно выполнять симлинки из /etc/rc2.d, которые по сути своей ведут к /etc/init.d, жизнь проста и прекрасна. Чтобы управлять последовательностью достаточно изменить сортировку файлов при помощи числа. Есть утилиты, чтобы автоматизировать создание этих симлинков.

Почему мы не могли остаться в том месте? Потому что системы изменились. Они стали, гм, сложными.

Во-первых, состояние системы ранее было практически монолитным, а сегодня может быть изменчивым. Бах — и по USB подключили сетевой адаптер. При Томпсоне такого не было! Надо реагировать, т.е. уведомить службы об этом, кого-то перезапустить, кого-то запустить, кого-то погасить.

Во-вторых, SysV было глубоко плевать на интимную жизнь программ. Он их запускал на старте, но если у тебя что-то не получалось, то это были твои личные проблемы. Отлаживать такие вещи, кстати, практически невозможно. Segmentation fault? Настоящие мужчины пишут программы, которые запускаются с первого раза и не сегфолтят, слабак.

В-третьих, структура зависимостей в SysV была достаточно простая, чего не всегда хватало.

В-четвертых, старт системы не мог быть параллельным. Запуск скриптов был строго последовательный. Это легко увидеть, если посмотреть на время старта OpenSUSE, например, лохматой 12 версии.

Правда, основная особенность SysV была не только в простоте. С простотой приходили проблемы. Например, если у меня каждый запуск скрипта start или stop отдельный, то как узнать, запущена программа или нет? Ведь ей нужно послать сигнал kill, а без PID его посылать некуда.

Свежей идеей было хранить эту цифру в файле .pid, прямо ну серьезно, свежей для своих далеких лет. Однако что делать, если программа вылетела с segmentation fault? Кратко: ничего, PID надо проверить, перед тем, как использовать.

Upstart

Мне кажется, что проблемы начались как раз тут. То есть, с того, как сообщество приняло Upstart. Это и задало дальнейший тон. Но по порядку.

Upstart поддерживал события. Он мог следить и перезапускать программы. Он умел выстраивать зависимости. Ну и с параллельностью у него тоже было все в порядке.

Кроме одной, огромной бочки дегтя, о которой я скажу дальше, я не помню никаких толком претензий к Upstart. А вот бочкой было то, что разработчики софта его в целом проигнорировали.

Почему? Я не знаю. Скорее всего потому, что совместимость с SysV была приоритетом для Upstart. Поэтому разработчикам ничего не нужно было менять.

В итоге, несмотря на то, что Upstart царствовал в Ubuntu 5 лет на протяжении с 2009 до 2014 года, огромное количество софта так и не перешло на него!

С одной стороны, я не могу винить в этом только разработчиков. Они, в конце концов, пишут программы. Как лучше запускать эти программы в системе — не их дело. Однако скрипты для SysV они пишут. Хотите примеров? Посмотрите, на что похож скрипт запуска postfix в Debian. Этот код монструозен, он ужасен, это же просто страшно.

Однако еще страшнее то, что многие администраторы вообще не видят и не понимают разницы. Они пишут:

И свято верят, что apache2 должен стартовать. Аргх, он не должен. Понимаете? Не должен. Запустится утилита /usr/bin/service, которая примется со страшной силой угадывать, как же нужно стартовать эту службу, а потом передаст вашу просьбу SysV или Upstart. Если сможет правильно угадать, ага.

service вообще не часть пакета Upstart. Оно вообще не оттуда, но как-то уживается в этом веселом кругу. Чтобы увеличить количество ада, некоторые разработчики делают скрипты /etc/init.d ссылающимися на Upstart. Эдакий уроборос, чтобы если вдруг администратор из лесу вышел и в Ubuntu 16.04 LTS напишет

Чтобы все работало.

Отдельно следует сказать про PID. Upstart не нужен PID в файле. Почему? Потому что любой запущенный им процесс остается его дочерним. Если вдруг он вылетит, то Upstart об этом узнает. И поскольку команды запуска и остановки тоже проходят через него, то тут нет никакой проблемы.

Однако как быть с сервисами, которым нужен fork? Ну для начала их надо спросить, зачем им это? Ведь в целом, fork применялся в основном для того, чтобы детачнуться от стартовавшего их процесса, но в случае с Upstart это делать незачем. Если у нас умер init, то у нас есть чуть больше проблем, чем неработающий postfix.

Да что уж там, сейчас, когда 16.04 LTS уже здесь, как думаете, при помощи чего стартует Apache2? postfix? Еще куча всякого? SysV.

Правда, в 16.04 им помогает systemd.

systemd

В целом, мне нравится systemd, честно. Его логика мне гораздо приятнее той, что была у Upstart. Правда, если бы еще Debian взяла бы не 215 релиз, а 218, то жить было бы еще лучше, но черт с ним, мы переживем и без команды edit, если надо.

И systemd можно долго ругать, но это уже стандарт. Однако как вы думаете, что делают разработчики с systemd? В основном игнорируют.

Итак, что привнес systemd? Генераторы! Тысячи их!

Кратко, если Upstart не выпендривался, а просто повторял поведение SysV, то systemd до такого не опускается. Он берет существующий /etc/init.d/service и на основе него генерирует скрипт для systemd. Его потом и запускает.

Ну вот как бы да, вот примерно вот так оно и получается. Я не буду рассказывать о том, что это далеко не всегда работает так, как надо. Вернее, стартовать оно стартует. Не вздумайте в каком-нибудь продакшене положиться на рестарт такого сервиса, мониторинг станет вашим лучшим будильником.

И да, вы же понимаете, что systemd тем более не нужен PID, но увы. В сообществе это до сих пор остается толком не понятым.

К разработчикам

Да, ребята, я согласен, еще раз, запуск программы не есть ваша забота. Однако кто, как не вы, лучше знает, как спроектировать беспроблемный старт? Ведь одно дело, если команда старта выглядит так:

А совсем другое, если так:

Давайте перестанем уже размазывать настройки между /etc/config.conf и /etc/default/service?

Давайте перестанем пытаться управлять стартом службы при помощи параметра START=yes в /etc/default/service? Нет, я понимаю, что «xyes» смотрится отличной шуткой, но надоело уже!

Давайте уже решим, что systemd — он везде. И что под него можно смело адаптироваться.

Источник

What is Upstart?

Which operating systems besides Ubuntu use it?

5 Answers 5

Upstart is the replacement for the traditional init.d style System-V bootup scripts. However, upstart is more than just a collection of bootup scripts. It allows in fact a minute planning and control of the start of different daemons. For instance, in order to automount network drives, you need first a working network. While before upstart these situations often led to race conditions, in the upstart declaration the prerequisite of a running network can be included.

Upstart is in fact based on an event monitoring system. When a certain hardware condition occurs, or another process sends an event, one or more of upstarts scripts might be triggered. This allows i.e. particular actions being automatically triggered when an usb stick is inserted or removed.

I believe all major Linux distributions are migrating System-V init to upstart step-by-step. In fact, upstarts can also trigger the start of the traditional init scripts, therefore, the transition does not have to occur all at once.

Upstart is an event-based replacement for the /sbin/init daemon which handles starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running.

The SysV boot process is strictly synchronous. Things happen one at a time, blocking future tasks until the current one has completed. If anything in the boot process takes a long time, everything else has to wait. Additionally tasks only run when the init daemon changes state (such as when the machine is powered on or off).

Upstart is a new init daemon that allows services to be started in response to events rather than in bulk runlevels. With each job file in the /etc/init directory being responsible for launching a service or for a specific component of system initialisation. There is no fixed sequence; instead each job specifies the events to which it will react. When an event occurs, Upstart starts all jobs that have been waiting for this event, in parallel.

You can theoretically use it even after the system is up and running. Upstart is eventually slated to take over tasks such as or plugging in external devices like thumb drives (currently handled by udev and hal), or running programs at specific times (currently handled by cron).

Upstart was originally developed for the Ubuntu distribution, but is intended to be suitable for deployment in all Linux distributions as a replacement for the venerable System-V init.

Источник

The Upstart Event System: What It Is And How To Use It

Published on August 21, 2014

Introduction

Initialization is a crucial procedure that lies at the heart of any Unix-based operating system to control the operation of every script and service. This is essential in a server environment, where issues can occur at the critical points of startup and shutdown, and where ensuring optimal performance is a priority.

In essence, initialization follows this kind of process:

1. The server boots
2. The init process runs (usually as PID 1 )
3. A predefined set of startup tasks activate in sequence

Initialization is responsible for ensuring the cloud server can boot up and shut down cleanly.

Some distributions with a Unix foundation utilize the standard init process for initialization. In this article, we’ll take a look at Upstart – a practical and powerful replacement that can supercharge your server’s operations.

What’s wrong with the classic init?

Traditional initialization follows a linear process: individual tasks load in a predefined sequence as the system boots. This isn’t that helpful, especially in rapidly changing situations. To understand why, imagine that, for example, you modified the server’s environment by adding an additional storage device.

The initialization process isn’t able to take into account sudden changes in environment, meaning that your cloud server would have to be re-initialized before it could recognize the additional storage. On-the-fly detection is what’s needed, although it’s not a capability of classic initialization procedure.

Booting in a linear sequence also takes time, which is especially disadvantageous in a cloud-based environment where fast deployment is essential.

You may also be concerned about the status of your tasks after the system has loaded. Unfortunately, init is concerned with the sequence only when you’re booting up or powering down.

Synchronous boot sequences are no longer desirable. A rigid system could support the systems of yesterday, but today is dynamic.

That’s where Upstart comes in – a solution to these problems with advanced capabilities.

Based on real-time events instead of a preset list of tasks in sequence, this replacement init daemon handles the starting and stopping of tasks and monitors these processes while the system is running – “full coverage” is the best way to describe it.

This newly asynchronous processing eliminates the need for a rigid boot sequence. Real-time processing may be messy to conceptualize, but Upstart can support the most complex of systems and keep everything in check by using a structure of jobs.

An Overview of Upstart

Designed with flexibility from the beginning, the Upstart event system utilizes a variety of concepts that differ from conventional initialization systems. The solution is installed by default on Red Hat Enterprise Linux (RHEL) 6, as well as Google’s Chrome OS, and Ubuntu, although recent debate has caused confusion over whether this will continue.

Jobs

In the world of Upstart, jobs are working processes, split into task jobs (with a purpose) and service jobs (which can run in the background). There are also abstract jobs – processes that run forever, until stopped by a user with administrative privileges.

Events

Events, however, are the signals or “calls” used to trigger a certain action with a job or another event. The common forms of events refer to the monitoring of a process: starting , started , stopping and stopped .

Emitting Events

The process of broadcasting an event is called “emitting.” This is usually caused by a process or job state, although an administrator can also emit an event manually by issuing the initctl emit command. You will notice that the init control command becomes incredibly useful when navigating the plethora of operations associated with Upstart.

Writing Your First Job Configuration

Upstart is known to perform well on Ubuntu, so spin up an Ubuntu 14.04 Droplet before getting started.

Now that you’re ready, it’s important to understand that a job configuration file must abide by three basic principles to be valid.

• It must not be empty (a file with no content)
• It must not contain any syntax errors
• It must contain at least one command block, known as a stanza

Let’s keep it basic for now. In a moment we will create a file called testjob.conf in the /etc/init directory. In this case, “init” is just used as the shortened version of “initialization.”

Notice the .conf file association – indicating that you’ll be writing a job configuration file.

For the purposes of this tutorial, the command-line text editor nano is recommended. Some of these commands may may require administrative privileges with sudo , so check out this article to create an appropriate user.

To create a new configuration file for our test job, run:

Let’s now outline the objective. We want this job to write a message and the current timestamp to a log file.

There are two basic stanzas that can help you define the purpose of a job script and who created it: description and author . Write these as your first lines in the file.

Now, we want this job to take place after the system services and processes have already loaded (to prevent any conflict), so your next line will incorporate the following event:

You may be wondering what a runlevel is. Essentially, it’s a single value that represents the current system configuration. The [2345] refers to all the configuration states with general Linux access and networking, which is ideal for a basic test example.

We will then add the execution code. This line starts with exec to indicate that the following commands should be run through the Bash shell:

Notice this echo command uses backticks to run date as a command and then write the entire message to a log file. If you wrote the word date without backticks, the word itself would be printed instead of the command’s output.

Save and close this file.

You can verify that this works by manually starting the job, but let’s check the configuration file syntax first:

If any issues are detected, this command will indicate the specific line number and the problem. However, with the test job you should see output like this:

This command can be used for controlling Upstart jobs and other background services, such as a web server.

The basic command syntax is:

This syntax works with these basic controls:

• restart: this will stop, then start a service
• start: this will start a service, if it’s not running
• stop: this will stop a service, if it’s running
• status: this will display the status of a service

We want to manually start our test job, so the command should look like this:

Now, check the testjob.log file by running the following command:

This command will read out the file into the shell; you should see a single line similar to the one below:

This shows that your test job is set up and ready to go.

Reboot your Droplet, then log in and read the log file again:

You should see a second line in the log displaying a later timestamp to confirm it ran as an Upstart job.

This merely scratches the surface of what you can do with Upstart. We’ll cover a detailed example later, but for now, let’s move on to an explanation of job states and events.

Job States and Events

System jobs reside in the /etc/init/ directory, and user jobs reside in the user’s own init directory,

User jobs run in the user’s own session, so they’re also known as session jobs. These don’t run system-wide and aren’t in the PID 1 designation. For the purposes of our test job, we used /etc/init so it could load as the system booted.

Regardless of its type, a job is always defined in a configuration file (.conf) where its filename should represent the service or task involved.

Each of these jobs has a goal – to start or stop . Between these two goals are a set of task states, which define the current actions of the job in regards to the goal. The important states are as follows:

• waiting: the initial state of processing
• starting: where a job is about to start
• pre-start: where the pre-start section is loaded
• spawned: where a script section is about to run
• post-start: where post-start operations take place
• running: where the job is fully operational
• pre-stop: where pre-stop operations take place
• stopping: where the job is being stopped
• killed: where the job is stopped
• post-stop: where post-stop operations take place — to clean up

After the post-start state, the job is defined as running. It stays running until a pre-stop is triggered, where the job gets ready to stop, then the job is killed and the post-stop cleanup procedures take place, if defined.

You can view how a job transitions between states by setting the priority of the Upstart system log (located in the /var/log/upstart/ directory) to debug with this command:

Remember that states are not events, and events are not states. The four events (starting, started, stopping and stopped) are emitted by Upstart but the task states define the transition between the stages of a job’s lifetime.

We’re now ready to move on to a more focused example that incorporates elements from your very first configuration by writing a service job. This will demonstrate how you can transition from running basic test configurations to production-ready scripts.

In-Depth Example: A Service Job

Covered briefly in the introduction, a service job involves scripting configuration files that allow processes to run in the background. We’ll be setting up a basic Node.js server from scratch.

If you’re not familiar with Node, in essence it’s a “cross-platform environment for server-side and networking applications” (Wikipedia).

Node.js is a very lightweight package, although it isn’t installed by default on Ubuntu 14.04. To get started, go ahead and install it on your cloud server.

Now, let’s get started with the service job. Create a new job configuration file in /etc/init called nodetest.conf . Naming the file with reference to its purpose is essential, so you’ll be able to recognize that this service job is for a Node.js test.

We’ll cover the Node application itself later in the example, as it’s important to understand the Upstart configuration beforehand.

First things first. Start by entering the job description and author lines to define the configuration.

We want this Node-powered server application to start when the server is up and running and to stop when it shuts down gracefully. Because of this, make sure to specify both conditions:

Remember the runlevel criteria from earlier? Combined with the filesystem event, this will ensure that the job loads when the server is up and running normally.

Those are the basics, but now it gets more complicated; we’re going to use the stanzas we mentioned earlier.

Since this is a server application, we’re going to incorporate a logging element in the job configuration. Because we want to log when the Node application starts and stops, we’ll be using three different stanzas to separate our service actions — script , pre-start script and pre-stop script .

If you think these sound familiar, you’re absolutely right. Pre-start and pre-stop are job states, but they also work in stanzas. What this means is that different commands can be run based on the state the job is in.

However, the first stanza to write is the job script itself. This will get a process ID for the Node background server and then run the application script. Note the indentation of commands inside a stanza – this is essential for syntactically correct formatting.

Node requires a home directory variable to be set, hence why /srv is exported in the first line of the stanza. Next, $$ is used to get an available process ID and create a PID file for our job. After that’s ready, the Node.js application is loaded, which we’ll write later.

It’s now time to focus on pre-start and pre-stop , which will be used for our simple application logging. The date, along with a starting or stopping message will be appended to a log file for our job:

Notice that the pre-stop stanza contains another line: removing the PID file as part of the procedure for shutting down the server (what pre-stop does).

That’s the entire Upstart job configuration sorted; here’s the whole thing again for reference:

Save and close the file.

As noted in the exec line, a Node.js script is run from the server, so create a nodetest.js file in your desired location ( /srv/ is used for this example):

As this is an Upstart tutorial, we won’t spend too long reviewing the Node.js code, although here’s a rundown of what this script will accomplish:

• Require and load Node’s HTTP module
• Create an HTTP web server
• Provide a status 200 (OK) response in the Header
• Write “Hello World” as output
• Listen on port 8888

Here’s the code you need to get the Node application running, which can be copied directly to save time:

After saving the Node.js file, the last thing to check is if the Upstart job syntax is valid. As usual, run the configuration check command and you should receive a confirmation as output:

You’ve got your job configuration, checked its syntax, and have your Node.js code saved — everything’s ready to go, so reboot your Droplet and then visit http://IP:**8888**, or the associated domain.

If you’re met with “Hello World” in the top-left corner of the window, the Upstart service job has worked!

For confirmation of the state-based logging, read the predefined log file and you should see a timestamped Starting line. Shutting the server down or manually stopping the Service Job would write a Stopping line to the log, which you can also check if you wish.

You can run starndard start, stop, restart, etc. commands for this service, and any other similar Upstart jobs, with syntax like the following:

Conclusion

This tutorial only scratches the surface of the Upstart Event System. You’ve read the background on traditional initialization, found out why the open-source Upstart solution is a more powerful choice, and started writing your own jobs. Now that you know the basics, the possibilities are endless.

Logo from Upstart official website, copyright original designers/Canonical Ltd.

Источник