Автозапуск через командную строку: Как добавить файл в автозагрузку через командную строку(реестр) на Windows 10?

Вы можете использовать любую программу, которую хотите запустить при загрузке; для этого урока мы используем пример программы на Python, которая будет говорить при запуске Raspberry Pi.В этом примере программы будет использоваться пакет Espeak , чтобы Raspberry pi говорил «Добро пожаловать в мир роботов».

Если у вас не установлен пакет Espeak , запустите в терминале для установки следующее:

 sudo apt-get install espeak 

Чтобы узнать больше о том, как заставить Raspberry Pi говорить, у нас есть руководство.

В каталоге / home / pi откройте файл для редактирования:

 sudo nano образец.py 

И введите следующий код и сохраните его (нажмите CTRL + X и введите Y).

 #! / usr / bin / env питон
из вызова импорта подпроцесса
call ([‘espeak« Добро пожаловать в мир роботов »2> / dev / null’], shell = True) 

Первый способ запустить программу на Raspberry Pi при запуске — использовать файл rc.local . Чтобы команда или программа выполнялась при загрузке Pi, вы можете добавить команды в rc.локальный файл . Это особенно полезно, если вы хотите включить Pi в автономном режиме (то есть без подключенного монитора) и запустить программу без конфигурации или ручного запуска.

На вашем Pi отредактируйте файл /etc/rc.local с помощью редактора по вашему выбору. Вы должны отредактировать его с правами root:

 судо нано /etc/rc.local 

Добавьте команды для выполнения программы python, предпочтительно с использованием абсолютной ссылки на расположение файла (предпочтительно полный путь к файлу).Обязательно оставьте строку exit 0 в конце, затем сохраните файл и выйдите. В nano для выхода нажмите Ctrl-x, а затем Y.

Если ваша программа работает непрерывно (запускает бесконечный цикл) или, скорее всего, не завершится, вы должны обязательно разветвить процесс, добавив амперсанд («&») в конец команды, например:

 Судо Питон /home/pi/sample.py и 

Pi будет запускать эту программу при загрузке и перед запуском других служб.Если вы не включите амперсанд и ваша программа работает постоянно, Pi не завершит процесс загрузки. Амперсанд позволяет команде запускаться в отдельном процессе и продолжать загрузку с запущенным основным процессом.

Теперь перезагрузите Pi, чтобы проверить его:

 sudo перезагрузка 

Также не забудьте ссылаться на абсолютные имена файлов, а не относительно вашей домашней папки. Например, используйте `/ home / pi / myscript.py` вместо` myscript.py`.

Если вы добавляете сценарий в /etc/rc.local, он добавляется в последовательность загрузки. Если ваш код застревает, последовательность загрузки не может продолжаться. Поэтому будьте осторожны с тем, какой код вы пытаетесь запустить при загрузке, и проверьте его пару раз. Вы также можете записать вывод скрипта и ошибку в текстовый файл (например, log.txt) и использовать его для отладки.

 Судо Питон /home/pi/sample.py &> /home/pi/Desktop/log.txt 2> & 1 

Второй способ запустить программу на Raspberry Pi при запуске — это изменить .bashrc файл. С методом .bashrc ваша программа python будет запускаться при входе в систему (что происходит автоматически, когда вы загружаетесь и переходите непосредственно на рабочий стол), а также каждый раз, когда открывается новый терминал или когда устанавливается новое соединение SSH. сделал. Поместите свою команду в конец «/home/pi/.bashrc». Программа может быть прервана нажатием «ctrl-c» во время ее работы!

 судо нано /home/pi/.bashrc 

Перейти к последней строке скрипта и добавить:

 echo Работает при загрузке
sudo python / home / pi / sample.py 

Приведенный выше оператор echo используется, чтобы показать, что команды в файле .bashrc выполняются при загрузке, а также при подключении к консоли bash.

Теперь перезагрузите Pi, чтобы услышать, как Pi говорит при запуске.

 sudo перезагрузка 

На изображении ниже показано, что команды, добавленные в файл .bashrc, выполняются даже при открытии нового терминала.

Третий способ запустить программу на Raspberry Pi при запуске — это добавить программу (для запуска при загрузке) в файл / etc / init.d каталог. Этот каталог содержит сценарии, которые запускаются во время процесса загрузки (кроме того, все программы здесь выполняются при завершении работы или перезагрузке системы).

Добавьте программу, запускаемую при запуске, в каталог init.d, используя следующие строки:

 судо cp /home/pi/sample.py /etc/init.d/ 

Перейдите в каталог инициализации и откройте образец сценария

 компакт-диск /etc/init.d
sudo nano sample.py 

Добавьте следующие строки в пример сценария, чтобы сделать его сценарием инициализации Linux Standard Base (LSB) (стандарт для структуры программной системы, включая иерархию файловой системы, используемую в операционной системе Linux ).

 # /etc/init.d/sample.py
### НАЧАЛО ИНФОРМАЦИИ
# Предоставляет: sample.py
# Обязательное начало: $ remote_fs $ syslog
# Обязательная остановка: $ remote_fs $ syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Краткое описание: запускать демон во время загрузки
# Описание: включить службу, предоставляемую демоном.
### КОНЕЦ НАЧАЛЬНОЙ ИНФОРМАЦИИ 

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

Вы можете научиться писать сценарии init.d, следуя руководству здесь.

Сделайте образец сценария в каталоге инициализации исполняемым, изменив его права доступа.

 судо chmod + x sample.py 

Выполните эту команду:

 sudo update-rc.d sample.py по умолчанию 

Теперь перезагрузитесь, чтобы услышать, как Pi говорит при запуске.

 sudo перезагрузка 

Четвертый способ запустить программу на Raspberry Pi при запуске — использовать файлы systemd . systemd предоставляет стандартный процесс для управления тем, какие программы запускаются при загрузке системы Linux. Обратите внимание, что systemd доступен только в версиях Jessie Raspbian OS.

Откройте файл образца модуля, используя команду, как показано ниже:

 судо нано /lib/systemd/system/sample.service 

Добавить в следующий текст:

 [Единица]
 Описание = Мой образец услуги
 После = многопользовательский.цель

 [Услуга]
 Тип = простаивает
 ExecStart = / usr / bin / python /home/pi/sample.py

 [Установить]
 WantedBy = multi-user.target 

Вы должны сохранить и выйти из редактора nano.

Это определяет новую службу под названием «Пример службы», и мы просим, ​​чтобы она запускалась, как только многопользовательская среда станет доступной. Параметр «ExecStart» используется для указания команды, которую мы хотим запустить. Для параметра «Тип» установлено значение «бездействие», чтобы команда ExecStart запускалась только тогда, когда все остальное загружено.Обратите внимание, что пути являются абсолютными и определяют полное местоположение Python, а также местоположение нашего скрипта Python.

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

 ExecStart = / usr / bin / python /home/pi/sample.py> /home/pi/sample.log 2> & 1 

Разрешение на файл модуля должно быть установлено на 644:

 sudo chmod 644 /lib/systemd/system/sample.service 

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

 sudo systemctl демон-перезагрузка
sudo systemctl enable sample.сервис 

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

 sudo перезагрузка 

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

