Вам будут нужны удаленные руки, чтобы войти в систему через консоль и работать telinit 3
или telinit 5
если любой из тех был runlevels, Вы использовали ранее.
Кроме того, скрипт мог запуститься, но через мгновение не сработал и, таким образом, его не видно в ps.[1120828].
В общем, когда у вас есть такие проблемы, вы всегда должны попробовать следующее:
Перенаправьте вывод ошибок вашей программы:
@reboot /root/myscriptname.sh 2> / root / logfile .txt
Увеличьте уровень детализации cron
, добавьте эту строку в / etc / default / cron
(по крайней мере, в системах на основе Debian) и перезапустите демон cron
:
EXTRA_OPTS = '- L 4'
Доступные параметры журнала:
0 без ведения журнала (ошибки регистрируются независимо)
1 записать начало заданий
2 зарегистрировать конец заданий
4 зарегистрировать задание со статусом выхода! = 0
8 зарегистрировать идентификатор дочернего процесса (во всех журналах) {{1 }}
Вы должны найти журналы в / var / syslog
.
В вашем конкретном случае, я почти уверен, что проблема в том, что mono-sgen
не находится на пути cron, как предлагает Gnouc, но это полезные уловки, о которых следует знать в следующий раз.
Сначала нужно проверить журнал crontab, чтобы убедиться, что crontab работает нормально.
Есть ли mono-gen
в вашем $PATH
? Вы можете проверить с помощью этой команды: type mono-gen
.
Попробуйте добавить полный путь к mono-sgen
и проверить результат:
#!/bin/bash
nohup /path/to/mono-sgen /root/myapp.exe /path/file > /dev/null 2>&1 &
@reboot
может вызвать проблемы в зависимости от того, какой дистрибутив вы используете. См. Эти вопросы и ответы U&L. Я написал об этой самой проблеме под названием: @reboot crontab работает только для root? .
Вместо того, чтобы возиться с записью в crontab, я был бы склонен создать сценарий, который можно запускать как часть вашего входа в среду рабочего стола (DE).Затем это можно добавить как «Программы запуска» через gnome-session-properties
.
Чтобы узнать об изменениях в вашем скрипте, см. @ Gnouc answer .