2>
перенаправляет стандартную погрешность cat
. cat
не выполняется однако, потому что удар не может открыть файл, к которому Вы указали как стандартный вход cat
. Для получения поведения, Вы хотите, используете
(cat < foo) 2> bar
Это будет работать cat < foo
в подоболочке и перенаправлении вывод ошибок удара к панели. Если Вы также хотите вывод ошибок от кошки, Вы могли бы сделать
(cat < foo 2> bar) 2> bar2
Я "исправил это", поставив мой бот
под экран
, как так:
[Unit]
Description=(my description)
[Service]
RemainAfterExit=yes
ExecStart=/usr/bin/screen -dmS bot /usr/bin/bot
Restart=restart-always
[Install]
WantedBy=multi-user.target
Я не знаю, почему положить мой процесс на экране исправляет его высокое использование процессора, но эй, это работает.
Проблема не в systemd.
Systemd запускает процесс без стандартного ввода (=/dev/null ). Все системные вызовы read()
завершаются немедленно (с обычным стандартным вводом, read()
блокируются до поступления новых данных ). Как правило, read()
вызывается в незавершенном цикле, что приводит к огромной нагрузке на ЦП. Чтобы убедиться в этом, попробуйте подключиться к запущенному процессу с помощью strace -p <pid>
.
Процесс должен быть адаптирован для работы без стандартного ввода или использования некоторых оболочек, таких как предлагаемая команда screen
илиnohup
Я вижу, что это старая ветка, но я оставлю здесь свой сценарий, может быть, через несколько лет кому-нибудь он покажется полезным.
У меня есть дискорд-бот в ядре c #dotnet.
Я создал для него демон systemctl на своем сервере ubuntu.
У меня также есть репозиторий git, хранящийся на сервере. когда я использовал его в тесте, я выбрал
dotnet run
он потреблял 0,3% процессора.
Я опубликовал его и поместил в папку на моем активном сервере. Оттуда в демоне он перешел к 100% использованию процессора в демоне.
Я перепутал разные версии, но чувствовал, что с терминала все работает нормально.
но нет.
Моя ошибка новичка заключалась в
dotnet publish -r linux-x64 --self-contained true
вместо
dotnet publish -r linux-x64
Но долгое время я этого не замечал, потому что автономная версия работала нормально с минимальным процессором, пока я не переместился из каталога procet bin.