Вы можете использовать любой из этих методов для запуска вашей программы при загрузке, если точка, в которой ваш скрипт Python запускается в последовательности запуска, не важна. Если ваш сценарий полагается на какие-либо системные функции, доступные в этот момент времени, такие как подключенная и доступная сеть, каталог / home / pi смонтирован и готов к использованию или системное время было обновлено NTP, тогда это было бы идеально. использовать systemd или init.d методы. Эти методы контролируют точку загрузки, в которой ваш скрипт выполняется во время загрузки.

Ваше желание — моя команда.

Узнать больше

Хотите создать отличные проекты с Raspberry Pi и роботами? Собери свой собственный автомобиль-робот GoPiGo! Посетите нашу страницу проектов, чтобы увидеть больше примеров забавных проектов робототехники с вашим Raspberry Pi!

Есть вопросы? Нужна помощь? Спросите на нашем форуме!

Узнать больше!

Если вам понравился этот учебник, подумайте о том, чтобы получить Raspberry Pi здесь и SD-карту с Raspbian для роботов здесь, чтобы попробовать себя.

Использование сценариев запуска на виртуальных машинах Linux | Документация по Compute Engine

Linux

Сценарий запуска — это файл, который выполняет задачи во время процесса запуска экземпляр виртуальной машины (ВМ). Сценарии запуска могут применяться ко всем виртуальным машинам в проекте. или на одну виртуальную машину. Сценарии запуска, указанные в переопределении метаданных на уровне виртуальной машины сценарии запуска, указанные в метаданных уровня проекта, и только сценарии запуска запускать, когда сеть доступна.В этом документе описывается, как использовать автозагрузку сценарии на экземплярах виртуальных машин Linux. Для получения информации о том, как добавить сценарий запуска на уровне проекта, см. gcloud compute project-info add-metadata .

Для сценариев запуска Linux вы можете использовать файл bash или не-bash. Чтобы использовать не-bash файл, назначьте интерпретатор, добавив #! в начало файла. Для Например, чтобы использовать сценарий запуска Python 3, добавьте #! / usr / bin / python3 наверх файла.

Если вы укажете сценарий запуска с помощью одной из процедур в этом документе, Compute Engine выполняет следующие действия:

1. Копирует сценарий запуска в виртуальную машину

2. Устанавливает разрешения на запуск для сценария запуска

3. Запускает сценарий запуска от имени пользователя root при загрузке виртуальной машины

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

Прежде чем начать

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

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

Порядок выполнения скриптов запуска Linux

Можно использовать несколько сценариев запуска.Скрипты запуска, хранящиеся локально или добавленные непосредственно выполнять перед запуском скрипты, которые хранятся в Облачное хранилище. В следующей таблице показано, на основе ключа метаданных, порядок выполнения сценариев запуска Linux.

Непосредственная передача сценария запуска Linux

Вы можете добавить содержимое сценария запуска непосредственно в виртуальную машину при создании ВМ.Следующие процедуры показывают, как создать виртуальную машину со сценарием запуска. который устанавливает Apache и создает базовую веб-страницу.

Разрешения, необходимые для этой задачи

Для выполнения этой задачи у вас должны быть следующие разрешения:

• Все разрешения, необходимые для создания новой виртуальной машины.
• compute.instances.setMetadata на виртуальной машине.

Консоль

Передача сценария запуска Linux непосредственно новой виртуальной машине

1. В Google Cloud Console перейдите на страницу Create an instance .

   Перейти к созданию экземпляра

2. Для загрузочного диска выберите Изменить и выберите Linux , работающий система.

3. Разверните Сеть, диски, безопасность, управление, единоличное владение раздел и выполните следующее:

   1. Разверните раздел Management .

   2. В разделе Automation добавьте следующий сценарий запуска:

        #! / bin / bash
       подходящее обновление
       apt -y установить apache2
       cat << EOF> / var / www / html / index.html
         
       Сценарий запуска Linux добавлен напрямую. 
        
        

4. Щелкните Создать .

Передача сценария запуска Linux непосредственно на существующую виртуальную машину

1. Щелкните Изменить .

2. В разделе Пользовательские метаданные укажите следующее:

   • ключ : сценарий запуска
   • значение : содержимое сценария запуска

Проверка сценария запуска

После запуска виртуальной машины просмотрите внешний IP-адрес в веб-браузере, чтобы убедиться, что сценарий запуска создал веб-сайт.Возможно, вам придется подождать около 1 минута для завершения примера сценария запуска.

gcloud

Передача сценария запуска Linux непосредственно новой виртуальной машине

Передать содержимое сценария запуска непосредственно виртуальной машине при ее создании. с помощью следующих экземпляров вычислений gcloud создайте команда.

Вычислительные экземпляры gcloud создают  VM_NAME  \
  --image-project = debian-cloud \
  --image-family = debian-10 \
  --metadata = startup-script = '#! / bin / bash
  подходящее обновление
  apt -y установить apache2
  cat << EOF> / var / www / html / index.html
    
 Сценарий запуска Linux добавлен напрямую. 
   '
 

Замените VM_NAME именем виртуальной машины.

Передача сценария запуска Linux непосредственно на существующую виртуальную машину

Добавьте сценарий запуска непосредственно в существующую виртуальную машину, используя следующие gcloud compute instance add-metadata команда:

gcloud compute instance add-metadata  VM_NAME  \
    --metadata = startup-script = '#! / bin / bash
  подходящее обновление
  apt -y установить apache2
  cat << EOF> / var / www / html / index.html
    
 Сценарий запуска Linux добавлен напрямую. 
   '
 

Замените VM_NAME именем виртуальной машины.

Проверка сценария запуска

После запуска виртуальной машины просмотрите внешний IP-адрес в веб-браузере, чтобы убедиться, что сценарий запуска создал веб-сайт. Возможно, вам придется подождать около 1 минута для завершения примера сценария запуска.

API

Передача сценария запуска Linux непосредственно новой виртуальной машине

Передайте содержимое сценария запуска непосредственно виртуальной машине при его создании с помощью с использованием следующих экземпляров.вставка метод.

POST https://compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / zone /  ZONE  / instance

{
  ...
  "networkInterfaces": [
    {
      "accessConfigs": [
        {
          "тип": "ONE_TO_ONE_NAT"
        }
      ]
    }
  ],
  "метаданные": {
    "Предметы": [
      {
        "ключ": "сценарий запуска",
        "value": "#! / bin / bash \ napt update \ napt -y install apache2 \ ncat << EOF> /var/www/html/index.html\n
 Сценарий запуска Linux добавлено напрямую.
   "
      }
    ]
  },
  ...
}
 

Заменить следующее:

Передача сценария запуска Linux непосредственно на существующую виртуальную машину

1. Получить значение tags.fingerprint виртуальной машины с помощью экземпляров . Get метод.

   ПОЛУЧИТЬ https://compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / zone /  ZONE  / instance /  VM_NAME 
    

   Заменить следующее:

2. Передайте сценарий запуска, используя значение отпечатка пальца вместе с ключ метаданных и значение для сценария запуска при вызове экземпляра.setMetadata метод:

   POST https://compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / zone /  ZONE  / instance /  VM_NAME  / setMetadata
   
   {
     «отпечаток пальца»:  FINGERPRINT ,
     "Предметы": [
       {
         "ключ": "сценарий запуска",
         "value": "#! / bin / bash \ napt update \ napt -y install apache2 \ ncat << EOF> /var/www/html/index.html\n
    Сценарий запуска Linux добавлено напрямую. 
      "
       }
     ],
     ...
   }
    

   Заменить следующее:

   • PROJECT_ID : идентификатор проекта

   • ЗОНА : зона ВМ

   • VM_NAME : зона виртуальной машины

   • FINGERPRINT : значение tags.fingerprint получено с помощью экземпляров . get метод

