Почему я не могу отделить файл журнала cron от системного журнала на хосте bangwagong?
Systemd может обрабатывать различные типы служб, в частности, один из следующих
простых- длительный процесс, который не влияет на его self и остается прикрепленным к оболочке.разветвление- типичный демон, который выполняет разветвление, отделяя его от процесса, который его запускал, эффективно создавая фоновый режим.oneshot- кратковременный процесс, который должен завершиться.dbus- То же самое, но уведомление об окончании запуска процессов отправляется по dbus.notify- аналогично простому, но уведомление об окончании запуска процессов отправляется через inotify.idle- аналогично простому, но двоичный файл запускается после отправки задания.
В вашем случае вы выбрали Type = forking , что означает, что systemd ожидает, пока процесс разветвится сам и завершится родительский процесс, что является признаком успешного запуска процесса. Однако ваш процесс этого не делает - он остается на переднем плане, поэтому systemctl start будет зависать на неопределенное время или до тех пор, пока процессы не завершатся сбоем.
Вместо этого вы хотите Type = simple , что является значением по умолчанию, поэтому вы можете полностью удалить строку, чтобы получить тот же эффект. В этом режиме systemd не дожидается завершения запуска процессов (поскольку он не знает, когда это произошло), и поэтому сразу же продолжает выполнение и зависимые службы. В вашем случае их нет, так что это не имеет значения.
Небольшое примечание о безопасности:
Вы запускаете службу от имени пользователя root, это не рекомендуется, поскольку это менее безопасно, чем запускать ее от имени непривилегированного пользователя. Причина этого в том, что , если есть уязвимость в jekyll, которая каким-то образом позволяет выполнять команды (возможно, через код, который он анализирует), тогда злоумышленнику не нужно ничего делать, чтобы полностью овладеть вашей системой. Если, с другой стороны, он запускается от имени непривилегированного пользователя, злоумышленник может нанести столько же ущерба, сколько и этот пользователь, и теперь должен попытаться получить привилегии root, чтобы полностью владеть вашей системой. Это просто добавляет дополнительный уровень, который злоумышленники должны уйти.
Вы можете просто запустить его от имени того же пользователя, который запускает ваш веб-сервер, но это оставляет вас уязвимым для другой потенциальной атаки. Если на вашем веб-сервере есть уязвимость, которая позволяет пользователю манипулировать файлами в вашей системе, они могут изменять сгенерированные файлы html или, что еще хуже, исходные файлы и заставлять ваш сервер обслуживать все, что они хотят. Однако, если сгенерированные файлы и исходные файлы доступны для чтения только веб-серверу и могут быть записаны другим непривилегированным пользователем, они не смогут так же легко изменить их, атакуя веб-сервер.
Однако, если вы просто обслуживаете статические файлы с этого сервера и постоянно обновляете сервер, эти атаки очень маловероятны - но все же возможны. Вы обязаны взвесить риски и накладные расходы на ее настройку в зависимости от того, насколько важна ваша система, но оба эти совета очень просты в настройке и практически не требуют затрат на обслуживание.