Автоматично стартиране при рестартиране на сървъра
Ако тази опция е активирана, услугата ще се стартира при рестартиране на сървъра.
Почистване на работната директория при стартиране на услугата
Ако тази опция е активирана, стандартният start скрипт ще премахне default/work/*
Премахване на стари логове при стартиране на услугата
Ако тази опция е активирана, стандартният start скрипт ще премахне default/logs/*
Действия на услугата
Стартиране
Действието START се опитва да стартира услугата.
SystemD изчаква уведомление READY, за да счита услугата за стартирана.
Конфигурацията по подразбиране на WatchDog изпраща сигнала READY, когато началните страници на всички конфигурирани домейни започнат да връщат HTTP статусни кодове без грешки.
Вижте останалата част от тази документация за начини да преопределите поведението на WatchDog.
Действието START изпълнява my_appserv/bin/start . То може да бъде променено, за да отговаря на нуждите на вашата услуга. Търсете „bin/start“ в този документ за повече информация.
Вижте Ограничения за времеви ограничения за стартиране/спиране.
Спиране
Действието STOP се опитва да спре услугата по нормален начин. То изчаква основният процес на услугата да приключи.
В случай че командата за спиране изтече SystemD изпраща TERM & CONT сигнали към всички процеси в групата на услугата.
Ако след сигнала TERM останат процеси, те се прекратяват със сигнали KILL & CONT. Сигналът KILL е немаскируем и ядрото на Linux прекратява процесите, които го получават. Има някои много специфични случаи, в които блокираните процеси не могат да бъдат прекратени дори със сигнал KILL.
Действието STOP изпълнява my_appserv/bin/stop . То може да бъде променено, за да отговаря на вашите нужди. Търсете „bin/stop“ в този документ за повече информация.
Вижте Ограничения за времеви ограничения за стартиране/спиране.
Рестартиране
RESTART изпълнява STOP, последвано от START, така че описанията на тези две действия са приложими.
Презареждане
RELOAD обикновено презарежда конфигурацията, без да рестартира целия процес на демона.
Това действие не е имплементирано в скриптовете по подразбиране, тъй като Tomcat не поддържа операция за презареждане. Затова е нормално да се получи грешка, ако го изпълните.
Ако вашият персонализиран сървър за приложения поддържа операцията за презареждане, можете да създадете скрипт bin/reload, който ще се изпълни, когато това действие бъде задействано. От вас зависи да решите какво да правите с това действие.
Изпращане на SIGTERM / SIGKILL
Те позволяват изпращането на сигнали към всички процеси в групата на услугата. Тези сигнали обикновено TERMinate (прекратяват) или KILL (убиват) услугата.
Обикновено тези две действия не трябва да се използват.
Имайте предвид, че SystemD ще рестартира услугата, ако я убиете с един от тези сигнали, докато тя е в активно състояние.
Инициализация на услугата
Това действие създава директорията my_appserv, ако тя липсва. Директорията ще бъде инициализирана с избраните версии на сървъра на приложението и версии на JVM .
Домейни на My App Server
Поддръжката на My App Server за даден домейн/поддомейни може да бъде активирана/деактивирана, ако:
- има активиран уеб хостинг
- е активен, т.е. не е спрян или деактивиран
Това състояние (активен/деактивиран) се използва в конфигурацията по подразбиране:
- от скрипта
bin/start, за да генерира необходимите конфигурационни файлове - от WatchDog за мониторинг на началните страници на активните домейни
Ако използвате персонализирана версия на сървър за приложения или сте модифицирали стандартните скриптове за стартиране/спиране/watchdog, можете да игнорирате статуса на активиране. Например, можете да имате конфигуриран по подразбиране catchall VHost в бекенда.