Проверка сценария запуска

После запуска виртуальной машины просмотрите внешний IP-адрес в веб-браузере, чтобы убедиться, что сценарий запуска создал веб-сайт.Возможно, вам придется подождать около 1 минута для завершения примера сценария запуска.

Передача сценария запуска Linux из локального файла

Вы можете сохранить сценарий запуска в локальном файле на своей рабочей станции и передать local как метаданные для виртуальной машины при ее создании. Вы не можете использовать сохраненные файлы на виртуальных машинах в качестве сценариев запуска.

Перед передачей сценария запуска Linux из локального файла в виртуальную машину выполните следующее:

1. Создайте локальный файл для хранения сценария запуска.

2. Обратите внимание на относительный путь от инструмента gcloud до сценария запуска.

3. Добавьте в файл следующий сценарий запуска:

     #! / bin / bash
   подходящее обновление
   apt -y установить apache2
   cat << EOF> /var/www/html/index.html
     
    сценарий запуска Linux из локального файла. 
     
     

Разрешения, необходимые для этой задачи

Для выполнения этой задачи у вас должны быть следующие разрешения:

• Все разрешения, необходимые для создания новой виртуальной машины.
• compute.instances.setMetadata на виртуальной машине.

gcloud

Передача сценария запуска Linux из локального файла в новую виртуальную машину

Создайте виртуальную машину и передайте содержимое локального файла для использования в качестве сценарий запуска с использованием экземпляров gcloud compute create с флагом --metadata-from-file .

Вычислительные экземпляры gcloud создают  VM_NAME  \
  --image-project = debian-cloud \
  --image-family = debian-10 \
  --metadata-from-file = сценарий запуска =  FILE_PATH 
 

Заменить следующее:

Передача сценария запуска Linux из локального файла в существующую виртуальную машину

Передайте сценарий запуска существующей виртуальной машине из локального файла, используя следующие gcloud compute instance add-metadata команда:

gcloud compute instance add-metadata  VM_NAME  \
  --metadata-from-file запуск-скрипт =  FILE_PATH 
 

Заменить следующее:

Проверка сценария запуска

Просмотрите внешний IP-адрес в веб-браузере, чтобы убедиться, что сценарий запуска создан веб-сайт.Возможно, вам придется подождать около 1 минуты для запуска образца сценарий, чтобы закончить.

Передача сценария запуска Linux из облачного хранилища

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

Перед добавлением сценария запуска из сегмента Cloud Storage выполните следующее:

1. Создайте файл для хранения сценария запуска.В этом примере используется bash ( .sh ) файл.

2. Добавьте следующее в файл bash, который устанавливает Apache и создает простая веб-страница:

     #! / bin / bash
   подходящее обновление
   apt -y установить apache2
   cat << EOF> /var/www/html/index.html
     
    Сценарий запуска Linux из облачного хранилища. 
     
     

3. Создайте корзину Cloud Storage.

4. Добавьте файл в корзину Cloud Storage.

Последствия для безопасности

• По умолчанию владельцы и редакторы проектов имеют доступ к Файлы Cloud Storage в том же проекте, если нет явного средства контроля доступа, которые его запрещают.

• Если сегмент или объект облачного хранилища менее безопасны, чем метаданные, существует риск повышения привилегий при изменении сценария запуска и ВМ перезагружается. Это связано с тем, что после перезагрузки виртуальной машины сценарий запуска запускается как root и затем может использовать разрешения подключенной учетной записи службы для доступ к другим ресурсам.

Разрешения, необходимые для этой задачи

Для выполнения этой задачи у вас должны быть следующие разрешения:

• Все разрешения, необходимые для создания новой виртуальной машины.
• compute.instances.setMetadata на виртуальной машине.
• Разрешение на доступ к корзине и файлу сценария в облачном хранилище. Проверьте настройки контроля доступа в корзине и файле, чтобы убедиться, что у вас есть разрешение.

Консоль

Передача сценария запуска, хранящегося в облачном хранилище, на новую виртуальную машину

1. В Google Cloud Console перейдите на страницу Create an instance .

   Перейти к созданию экземпляра

2. Укажите сведения о виртуальной машине.

3. Для Загрузочного диска выберите Изменить и выберите Linux операционная система.

4. В разделе Идентификация и доступ к API выберите учетную запись службы, которая имеет средство просмотра объектов хранилища роль ( ролей / storage.objectViewer ).

5. Разверните Сеть, диски, безопасность, управление, единоличное владение раздел, а затем выполните следующее:

   1. Разверните раздел Management .

   2. В разделе метаданных добавьте следующие значения:

      • Ключ : ключ метаданных. Установите URL-адрес сценария запуска , чтобы добавить сценарий запуска из облачного хранилища.

      • Значение : значение метаданных. Установить в облачное хранилище расположение файла сценария запуска, используя один из следующих форматы:

        • URL-адрес, прошедший аутентификацию : https://storage.googleapis.com/ BUCKET / FILE
        • gsutil URI : gs: // ВЕДРО / ФАЙЛ

        Заменить следующее:

        • BUCKET : название ковша, который содержит файл сценария запуска
        • ФАЙЛ : имя сценария запуска файл

6. Чтобы создать виртуальную машину, щелкните Create .

Передача сценария запуска, хранящегося в облачном хранилище, на существующую виртуальную машину

Отредактируйте ВМ, затем в разделе Пользовательские метаданные используйте следующие значения для метаданных:

Проверка сценария запуска

Просмотрите внешний IP-адрес в веб-браузере, чтобы убедиться, что сценарий запуска создал веб-сайт. Возможно, вам придется подождать около 1 минуты для образца сценарий запуска для завершения.

gcloud

Передача сценария запуска, который хранится в облачном хранилище, на новую виртуальную машину

Передайте сценарий запуска, хранящийся в облачном хранилище, на виртуальную машину, когда вы создайте его с помощью следующих экземпляров gcloud compute create команда.По стоимости флаг --scope , используйте storage-ro , чтобы виртуальная машина могла получить доступ Облачное хранилище.

Вычислительные экземпляры gcloud создают  VM_NAME  \
  --image-project = debian-cloud \
  --image-family = debian-10 \
  --scopes = хранилище-ро \
  --metadata = start-script-url =  CLOUD_STORAGE_URL 
 

Заменить следующее:

• VM_NAME : имя виртуальной машины.

• CLOUD_STORAGE_URL : значение метаданных.Установлен в расположение в облачном хранилище файла сценария запуска, используя один следующих форматов:

  • URL-адрес, прошедший аутентификацию : https://storage.googleapis.com/ BUCKET / FILE
  • gsutil URI : gs: // ВЕДРО / ФАЙЛ

Передача сценария запуска, хранящегося в облачном хранилище, на существующую виртуальную машину

Передайте сценарий запуска, который хранится в облачном хранилище, в существующая виртуальная машина с помощью следующих экземпляров gcloud compute add-metadata команда:

gcloud compute instance add-metadata  VM_NAME  \
  --metadata startup-script-url =  CLOUD_STORAGE_URL 
 

Заменить следующее:

• VM_NAME : имя виртуальной машины.

• CLOUD_STORAGE_URL : значение метаданных. Установлен в расположение в облачном хранилище файла сценария запуска, используя один следующих форматов:

  • URL-адрес, прошедший аутентификацию : https://storage.googleapis.com/ BUCKET / FILE
  • gsutil URI : gs: // ВЕДРО / ФАЙЛ

Проверка сценария запуска

Просмотрите внешний IP-адрес в веб-браузере, чтобы убедиться, что сценарий запуска создал веб-сайт.Возможно, вам придется подождать около 1 минуты для образца сценарий запуска для завершения.

API

Передача сценария запуска, который хранится в облачном хранилище, на новую виртуальную машину

Передача сценария запуска, который хранится в облачном хранилище, на виртуальную машину. при его создании с использованием следующих экземпляров .insert метод. К прицелам добавьте https://www.googleapis.com/auth/devstorage.read_only , чтобы виртуальная машина может получить доступ к облачному хранилищу.

POST https: // compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / зонах /  ЗОНА  / экземпляров

{
  ...
  "networkInterfaces": [
    {
      "accessConfigs": [
        {
          "тип": "ONE_TO_ONE_NAT"
        }
      ]
    }
  ],
  "serviceAccounts": [
    {
      "электронная почта": "по умолчанию",
      "области": [
        "https://www.googleapis.com/auth/devstorage.read_only"
      ]
    }
  ],
  "метаданные": {
    "Предметы": [
      {
        "ключ": "URL-адрес сценария запуска",
        "значение": " CLOUD_STORAGE_URL "
      }
    ]
  },
  ...
}
 

Заменить следующее:

• PROJECT_ID : идентификатор проекта.

• ЗОНА : зона для создания новой виртуальной машины.

• CLOUD_STORAGE_URL : значение метаданных. Установлен в расположение в облачном хранилище файла сценария запуска, используя один следующих форматов:

  • URL-адрес, прошедший аутентификацию : https://storage.googleapis.com/ BUCKET / FILE
  • gsutil URI : gs: // ВЕДРО / ФАЙЛ

Передача сценария запуска, хранящегося в облачном хранилище, на существующую виртуальную машину

1. Получите теги .значение отпечатка виртуальной машины с использованием экземпляров . get метод.

   ПОЛУЧИТЬ https://compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / zone /  ZONE  / instance /  VM_NAME 
    

   Заменить следующее:

2. Передайте сценарий запуска, используя значение отпечатка пальца вместе с ключ метаданных и значение для сценария запуска при вызове instance.setMetadata метод:

   POST https: // compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / zone /  ZONE  / instance /  VM_NAME  / setMetadata
   
   {
     «отпечаток пальца»:  FINGERPRINT ,
     "Предметы": [
       {
           "ключ": "URL-адрес сценария запуска",
           "значение": " CLOUD_STORAGE_URL "
       }
     ],
     ...
   }
    

   Заменить следующее:

   • PROJECT_ID : идентификатор проекта.

   • ЗОНА : зона ВМ.

   • VM_NAME : зона виртуальной машины.

   • FINGERPRINT : значение tags.fingerprint получено с помощью экземпляров . get метод.

   • CLOUD_STORAGE_URL : значение метаданных. Установлен в расположение в облачном хранилище файла сценария запуска, используя один следующих форматов:

     • URL-адрес, прошедший аутентификацию : https://storage.googleapis.com/ BUCKET / FILE
     • gsutil URI : gs: // ВЕДРО / ФАЙЛ

Проверка сценария запуска

Просмотрите внешний IP-адрес в веб-браузере, чтобы убедиться, что сценарий запуска создал веб-сайт.Возможно, вам придется подождать около 1 минуты для образца сценарий запуска для завершения.

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

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

