Handbook:x86/working/initscripts

Changing runlevel behavior

Who might benefit

Many laptop users know the situation: at home they need to start net.eth0, but they don’t want to start net.eth0 while on the road (as there is no network available). With Gentoo the runlevel behaviour can be altered at will.

For instance, a second «default» runlevel can be created which can be booted that has other init scripts assigned to it. At boottime, the user can then select what default runlevel to use.

Using softlevel

First of all, create the runlevel directory for the second «default» runlevel. As an example we create the offline runlevel:

Add the necessary init scripts to the newly created runlevel. For instance, to have an exact copy of the current default runlevel but without net.eth0:

(Partial sample Output)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

Even though net.eth0 has been removed from the offline runlevel, udev might want to attempt to start any devices it detects and launch the appropriate services, a functionality that is called hotplugging. By default, Gentoo does not enable hotplugging.

To enable hotplugging, but only for a selected set of scripts, use the rc_hotplug variable in /etc/rc.conf:

FILE Enable hotplugging of the WLAN interface

rc_hotplug="net.wlan !net.*"

NoteFor more information on device initiated services, please see the comments inside /etc/rc.conf.

Edit the bootloader configuration and add a new entry for the offline runlevel. In that entry, add as a boot parameter.

Using bootlevel

Using bootlevel is completely analogous to softlevel. The only difference here is that a second «boot» runlevel is defined instead of a second «default» runlevel.

← Home →

Writing initscripts¶

Do I really have to?

No, writing an init script is usually not necessary as Calculate provides ready-to-use init scripts for all provided services. However, you might have installed a service without using Portage, in which case you will most likely have to create an init script.

Layout

The basic layout of an init script is shown below.

#!/sbin/runscript

depend() {
  (dependency information)
}

start() {
  (commands necessary to start the service)
}

stop() {
  (commands necessary to stop the service)
}

restart() {
  (commands necessary to restart the service)
}

Any init script requires the start() function to be defined. All the other functions are optional.

Dependencies

There are two dependency-alike settings you can define that influence the start-up or sequencing of init scripts: use and need. The need dependency is harder than the use dependency. The name of the service requiring a dependency or a link to a virtual dependency are put after the service’s type.

A virtual dependency is a dependency that a service provides, but that is not provided solely by that service. An init script can depend on a system logger, but there are many system loggers available (metalogd, syslog-ng, sysklogd, …). As you cannot need every single one of them (no sensible system has all these system loggers installed and running), all these services provide a virtual dependency.

Let us take a look at the dependency information for the postfix service.

depend() {
  need net
  use logger dns
  provide mta
}

As you can see, postfix:

• requires the net service: a virtual dependency provided, for instance, by ;
• uses the logger: a virtual dependency provided, for instance, by ;
• uses the dns service: a virtual dependency provided, for instance, by ;
• provides the mta service: a virtual dependency common for all mail servers.

Startup order

Sometimes you do not need the service itself, but that is be started before (or after) another service, if it is enabled (note the if: this is not a dependency any more) and run in the same runlevel (note that this only about services of the same runlevel). This ordering is handled through the order settings before or after.

Let us have a look at the depend() function in the Portmap service:

depend() {
  need net
  before inetd
  before xinetd
}

You can also use «*» to catch all services in the same runlevel, although this is not advisable. Below is an example of running a script as first script in the runlevel:

depend() {
  before *
}

Standard functions

After the depend() functionality, you will also need to define the start() function. It contains all the commands necessary to initialize your service. It is advisable to use the ebegin and eend functions to inform the user about what is happening. Here is a example of a start() function:

start() {
  ebegin "Starting my_service" 
  start-stop-daemon --start --quiet --exec /path/to/my_service
  eend $?
}

If you need more examples of the start() function, please read the source code of the available init scripts in your directory. The start-stop-daemon function has an excellent man page available if you need more information. To view the man page on start-stop-daemon enter:

The stop() and the restart() functions can also be defined. You will not have to define them manually, though! Your init system is intelligent enough to fill in this function by itself if you use start-stop-daemon.

Calculate’s init script syntax is based on the Bourne Again Shell (bash), so you are free to use bash-compatible constructs inside your init script.