1. Создайте сценарий запуска, который запрашивает значение ключа метаданных. Для Например, следующий файл bash (.sh ) сценарий запуска запрашивает значение параметра foo ключ метаданных.

   #! / bin / bash
   METADATA_VALUE = $ (curl http: //metadata.google.internal/computeMetadata/v1/instance/attributes/foo -H "Metadata-Flavor: Google")
   подходящее обновление
   apt -y установить apache2
   cat << EOF> /var/www/html/index.html
     
    Доступ к значению метаданных foo: $ METADATA_VALUE 
     
    

2. Установите значение ключа метаданных foo при создании виртуальной машины с помощью следующие экземпляров вычислений gcloud создают команда.В этом примере сценарий запуска передается виртуальной машине из локального файла.

   gcloud

   Вычислительные экземпляры gcloud создают  VM_NAME  \
     --image-project = debian-cloud \
     --image-family = debian-10 \
     --metadata-from-file = startup-script =  FILE_PATH  \
     --metadata = foo = bar
    

   Заменить следующее:

   Для получения дополнительной информации о том, как указать пару ключ / значение метаданных, см. Установка собственных метаданных.

3. На локальной рабочей станции просмотрите внешний IP-адрес в веб-браузере, чтобы убедиться, что сценарий запуска выводит значение foo .Возможно, вам придется подождать около 1 минута для завершения примера сценария запуска.

Повторный запуск сценария запуска Linux

Перезапустите сценарий запуска, выполнив следующие действия:

1. Подключение к ВМ.

2. Выполнение следующей команды:

     sudo google_metadata_script_runner запуск 
    

Просмотр вывода сценария запуска Linux

Вы можете просмотреть вывод сценария запуска Linux, выполнив любое из следующее:

Что дальше

Как автоматически запускать команды и сценарии Linux при перезагрузке системы

 sudo apt установить gnome-tweak-tool 

 sudo apt-get install gnome-tweak-tool 

 sudo pacman -S инструмент gnome-tweak 

 sudo dnf установить инструмент gnome-tweak 

 sudo zypper установить gnome-tweak-tool 

 cd / usr / share / applications / 

 лс 

 ls | grep 'имя программы' 

 mkdir -p ~ / .config / автозапуск /

cp имя программы.desktop ~ / .config / autostart / 

 sudo chmod + x ~ / .config / autostart / имя_программы.desktop 

 cd ~ / .config / autostart 

 лс 

 rm имя программы.desktop 

 
 #! / Usr / bin / bash 
 # Простая программа для тестирования конфигураций запуска 
 # с systemd.
 # Дэвид Оба 
 # Лицензия GPL V2 
 # 
 echo "#############################" 
 echo "######### Hello World! ########" 
 echo "######################## ###### "
 

 
 [root @ testvm1 ~] # hello.sh 
 ############################## 
 ##### #### Привет, мир! ######## 
 ############################## 
 [root @ testvm1 ~] # 
 

 # Простой служебный файл модуля для тестирования 
 # конфигураций запуска с помощью systemd. 
 # Дэвид Оба 
 # Лицензия GPL V2 
 # 
 [Unit] 
 Описание = My hello shell script 
 
 [Service] 
 Type = oneshot 
 ExecStart = / usr / local / bin / hello.sh 
 
 [Установить ] 
 WantedBy = многопользовательский.цель 
 

 
 [root @ testvm1 ~] # systemctl status hello.service 
 ● hello.service - мой сценарий оболочки hello 
 Загружено: загружено (/etc/systemd/system/hello.service; отключено; предустановка поставщика: отключено) 
 Активно: неактивный (мертвый) 
 [root @ testvm1 ~] # 
 

 [root @ testvm1 ~] # статус systemctl hello.service 

● hello.service - мой сценарий оболочки hello 

Загружено: загружено (/etc/systemd/system/hello.service; отключено; предустановка поставщика: отключено) 

Активный: неактивный (мертвый) 
 6 мая 08:50:09 testvm1.both.org systemd [1]: /etc/systemd/system/hello.service:12: Не удалось проанализировать тип службы, игнорирование: neshot 
 [root @ testvm1 ~] # 
 

 [root @ testvm1 ~] # systemctl start привет.служба 
 [root @ testvm1 ~] # systemctl status hello.service 

● hello.service - мой сценарий оболочки hello 

Загружено: загружено (/etc/systemd/system/hello.service; отключено; предустановка поставщика: отключено) 

Активный: неактивный (мертвый) 
 10 мая 10:37:49 testvm1.both.org hello.sh [842]: ######### Hello World! ######## 
 10 мая 10:37:49 testvm1.both.org hello.sh [842]: ###################### ######### 
 10 мая 10:37:49 testvm1.both.org systemd [1]: hello.service: Успешно. 
 10 мая 10:37:49 testvm1.both.org systemd [1]: Завершено Сценарий оболочки моего приветствия. 
 10 мая 10:54:45 testvm1.both.org systemd [1]: Запуск сценария оболочки My hello ... 
 10 мая 10:54:45 testvm1.both.org hello.sh [1380]: #### ########################### 
 10 мая 10:54:45 testvm1.both.org hello.sh [1380]: ### ###### Привет, мир! ######## 
 10 мая 10:54:45 testvm1.both.org hello.sh [1380]: ##################### ######### 
 10 мая 10:54:45 testvm1.both.org systemd [1]: hello.service: Успешно. 
 10 мая 10:54:45 testvm1.both.org systemd [1]: Завершено Сценарий оболочки моего приветствия. 
 [root @ testvm1 ~] # 
 

 
 [root @ testvm1 ~] # journalctl -t hello.sh 
  
 - Перезагрузка - 
 8 мая, 15:55:47 testvm1.both.org hello.sh [840]: ##### ######################### 
 8 мая 15:55:47 testvm1.both.org hello.sh [840]: #### ##### Привет, мир! ######## 
 8 мая 15:55:47 testvm1.both.org hello.sh [840]: ############################# 
 - Перезагрузка - 
, 8 мая. 16:01:51 testvm1.both.org hello.sh [840]: ############################## 
 май 08 16:01:51 testvm1.both.org hello.sh [840]: ######### Hello World! ######## 
 8 мая 16:01:51 testvm1.both.org hello.sh [840]: ###################### ######### 
 - Перезагрузка - 
 10 мая 10:37:49 testvm1.both.org hello.sh [842]: ############### ################ 
 10 мая 10:37:49 testvm1.both.org hello.sh [842]: ######### Hello World! ######## 
 10 мая 10:37:49 testvm1.both.org hello.sh [842]: ############################## 
 10 мая 10:54:45 testvm1 .both.org hello.sh [1380]: ############################## 
 10 мая 10:54:45 testvm1.both.org hello.sh [1380]: ######### Привет, мир! ######## 
 10 мая 10:54:45 testvm1.both.org hello.sh [1380]: ##################### ######### 
 [root @ testvm1 ~] # 
 

 
 [root @ testvm1 ~] # journalctl -b -t systemd 
  
 10 мая 10:37:49 testvm1.both.org systemd [1]: Запуск SYSV: Поздний сценарий инициализации для живого образа .... 
 10 мая 10:37:49 testvm1.both.org systemd [1]: запущен SYSV: сценарий поздней инициализации для живого образа .. 
 10 мая 10:37:49 testvm1.both.org systemd [1]: hello.service : Успешно. 
 10 мая, 10:37:49 testvm1.both.org systemd [1]: завершено Мой сценарий оболочки hello.
 10 мая 10:37:50 testvm1.both.org systemd [1]: запуск шины системных сообщений D-Bus ... 
 10 мая 10:37:50 testvm1.both.org systemd [1]: запущен D-Bus Системная шина сообщений. 
 

 
 [root @ testvm1 ~] # journalctl -b -t systemd -g "hello" 
 [root @ testvm1 ~] # journalctl -b -t systemd -g "hello" 
 - Журналы начинаются во вторник 2020-05- 05 18:11:49 EDT, конец в Sun 2020-05-10 11:01:01 EDT. - 
 10 мая 10:37:49 testvm1.both.org systemd [1]: Запуск сценария оболочки My hello ... 
 10 мая 10:37:49 testvm1.both.org systemd [1]: hello.service: Удалось. 
 10 мая 10:37:49 testvm1.both.org systemd [1]: Завершено Сценарий оболочки моего приветствия. 
 10 мая 10:54:45 testvm1.both.org systemd [1]: Запуск сценария оболочки My hello ... 
 10 мая 10:54:45 testvm1.both.org systemd [1]: hello.service: Успешно. 
 10 мая 10:54:45 testvm1.both.org systemd [1]: завершено Мой сценарий оболочки hello. 
 [root @ testvm1 ~] # 
 

 
 [root @ testvm1 ~] # journalctl --since = "2020-05-10 10:54:00" 
 10 мая 10:54:35 testvm1.both.org audit: BPF prog-id = 54 op = LOAD 
 10 мая 10:54:35 testvm1.both.org audit: BPF prog-id = 55 op = LOAD 
 10 мая 10:54:45 testvm1.both. org systemd [1]: Запуск сценария оболочки My hello ... 
 10 мая 10:54:45 testvm1.both.org hello.sh [1380]: ############### ############### 
 10 мая 10:54:45 testvm1.both.org hello.sh [1380]: ######### Hello World! ######## 
 10 мая 10:54:45 testvm1.both.org hello.sh [1380]: ###################### ######### 
 10 мая 10:54:45 testvm1.both.org systemd [1]: привет.сервис: Успешно. 
 10 мая 10:54:45 testvm1.both.org systemd [1]: завершено Мой сценарий оболочки hello. 
 10 мая 10:54:45 testvm1.both.org audit [1]: SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = hello comm = "systemd" exe = "/ usr / lib / systemd "'
 10 мая 10:54:45 testvm1.both.org audit [1]: SERVICE_STOP pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg =' unit = hello comm =" systemd "exe =" / usr / lib / systemd / "'
 10 мая, 10:56:00 testvm1.both.org NetworkManager [840]: <ошибка> [158
60.0633] dhcp4 (enp0s3): ошибка -113 отправка событий 
 10 мая 10:56:00 testvm1.both.org NetworkManager [840]:  [158
60.0634] dhcp4 (enp0s3): граница состояния изменена -> сбой 
  
 
 Спецификация , начиная с  пропускает все записи до этого времени, но после этого времени все еще остается много записей, которые вам не нужны. Вы также можете использовать опцию от  до , чтобы обрезать записи, которые появляются немного позже интересующего вас времени.Мне нужна вся минута, когда произошло событие, и не более:
 
 [root @ testvm1 ~] # journalctl --since = "2020-05-10 10:54:35" --until = "2020-05-10 10:55:00" 
 - Регистрация начинается во вторник 2020 г. -05-05 18:11:49 EDT, конец в Sun 2020-05-10 11:04:59 EDT. - 
 10 мая, 10:54:35 testvm1.both.org systemd [1]: Перезагрузка. 
 10 мая 10:54:35 testvm1.both.org audit: BPF prog-id = 27 op = UNLOAD 
 10 мая 10:54:35 testvm1.both.org audit: BPF prog-id = 26 op = UNLOAD 
 < snip> 
 год 10 10:54:35 testvm1.аудит both.org: BPF prog-id = 55 op = ЗАГРУЗИТЬ 
 10 мая 10:54:45 testvm1.both.org systemd [1]: Запуск сценария оболочки My hello ... 
 10 мая 10:54:45 testvm1. both.org hello.sh [1380]: ############################## 
 10 мая 10:54:45 testvm1 .both.org hello.sh [1380]: ######### Hello World! ######## 
 10 мая 10:54:45 testvm1.both.org hello.sh [1380]: ##################### ######### 
 10 мая 10:54:45 testvm1.both.org systemd [1]: hello.service: Успешно. 
 10 мая 10:54:45 testvm1.both.org systemd [1]: завершено Мой сценарий оболочки hello.
 10 мая 10:54:45 testvm1.both.org audit [1]: SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = hello comm = "systemd" exe = "/ usr / lib / systemd> 
 10 мая 10:54:45 testvm1.both.org audit [1]: SERVICE_STOP pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = hello comm = "systemd" exe = "/ usr / lib / systemd /> 
, строки 1-46 / 46 (КОНЕЦ) 
 
 Если в этот период времени было много активности, вы могли бы еще больше сузить результирующий поток данных, используя комбинацию этих опций:
 
 [root @ testvm1 ~] # journalctl --since = "2020-05-10 10:54:35" --until = "2020-05-10 10:55:00" -t "привет.sh "
 - Журналы начинаются во вторник 2020-05-05 18:11:49 EDT, заканчиваются вс 2020-05-10 11:10:41 EDT. - 
 мая 10 10:54:45 testvm1.both. org hello.sh [1380]: ############################## 
 10 мая 10:54:45 testvm1.both .org hello.sh [1380]: ######### Hello World! ######## 
 10 мая 10:54:45 testvm1.both.org hello.sh [1380]: # ############################# 
 [root @ testvm1 ~] # 
 
 Ваши результаты должны быть похожи на мои. Из этой серии экспериментов видно, что служба работает правильно.
 Перезагрузка - наконец 
 Пока вы не перезагружали хост, на котором установили службу. Так что сделайте это сейчас, потому что, в конце концов, это руководство посвящено запуску программы при запуске. Во-первых, вам нужно разрешить запуск службы во время последовательности запуска:
 
 [root @ testvm1 ~] # systemctl enable hello.service 
 Создана символическая ссылка /etc/systemd/system/multi-user.target.wants/hello.service → /etc/systemd/system/hello.service. 
 [root @ testvm1 ~] # 
 
 Обратите внимание, что ссылка была создана в  / etc / systemd / system / multi-user.target. хочет каталог . Это связано с тем, что файл служебной единицы указывает, что служба «требуется» для  multi-user.target .
 Перезагрузитесь и обязательно следите за потоком данных во время последовательности запуска, чтобы увидеть сообщение «Hello world». Подождите ... вы этого не видели? Что ж, я тоже. Хотя это прошло очень быстро, я увидел сообщение systemd о том, что он запускает  hello.service .
 Посмотрите журнал с момента последней загрузки системы. Вы можете использовать инструмент поиска пейджера  минус , чтобы найти «Привет» или «Привет."Я удалил много строк данных, но оставил некоторые из окружающих записей журнала, чтобы вы могли почувствовать, как записи, относящиеся к вашей службе, выглядят локально:
 
 [root @ testvm1 ~] # journalctl -b 
  
 10 мая 10:37:49 testvm1.both.org systemd [1]: прослушивание сокета ответчика SSSD Kerberos Cache Manager. 
 10 мая, 10:37:49 testvm1.both.org systemd [1]: достигнуты целевые сокеты. 
 10 мая, 10:37:49 testvm1.both.org systemd [1]: достигнута целевая базовая система.
 10 мая 10:37:49 testvm1.both.org systemd [1]: запуск диспетчера модема ... 
 10 мая 10:37:49 testvm1.both.org systemd [1]: запуск диспетчера сети ... 
 мая 10 10:37:49 testvm1.both.org systemd [1]: Запуск стека Avahi mDNS / DNS-SD ... 
 10 мая 10:37:49 testvm1.both.org systemd [1]: проверка условий завершилась безопасностью Пропускается загрузочная программа обновления DBX (черный список). 
 10 мая 10:37:49 testvm1.both.org systemd [1]: Запуск сценария оболочки My hello ... 
 10 мая 10:37:49 testvm1.both.org systemd [1]: Запуск межсетевого экрана IPv4 с помощью iptables... 
 10 мая 10:37:49 testvm1.both.org systemd [1]: запущен демон irqbalance. 
 10 мая 10:37:49 testvm1.both.org audit [1]: SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = irqbalance comm = "systemd" exe = "/ usr / lib / sy> "'
 10 мая 10:37:49 testvm1.both.org systemd [1]: Запуск LSB: сценарий инициализации для живого образа .... 
 10 мая 10:37:49 testvm1.both.org systemd [1 ]: Запуск датчиков мониторинга оборудования ... 
  
 10 мая 10:37:49 testvm1.both.org systemd [1]: Запуск клиента / сервера NTP... 
 10 мая 10:37:49 testvm1.both.org systemd [1]: Запуск SYSV: сценарий поздней инициализации для живого образа .... 
 10 мая 10:37:49 testvm1.both.org systemd [1] : Запущен SYSV: Поздний сценарий инициализации для живого образа .. 
 10 мая 10:37:49 testvm1.both.org audit [1]: SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = lifeys- late comm = "systemd" exe = "/ usr / lib />" '
 10 мая 10:37:49 testvm1.both.org hello.sh [842]: ############# ################## 
 10 мая, 10:37:49 testvm1.both.org hello.sh [842]: ######### Hello World! ######## 
 10 мая 10:37:49 testvm1.both.org hello.sh [842]: ######################################### 
 10 мая 10:37:49 testvm1 .both.org systemd [1]: hello.service: Успешно. 
 10 мая, 10:37:49 testvm1.both.org systemd [1]: завершено Мой сценарий оболочки hello. 
 10 мая 10:37:49 testvm1.both.org audit [1]: SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = hello comm = "systemd" exe = "/ usr / lib / systemd> "'
 10 мая 10:37:49 testvm1.both.org audit [1]: SERVICE_STOP pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg =' unit = hello comm =" systemd "exe =" / usr / lib / systemd /> 
 10 мая 10:37:50 testvm1.аудит both.org: BPF prog-id = 28 op = LOAD 
  
 
 Вы можете видеть, что systemd запустил модуль  hello.service , который запустил сценарий оболочки  hello.sh  с выводом, записанным в журнале. Если бы вы смогли поймать его во время загрузки, вы также увидели бы сообщение systemd, указывающее, что он запускает скрипт, и другое сообщение, указывающее, что служба прошла успешно. Посмотрев на первое сообщение systemd в потоке данных выше, вы увидите, что systemd запустила вашу службу очень скоро после достижения базовой цели системы.
 Но я бы хотел, чтобы это сообщение отображалось и при запуске. Есть способ сделать это: Добавьте следующую строку в раздел  [Service]  файла  hello.service :
  StandardOutput = журнал + консоль  
 Файл  hello.service  теперь выглядит так:
 # Простой служебный файл модуля для тестирования 
 # конфигураций запуска с помощью systemd. 
 # Дэвид Оба 
 # Лицензия GPL V2 
 # 
 [Unit] 
 Описание = My hello shell script 
 
 [Service] 
 Type = oneshot 
 ExecStart = / usr / local / bin / hello.sh 
 StandardOutput = journal + console 
 
 [Установить] 
 WantedBy = multi-user.target 
 
 После добавления этой строки перезагрузите систему и наблюдайте за потоком данных, пока он прокручивает экран вверх во время процесса загрузки. Вы должны увидеть сообщение в его маленьком ящике. После завершения последовательности запуска вы можете просмотреть журнал последней загрузки и найти записи для вашей новой службы.
 Изменение последовательности 
 Теперь, когда ваша служба работает, вы можете посмотреть, где она начинается в последовательности запуска, и поэкспериментировать с ее изменением.Важно помнить, что намерение systemd состоит в том, чтобы запустить как можно больше служб и других типов модулей параллельно в рамках каждой из основных целей:  basic.target ,  multi-user.target  и  graphical.target . Вы должны были видеть записи журнала для последней загрузки, которые должны быть похожи на мой журнал в выходных данных выше.
 Обратите внимание, что systemd запустила вашу тестовую службу вскоре после того, как достигла целевой базовой системы. Это то, что вы указали в файле служебной единицы в строке  WantedBy , так что это правильно.Прежде чем что-либо менять, перечислите содержимое каталога  /etc/systemd/system/multi-user.target.wants , и вы увидите символическую (программную) ссылку на файл служебного модуля. В разделе  [Install]  файла служебной единицы указывается, какая цель будет запускать службу, а запуск команды  systemctl enable hello.service  создает ссылку в соответствующем каталоге «target хочет»:
  hello.service -> /etc/systemd/system/hello.service  
 Определенные службы необходимо запустить во время базового .target , а другие запускать не нужно, если система не запускает  graphical.target . Служба в этом эксперименте не будет запускаться в  basic.target  - предположим, вам не нужно запускать ее до  graphical.target . Так что измените строку  WantedBy :
  WantedBy = graphical.target  
 Обязательно отключите  hello.service  и снова включите его, чтобы удалить старую ссылку и добавить новую в графике .targets.wants  каталог. Я заметил, что если я забуду отключить службу перед изменением цели, которая ее хочет, я могу запустить команду  systemctl disable , и ссылки будут удалены из обоих каталогов «target хочет». Затем мне просто нужно повторно включить службу и перезагрузить компьютер.
 Одна проблема с запуском служб в  graphical.target  заключается в том, что если хост загружается на  multi-user.target , эта служба не запускается автоматически. Это может быть то, что вам нужно, если для службы требуется графический интерфейс рабочего стола, но это также может быть не то, что вам нужно.
 Посмотрите записи журнала для  graphical.target  и  multi-user.target , используя опцию  -o short-monotonic , которая отображает секунды после запуска ядра с точностью до микросекунд:
  [root @ testvm1 ~] # journalctl -b -o short-monotonic  
 Некоторые результаты для  multi-user.target :
 
 [17.264730] testvm1.both.org systemd [1]: Запуск сценария оболочки My hello ... 
 [17.265561] testvm1.both.org systemd [1]: Запуск брандмауэра IPv4 с помощью iptables ... 
  
 [19.478468] testvm1.both.org systemd [1]: Запуск LSB: сценарий инициализации для живого образа .... 
 [19.507359] testvm1.both.org iptables.init [844]: iptables: Применение правил брандмауэра: [OK] 
 [19.507835] testvm1.both.org hello.sh [843]: ######### ##################### 
 [19.507835] testvm1.both.org hello.sh [843]: ######### Hello World! ######## 
 [19.507835] testvm1.both.org привет.sh [843]: ############################# 
  
 [21.482481] testvm1.both.org systemd [1]: hello.service: Успешно. 
 [21.482550] testvm1.both.org smartd [856]: Открыл файл конфигурации /etc/smartmontools/smartd.conf. 
 [21.482605] testvm1.both.org systemd [1]: Готово, сценарий оболочки моего приветствия. 
 
 И некоторые результаты для  graphical.target :
 
 [19.436815] testvm1.both.org systemd [1]: Запуск сценария оболочки My hello ... 
 [19.437070] testvm1.both.org systemd [1]: запуск межсетевого экрана IPv4 с iptables ... 
  
 [19.612614] testvm1.both.org hello.sh [841]: ########## #################### 
 [19.612614] testvm1.both.org hello.sh [841]: ######### Hello World! ######## 
 [19.612614] testvm1.both.org hello.sh [841]: ######################### ##### 
 [19.629455] testvm1.both.org audit [1]: SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = hello comm = "systemd" exe = "/ usr / lib / systemd / systemd "hostname =?" адрес =? терминал =? res = success '
 [19.629569] testvm1.both.org audit [1]: SERVICE_STOP pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = hello comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname = ? адрес =? терминал =? res = success '
 [19.629682] testvm1.both.org systemd [1]: hello.service: Успешно. 
 [19.629782] testvm1.both.org systemd [1]: завершено Мой сценарий оболочки hello. 
 
 Несмотря на наличие  graphical.target  «want» в файле модуля, модуль  hello.service  работает около 19.5 или 19,6 секунды после запуска. Но  hello.service  запускается примерно через 17,24 секунды в  multi-user.target  и 19,43 секунды в графической цели.
 Что это значит? Посмотрите ссылку  /etc/systemd/system/default.target . Содержимое этого файла показывает, что systemd сначала запускает цель по умолчанию,  graphical.target , которая затем извлекает  multi-user.target :
 [root @ testvm1 system] # cat default.target 
 # Идентификатор лицензии SPDX: LGPL-2.1+ 
 # 
 # Этот файл является частью systemd. 
 # 
 # systemd - бесплатное программное обеспечение; вы можете распространять и / или изменять его 
 # в соответствии с условиями Стандартной общественной лицензии ограниченного применения GNU, опубликованной 
 # Free Software Foundation; либо версии 2.1 Лицензии, либо 
 # (по вашему выбору) любой более поздней версии. 
 [Unit] 
 Описание = графический интерфейс 
 Documentation = man: systemd.special (7) 
 Требуется = multi-user.target 
 Требуется = display-manager.service 
 Конфликты = спасение.service rescue.target 
 After = multi-user.target rescue.service rescue.target display-manager.service 
 AllowIsolate = yes 
 [root @ testvm1 system] # 
 
 Независимо от того, запускает ли он службу с помощью  graphical.target  или  multi-user.target , модуль  hello.service  запускается примерно через 19,5 или 19,6 секунды после запуска. На основании этого и результатов журнала (особенно тех, которые используют монотонный вывод), вы знаете, что обе эти цели запускаются параллельно.Посмотрите еще на одну вещь из журнала:
 
 [28.397330] testvm1.both.org systemd [1]: достигнута целевая многопользовательская система. 
 [28.397431] testvm1.both.org systemd [1]: достигнут целевой графический интерфейс. 
 
 Обе мишени завершаются почти одновременно. Это согласовано, потому что  graphical.target  тянет за собой  multi-user.target  и не может завершиться, пока не будет достигнута цель  multi.user , т.е. Но  привет.обслуживание  заканчивается намного раньше этого.
 Все это означает, что эти две цели запускаются практически параллельно. Если вы изучите записи журнала, вы увидите различные цели и услуги от каждой из этих основных целей, запускаемых в основном параллельно. Понятно, что  multi-user.target  не нужно завершать до запуска  graphical.target . Следовательно, простое использование этих основных целей для последовательного запуска не очень хорошо работает, хотя может быть полезно для обеспечения того, чтобы блоки запускались только тогда, когда они необходимы для графического объекта .цель .
 Перед тем, как продолжить, измените файл модуля  hello.service  на  WantedBy = multi-user.target  (если это еще не сделано).
 Убедитесь, что служба запускается после запуска сети 
 Распространенная проблема с последовательностью запуска - обеспечение того, чтобы устройство запускалось после того, как сеть была запущена и работает. В статье  Freedesktop.org «Запуск служб после запуска сети»  говорится, что нет реального консенсуса относительно того, когда сеть считается «работающей». Однако в статье представлены три варианта, и тот, который отвечает потребностям полностью работоспособной сети, - это  network-online.цель . Просто имейте в виду, что  network.target  используется во время завершения работы, а не при запуске, поэтому он не принесет вам никакой пользы, когда вы попытаетесь упорядочить запуск.
 Перед внесением любых других изменений обязательно проверьте журнал и убедитесь, что модуль  hello.service  запускается задолго до подключения к сети. Вы можете найти  network-online.target  в журнале, чтобы проверить.
 Ваша служба на самом деле не требует сетевой службы, но вы можете использовать ее в качестве аватара для тех, кто ей нужен.
 Поскольку установка  WantedBy = graphical.target  не гарантирует, что служба будет запущена после того, как сеть будет запущена, вам нужен другой способ убедиться в этом. К счастью, есть простой способ сделать это. Добавьте следующие две строки в раздел  [Unit]  файла модуля  hello.service :
 
 После = network-online.target 
 Хочет = network-online.цель 
 
 Обе эти записи необходимы для работы. Перезагрузите хост и найдите в журналах расположение записей о вашем сервисе:
 
 [26.083121] testvm1.both.org NetworkManager [842]:  [158
64.0293] устройство (enp0s3): Активация: успешна, устройство активировано. 
 [26.083349] testvm1.both.org NetworkManager [842]: <информация> [158
64.0301] менеджер: состояние NetworkManager теперь CONNECTED_GLOBAL 
 [26.085818] testvm1.both.org NetworkManager [842]:  [158
64.0331] менеджер: запуск завершен 
 [26.089911] testvm1.both.org systemd [1]: завершен сетевой менеджер Ожидание в сети. 
 [26.0
] testvm1.both.org systemd [1]: достигнутая целевая сеть находится в сети. 
 [26.0] testvm1.both.org audit [1]: SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = NetworkManager-wait-online comm = "systemd" exe = "/ usr / lib / systemd / systemd "hostname =?" адрес =? termina> "'
 [26.0] testvm1.both.org systemd [1]: Запуск сценария оболочки My hello ... 
 [26.095864] testvm1.both.org sssd [be [implicit_files]] [1007]: Запуск 
 [26.2] testvm1.both.org systemd [1 ]: Проверка условий привела к пропуску входа в систему и сканирования устройств iSCSI. 
 [26.2
] testvm1.both.org systemd [1]: достигнута целевые удаленные файловые системы (предварительная версия). 
 [26.2
] testvm1.both.org systemd [1]: Достигнуты целевые удаленные файловые системы. 
 [26.2
] testvm1.both.org systemd [1]: Запуск Уведомление узлов NFS о перезапуске... 
 [26.294897] testvm1.both.org systemd [1]: iscsi.service: Невозможно перезагрузить модуль, поскольку он неактивен. 
 [26.304682] testvm1.both.org hello.sh [1010]: ############################# 
 [26.304682 ] testvm1.both.org hello.sh [1010]: ######### Привет, мир! ######## 
 [26.304682] testvm1.both.org hello.sh [1010]: ######################### ##### 
 [26.306569] testvm1.both.org audit [1]: SERVICE_START pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = hello comm = "systemd" exe = "/ usr / lib / systemd / systemd "hostname =? адрес =? терминал =? res = success '
 [26.306669] testvm1.both.org audit [1]: SERVICE_STOP pid = 1 uid = 0 auid = 4294967295 ses = 4294967295 msg = 'unit = hello comm = "systemd" exe = "/ usr / lib / systemd / systemd" hostname = ? адрес =? терминал =? res = success '
 [26.306772] testvm1.both.org systemd [1]: hello.service: Успешно. 
 [26.306862] testvm1.both.org systemd [1]: завершено Мой сценарий оболочки hello. 
 [26.584966] testvm1.both.org sm-notify [1011]: версия 2.4.3, начиная с
 

Это подтверждает, что модуль hello.service запущен после network-online.цель . Это именно то, что вам нужно. Вы также могли видеть сообщение «Hello World» во время запуска. Также обратите внимание, что временная метка при запуске ставится примерно на шесть секунд позже, чем была раньше.

Лучший способ определить последовательность запуска

В этой статье более подробно исследуется запуск Linux с использованием файлов systemd и unit и журналов, а также выясняется, что происходит, когда в служебный файл вносятся ошибки. Как системный администратор, я считаю, что этот тип экспериментов помогает мне понять поведение программы или службы при ее сбоях, а намеренное нарушение работы - хороший способ учиться в безопасной среде.

Как показали эксперименты в этой статье, простое добавление служебной единицы к multi-user.target или graphical.target не определяет ее место в стартовой последовательности. Он просто определяет, запускается ли модуль как часть графической среды или нет. Реальность такова, что стартап нацелен на multi-user.target и graphical.target - и все их требования и требования - запускаются практически параллельно. Лучший способ убедиться, что модуль запускается в определенном порядке, - это определить модуль, от которого он зависит, и настроить новый модуль на «Требуется» и «После» модуля, от которого он зависит.

Ресурсы

В Интернете есть много информации о systemd, но она является краткой, непонятной или даже вводящей в заблуждение. В дополнение к ресурсам, упомянутым в этой статье, следующие веб-страницы предлагают более подробную и достоверную информацию о запуске systemd.

• У проекта Fedora есть хорошее практическое руководство по systemd. В нем есть почти все, что вам нужно знать для настройки, управления и обслуживания компьютера Fedora с помощью systemd.
• В проекте Fedora также есть хорошая шпаргалка, в которой старые команды SystemV сопоставляются с аналогичными командами systemd.
• Подробную техническую информацию о systemd и причинах ее создания можно найти в описании systemd на Freedesktop.org.
• Linux.com «Больше удовольствия от системы» предлагает более подробную информацию и советы по системе.

Существует также серия глубоко технических статей для системных администраторов Linux от Леннарта Поеттеринга, дизайнера и основного разработчика systemd.