Adding custom options

If you want your init script to support more options than the ones we have already encountered, you should add the option to the opts variable, and create a function with the same name as the option. For instance, to support an option called restartdelay:

opts="${opts} restartdelay" 

restartdelay() {
  stop
  sleep 3    # Wait 3 seconds before starting again
  start
}

Service Configuration Variables

You don’t have to do anything to support a configuration file in : if your init script is executed, the following files are automatically sourced (i.e. the variables are available to use):

If your init script provides a virtual dependency (such as net), the file associated with that dependency (such as ) will be sourced too.

Enable and disable

In order to automatically start the init script on boot, it must be installed into /etc/rc.d/ (see above). On recent versions of OpenWrt, the build system will attempt to “enable” and/or “disable” initscripts during package install and removal by itself (refer to default_postinst() and default_prerm() in /lib/functions.sh from package base-files – this thing is utterly undocumented, including how to AVOID the automatic behavior where unwanted), and it will “enable” the initscripts on packages *included* in the ROM images during build, see below.

WARNING OpenWrt initscripts will be run while building OpenWrt images (when installing packages in what will become a ROM image) in the host system (right now, for actions “enable” and “disable”). They must not fail, or have undesired side-effects in that situation. When being run by the build system, environment variable ${IPKG_INSTROOT} will be set to the working directory being used. On the “target system”, that environment variable will be empty/unset. Refer to “/lib/functions.sh” and also to “/etc/rc.common” in package “base-files” for the nasty details.

Invoke the “enable” command to run the initscript on boot:

root@OpenWrt:/# /etc/init.d/example enable

This will create one or more symlinks in which automatically execute at boot time (see Boot process)) and shutdown. This makes the application behave as a system service, by starting when the device boots and stopping at shutdown, as configured in the init.d script.

To disable the script, use the “disable” command:

root@OpenWrt:/# /etc/init.d/example disable

which is configured to remove the symlinks again.

The current state can be queried with the “enabled” command:

root@OpenWrt:/# /etc/init.d/example enabled && echo on
on

Many useful daemons are included in the official binaries, but they are not enabled by default. For example, the daemon is not activated by default, thus only editing the won’t do anything. You have to either start the daemon with or enable it with . You can , and most of those daemons, too. – This might not be true anymore!

To query the state of all init scripts, you can use the command below:

for F in /etc/init.d/* ; do $F enabled && echo $F on || echo $F **disabled**; done

root@OW2:~# for F in /etc/init.d/* ; do $F enabled && echo $F on || echo $F **disabled**; done
/etc/init.d/boot on
/etc/init.d/collectd on
...
/etc/init.d/led on
/etc/init.d/log on
/etc/init.d/luci_statistics on
/etc/init.d/miniupnpd **disabled**
/etc/init.d/network on
/etc/init.d/odhcpd on
...

Скрипт «Hello World!»

Для примера можно создать простейший скрипт, выводящий надпись «Hello World!». Вначале создайте файл и сделайте его исполняемым, а затем отредактируйте в Geany. Скрипт в нашем примере имеет название hello.pl, но вы можете дать ему любое другое имя, как с расширением .pl, так и без.

$ touch hello.pl
$ chmod +x hello.pl
$ geany hello.pl &

Первая строка скрипта определяет путь к интерпретатору Perl, обычно это /usr/bin/perl. Для вывода на экран текста используется команда print. Нужно отметить, что Perl чувствителен к регистру и что каждая строка кода должна заканчиваться точкой с запятой. Вот сам код (вы можете его скопировать и вставить в редактор):

#!/usr/bin/perl
#

print "Hello World!\n";

Чтобы выполнить скрипт, в командной строке наберите

$ ./hello.pl

CGI-скрипты и Perl

CGI-скрипты разработаны для отображения динамически изменяющихся веб-страниц. Язык Perl, ассоциированный с веб-сервером LightTPD, позволяет использовать CGI-скрипты в общем адресном пространстве или в виртуальных машинах. Perl вполне приспособлен к Web 2.0 и может генерировать страницы в формате xHTML. Перед тем как использовать CGI-скрипты в SliTaz, вам нужно установить Perl или Microperl и настроить сервер LightTPD. По умолчанию Shell-скрипты (расширение .sh) помещаются в папку /cgi-bin.

Когда сервер настроен должным образом, можно поместить скрипты в папку $HOME/Public/cgi-bin, задав им расширение .pl или .cgi, и просматривать их на локальном или удаленном компьютере. Пример использования скрипта Perl CGI:

#!/usr/bin/perl
#
print "content-type : text/html\n\n";

print "Hello World!\n";

Скрипты командной строки

Написание скриптов командной строки (shell-скриптов) — самый простой способ начать программировать, т.к. они дают быстрые результаты и всё, что вам нужно уметь, перед тем как садиться писать такой скрипт — это открыть терминал и использовать текстовый редактор: Nano, Leafpad или Geany. Shell-скрипты в Linux способны на многое — загружать систему, делать резервные копии, осуществлять рутинные операции, выводить информацию о системе, создавать и изменять файлы и т.д. В таких скриптах можно использовать переменные, функции или вызовы для запуска того или иного файла. Скрипту можно давать любое удобное для вас имя, при этом широко используется расширение .sh.

Создание shell-скриптов

Перед тем как создавать shell-скрипт, необходимо выяснить, какой интерпретатор используется в системе. Большинство скриптов используют /bin/sh, поскольку он более портативен, но существуют также скрипты, опирающиеся на /bin/bash, поэтому он тоже должен быть установлен в системе. Чтобы скрипт можно было запустить, его нужно сделать исполняемым, изменив его права доступа в командной строке утилитой chmod. Чтобы создать скрипт script.sh и сделать его исполняемым, используйте команды

$ touch script.sh
$ chmod +x script.sh

Получив исполняемый файл, можно приступать к его редактированию. Вы можете оставаться в терминале и использовать редактор Nano (для сохранения и выхода нажмите Ctrl+X) или Leafpad:

$ nano script.sh

$ leafpad script.sh

Ниже приведен скрипт, содержащий переменную NAME и выводящий ее значение командой echo:

#!/bin/sh

NAME="Кеша"

echo "$NAME хороший."

После создания или редактирования скрипта его можно запустить для проверки:

$ ./script.sh

Это было краткое введение в shell-скрипты. В Интернете очень много информации по этой теме, если она вас заинтересует.

Автозапуска скриптов и сервисов с помощью rc.local

Для запуска различных скриптов при загрузке Linux чаще всего используется rc.local.

Но помимо скриптов, через rc.local так же можно и запускать сервисы, даже те, которые запускаются через systemd. Не могу ответить на вопрос, для чего использовать в таком случае rc.local, если есть systemd, но пару примеров я приведу.

Начнем с того, что файл /etc/rc.local должен быть исполняемым:

Rc.local должен быть добавлен в автозагрузку systemd:

И на примере того же nginx, мы можем добавить в rc.local команду запуска веб-сервера:

Но я редко использую rc.local для запуска сервисов. Чаще rc.local используется, когда нужно запустить скрипт, либо выполнить разово какую-то команду.

К примеру, я создал скрипт /root/test.sh который выполняет некоторые действия, и хочу запустить его сразу после запуска системы. Добавляем в файл rc.local строку:

Начиная с CentOS 7, разработчики указывают на то, что rc.local устаревший демон и осуществлять автозапуск скриптов или сервисов через него, это прошлый век. Но пока он работает, я пользуюсь им, так как он очень прост в эксплуатации.

Как проверить поддерживает ли ядро init.d?

1. Установите Busybox
2. Через любой терминал (с помощью ПК или приложение) введите команду: 
3. Если появиться ответ со строкой:  Значит все работает как надо, ядро поддерживает init.d

Где должна быть создана папка init.d в Android для добавления скриптов?

1. Скачайте приложение Root Browser
2. Установите Busybox
3. В приложение Root Browser перейдите в раздел /system/etc
4. Создайте папку init.d
5. Задайте права доступа для папки (Permissions) — rwxr-xr-x или 0755 или буквой «П»
6. Откройте текстовый файл конфигурации build.prop находящийся в корне раздела /system и дописать строку: 

Перезагрузите Android и все готово!

На этом все! Оставайтесь с Android +1 и подписывайтесь в социальные группы! Дальше будет интересней!

Configuring services

Why additional configuration is needed

Init scripts can be quite complex. It is therefore not really desirable to have the users edit the init script directly, as it would make it more error-prone. It is however important to be able to configure such a service. For instance, users might want to give more options to the service itself.

A second reason to have this configuration outside the init script is to be able to update the init scripts without the fear that the user’s configuration changes will be undone.

conf.d directory

Gentoo provides an easy way to configure such a service: every init script that can be configured has a file in /etc/conf.d/. For instance, the apache2 initscript (called /etc/init.d/apache2) has a configuration file called /etc/conf.d/apache2, which can contain the options to give to the Apache 2 server when it is started:

FILE Example options for apache2 init script

APACHE2_OPTS="-D PHP5"

Such a configuration file contains only variables (just like /etc/portage/make.conf does), making it very easy to configure services. It also allows us to provide more information about the variables (as comments).

Systemd: управление автозагрузкой служб в Linux

В большистве популярных современных популярных дистрибутивов Linux (CentOS 7, RHEL, Debian, Fedora и Ubuntu) в качестве демона автозагрузки вместо init.d используется systemd. Systemd – менеджер системы и служб Linux, используется для запуска других демонов и управления ими в процессе работы, использует unit-файлы из /etc/systemd/system (init.d использовал скрипты из каталога /etc/init.d/). Systemd позволяет распараллелить запуск служб в процессе загрузки ОС, тем самым ускоряя запуск.

Для управления system используется команда systemctl.

Для начала, после загрузки системы, мы проверим список юнитов, которые в данный момент добавлены в systemd:

Список unit-файлов можно получить командой:

Данная команда отобразит все доступные юнит-файлы (не зависимо от того, были они загружены в systemd после загрузки ОС или нет).

Чтобы вывести список активных сервисов и их состояние, выполните:

Следующая команда выведет список юнитов, которые загрузил или пытался загрузить systemd. Так как после запуска некоторые юниты могут стать неактивными, с помощью флага —all вы получите полный список.

UNIT LOAD ACTIVE SUB DESCRIPTION
proc-sys-fs-binfmt_misc.automount loaded active waiting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
● exim.service not-found inactive dead exim.service
firewalld.service loaded active running firewalld - dynamic firewall daemon
getty@tty1.service loaded active running Getty on tty1
● ip6tables.service not-found inactive dead ip6tables.service
● ipset.service not-found inactive dead ipset.service
● iptables.service not-found inactive dead iptables.service
Bring up/down networking
● NetworkManager-wait-online.service not-found inactive dead

Как видим из списка, здесь отображаются даже сервисы, которые не были найдены на диске «not-found».

Использую данную команду, вы можете добавить и другие флаги, например:

• —state — используется для определения состояния демона Load, Active, Sub
• —type — позволяет фильтровать юниты по их типу.

Примеры:

— выведет список только активных юнитов

— выведет список юнитов, которые являются сервисом.

Добавление сервиса в systemd

Для управления сервисами в systemd используется особый синтаксис. После имени серверсв в конце нужно указывать .service. Например:

– команда добавит в автозагрузку веб-сервер nginx

Данная команда создаст символическую ссылку на копию файла, указанного в команде сервиса, в директории автозапуска systemd.

Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service

Вывод этой команды показывает в какой директории был создан симлинк на файл сервиса.

Чтобы посмотреть добавлен тот или иной сервис в автозагрузку, можно проверить его статус:

При выводе нужно обратить внимание на строку:

Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)

Значение enabled означает что данный сервис загружается автоматически (добавлен в автозагрузку). Если сервис не загружается автоматом, здесь буде указано disabled.

Удаление сервиса из systemd

Вы можете удалить сервис из автозагрузки, чтобы он не запускался после старта Linux (при этом сам сервис с сервера не удаляется). Чтобы удалить сервис из автозагрузки, выполните команду:

Например, чтобы удалить из автозагрузки nginx, выполните:

Removed symlink /etc/systemd/system/multi-user.target.wants/nginx.service

После выполнения команды, симлинк на файл сервиса будет удален из директории systemd. Можно проверить, есть ли юнит в автозагрузке:

Systemd: маскировка юнитов

В моей практике встречались «вредные» сервисы, которые после удаления их из автозагрузки, все равно там оставались и запускались после рестарта ОС. Чтобы решить этот вопрос, можно замаскировать сервис:

И после этого, он вообще не будет запускаться, ни вручную, ни после перезагрузки ОС:

Created symlink from /etc/systemd/system/nginx.service to /dev/null.

Redirecting to /bin/systemctl restart nginx.service
Failed to restart nginx.service: Unit is masked.

Снять маску можно командой:

Removed symlink /etc/systemd/system/nginx.service.

Если после маскировки сервиса, вы проверите юнит-файлы, то увидите, что сервис помечен как замаскированный (состояние masked):

Таким нехитрым способом, можно избавить себя от удаления сервиса, даже если он не удаляется из автозагрузки systemd.

Изменение поведения уровней запуска

Кто может выиграть?

Большинству пользователей ноутбуков знакома ситуация: дома нужен запуск net.eth0, и наоборот, в дороге запуск net.eth0 не нужен (так как сеть недоступна). В Gentoo можно изменять поведение уровней запуска по своему усмотрению.

Например можно создать второй загружаемый уровень запуска default, в котором будут другие init-скрипты. Затем, при загрузке, можно выбрать, какой из уровней default следует использовать.

Использование программного уровня (softlevel)

Прежде всего, создайте каталог для второго уровня запуска default. Например, создадим уровень запуска offline:

Добавьте необходимые init-скрипты в только что созданный уровень запуска. Например, чтобы получить точную копию уровня default, за исключением net.eth0:

(Partial sample Output)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

Даже несмотря на то, что net.eth0 был удален с уровня запуска offline, udev может попытаться запустить любые устройства, которые найдет, и запустить соответствующие сервисы. Данная функциональность называется hotplugging. По умолчанию, Gentoo отключает hotplugging.

Чтобы включить hotplugging, но только для конкретного набора скриптов, используйте переменную rc_hotplug в /etc/rc.conf:

Файл Включение hotplugging на интерфейсе WLAN

rc_hotplug="net.wlan !net.*"

ЗаметкаДля более детальной информации о сервисах, инициируемых устройствами, просмотрите комментарии в /etc/rc.conf.

Теперь необходимо отредактировать конфигурацию загрузчика, добавив новую запись для уровня запуска offline. В данной записи добавьте в качестве параметра загрузки.

Использование загрузочного уровня (bootlevel)

Использование загрузочного уровня полностью аналогично использованию программного уровня. Единственная разница состоит в том, что определяется второй уровень boot вместо второго уровня default.

← Возможности Portage К содержанию Переменные окружения →

Configuring services¶

Why do you need extra configuring?

Init scripts can be quite complex. It is therefore not really desirable to have the users edit the init script directly, as it would make it more error-prone. It is however important to be able to configure such a service. For instance, you might want to give more options to the service itself.

A second reason to have this configuration outside the init script is to be able to update the init scripts without the risk that your configuration changes will be undone.

The /etc/conf.d directory

Calculate provides an easy way to configure such a service: every init script that can be configured has a file in . For example, the apache2 (called ) has a configuration file called , which can contain the options you want to give to the Apache 2 server when it is started. Here is an example of a variable defined in :

Such a configuration file contains variables and variables alone (like /etc/make.conf), making it very easy to configure services. It also allows us to provide more information about the variables (as comments).

Toolchain — библиотеки, компилятор С и различные утилиты

Чтобы компилировать программное обеспечение из сторонних или ваших собственных исходников, вам понадобится по крайней мере минимальный набор утилит, куда войдут Binutils, Glibc, компилятор С, заголовочные файлы ядра Linux и утилита Make. Toolchain также используется разработчиками SliTaz для сборки системы из исходников. Для установки toolchain со всеми зависимостями введите

# tazpkg get-install slitaz-toolchain

Текущая версия toolchain может без проблем компилировать простые программы в режиме командной строки, используя Ash из состава Busybox, но некоторые программы посложнее потребуют наличия Bash для компиляции. GNU Bash доступен в качестве пакета вместе с другими средствами разработки, например, Flex, M4, Bison или Pkg-config. Если вам нужно найти pkg-config, то используйте команду

$ tazpkg search pkg-config

Если вы хотите компилировать программы, использующие библиотеку Ncurses, потребуется установить пакет ncurses-dev. Этот пакет также имеет в своем составе несколько маленьких программ, к примеру, tic и tac.

$ tazpkg search ncurses

ru/handbook/development.txt · Last modified: 2010/09/21 23:13 by lexeii

Инструкция как в ядро Android добавить поддержку init.d

Способ 1. ОС Windows

1. Ядро boot.img поместить рядом в папку Android Image Kitchen
2. Перетянуть ядро на BAT-скрипт unpackimg.bat, после чего ядро будет разобрано
3. Открыть папку ramdisk и найти файл init.rc, после чего открыть его через Notepad ++
4. Добавить после service bootanim /system/bin/bootanimation …. следующие строки: 
5. Сохранить документ, закрыть Notepad ++, вернуться в папку Android Image Kitchen
6. Запустить Bat-скрипт repackimg.bat после чего будет созданно новое ядро image-new.img
7. Готовое ядро прошить через Fastboot

Подготовка

Установим пакет встраивающий открытие терминала в файловом менеджере

1. Открываем терминал и вводим следующую команду (с версии Ubuntu 15.10 терминал уже встроен в файловый менеджер Nautilus)

Для 32х разрядных систем:

Для 64х разрядных систем:

2. После чего выполнить команду перезапуска файлового менеджера

3. Установить пакет необходимый для работы с ядром Android

В текстовом редакторе Gedit снять галочку с параметра «создание резервной копии»

Работа с ядром

1. Создайте в папке home (Домашняя папка) папку с любым удобным именем и переместите туда ядро Android — boot.img. ( В примере будет указана папка kernel)

2. Перейдите в папку kernel, в любом пустом месте нажмите правую кнопку мыши и выбрать «Открыть в терминале»

3. В открывшемся терминале введите команду:

После чего в папке kernel вы увидите что появились новые файлы (ядро распаковано)

4. Создадим новую папку (назовем ее rw) внутри папки kernel, в терминале пишем

и далее пишем команду для перехода в нее

5. Пишем команду в терминале для дальнейшей распаковки раздела initrd.img

6. После чего в папке rw вы обнаружите множество файлов

7. Найдите и откройте файл init.rc

8. В конце файла добавьте следующие строки

и сохраните файл и выйдете с него

9. В терминале выполняем сборку файла initrd.img, пишем команду

10.  Возвращаемся обратно в папку kernel, для этого в терминале  пишем

11. Собираем ядро Android с внесенными изменениями

и после еще одну команду

Если получаете ошибку что ядро стало большим:

boot.img: updated is too big for the Boot Image

тогда собираем с такой командой

Ядро Android с поддержкой init.d собрано! Далее вам необходимо прошить!

Using rc-update¶

What is rc-update?

Calculate’s initialization system uses a dependency-tree to decide which services need to be started first. As this is a tedious task our users should not have to do manually, tools were created that ease the administration of the runlevels and init scripts.

With rc-update, you can add and remove init scripts to a runlevel. The rc-update tool will then automatically ask the depscan.sh script to rebuild the dependency tree.

Adding and removing services

The rc-update script requires a second argument that defines the action: add, del or show.

To add or remove an init script, just give the rc-update an add or del argument followed by the init script and the runlevel. If you wanted to remove postfix from the default runlevel, you would enter:

If you run rc-update show, a list of all enabled init scripts and their runlevels will be shown:

Perl (Microperl) — создание и использование Perl-скриптов

В SliTaz вы можете использовать мощный скриптовый язык Perl, запустив его как perl или microperl. Microperl — это модернизированная версия Perl, собранная из официальных исходников. Perl-скрипты, использующие Microperl, совместимы с полной версией Perl. Одна из сильных сторон Perl — его портативность: его можно использовать на любой системе и он является интерпретируемым языком, что означает отсутствие необходимости в компилировании кода и возможность его запуска напрямую. В SliTaz Perl и Microperl по умолчанию не входят в состав Live CD, поэтому вам понадобится либо перепаковать Live CD, либо установить Perl через менеджер пакетов. К сведению: Microperl имеет размер всего 1 Мб и не предоставляет модулей. Установку Perl (или Microperl) можно произвести командой

$ tazpkg get-install perl

$ tazpkg get-install microperl

Updating runlevels

rc-update

Gentoo’s init system uses a dependency-tree to decide what service needs to be started first. As this is a tedious task that we wouldn’t want our users to have to do manually, we have created tools that ease the administration of the runlevels and init scripts.

With rc-update it is possible to add and remove init scripts to a runlevel. The rc-update tool will then automatically ask the depscan.sh script to rebuild the dependency tree.

Adding and removing services

In earlier instructions, init scripts have already been added to the «default» runlevel. What «default» means has been explained earlier in this document. Next to the runlevel, the rc-update script requires a second argument that defines the action: , , or .

To add or remove an init script, just give rc-update the or argument, followed by the init script and the runlevel. For instance:

The rc-update -v show command will show all the available init scripts and list at which runlevels they will execute:

It is also possible to run rc-update show (without ) to just view enabled init scripts and their runlevels.

Автозапуск через cron

Если вам с какой-то периодичностью нужно запускать скрипт или команду, вы можете воспользоваться cron-ом:

— открыть терминал для написания задания cron

И добавьте туда нужное вам задание, например:

— запускать скрипт каждую минуту.

Можно написать скрипт watch-dog, который по заданию будет проверять, например, статус какого-либо сервиса и, если он не работает, запускать его. На нескольких своих проектах я использую подобную схему.

Чтобы вывести список всех заданий в крон, нужно выполнить команду:

* * * * * /root/test.sh

Допустимые значения для времени запуска заданий cron по порядку:

• Минуты от 0 до 59
• Часы от 0 до 59
• День месяца от 1 до 31
• Месяц от 1 до 12
• День недели от 0 до 7 (0 или 7 это воскресение)

В нашем задании скрипт запускается каждую минуту, поэтому там стоят «*».

Так же вы можете разместить нужный вам скрипт в директориях cron:

• /cron.daily – выполнение скрипта ежедневно
• /cron.hourly – выполнение скрипта ежечасно
• /cron.monthly — выполнение скрипта ежемесячно
• /cron.weekly — выполнение скрипта еженедельно

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

Changing the runlevel behavior¶

Who benefits from this?

Many laptop users know the situation: at home you need to start net.eth0 while you don’t want to start net.eth0 while you’re on the road (as there is no network available). With Calculate you can alter the runlevel behaviour to your own will.

For instance you can create a second «default» runlevel which you can boot that has other init scripts assigned to it. You can then select at boottime what default runlevel you want to use.

Using softlevel

First of all, create the runlevel directory for your second «default» runlevel. Let us create the «offline» runlevel as an example. We will create the runlevel directory:

Add the necessary init scripts to the newly created runlevel. For instance, if you want to have an exact copy of your current «default» runlevel but without net.eth0, type in:

(copyint all services from default runlevel to offline runlevel)
# cd /etc/runlevels/default
# for service in *; do rc-update add $service offline; done
(removing unwanted service from offline runlevel)
# rc-update del net.eth0 offline
(displaying active services for offline runlevel)
# rc-update show offline
(partial sample output)
               acpid | offline
          domainname | offline
               local | offline
            net.eth0 |

Now edit your bootloader configuration and add a new entry for the «offline» runlevel. For instance, add in :

title Calculate Linux Offline Usage
  root (hd0,0)
  kernel /boot/vmlinuz-5bf7e746 root=/dev/hda3 softlevel=offline

Here you are. If you boot your system and select the newly added entry at boot, the «offline» runlevel will be used instead of the «default» one.

Using bootlevel

Using bootlevel is completely analogous to softlevel. The only difference here is that you define a second «boot» runlevel instead of a second «default» runlevel.