Я создал на нашем Debian сжатие моего собственного демона из скелета, где запускается мое приложение (+ я добавляю туда некоторые записи в свой файл журнала). Я поместил этот файл в /etc/init.d/
cp /home/ja /etc/init.d/ucloud-test -f
chown root /etc/init.d/ucloud-test
chmod 775 /etc/init.d/ucloud-test
После этого я создал символические ссылки на этого демона:
ln -sf ../init.d/ucloud-test /etc/rc0.d/K02ucloud-test
ln -sf ../init.d/ucloud-test /etc/rc1.d/K02ucloud-test
ln -sf ../init.d/ucloud-test /etc/rc6.d/K02ucloud-test
ln -sf ../init.d/ucloud-test /etc/rc2.d/S17ucloud-test
ln -sf ../init.d/ucloud-test /etc/rc3.d/S17ucloud-test
ln -sf ../init.d/ucloud-test /etc/rc4.d/S17ucloud-test
ln -sf ../init.d/ucloud-test /etc/rc5.d/S17ucloud-test
Он создал эти символические ссылки:
root@id135728-2:/home/ja# cd /etc
root@id135728-2:/etc# ls -l rc* | grep ucloud-test
lrwxrwxrwx 1 root root 21 Aug 7 13:15 K02ucloud-test -> ../init.d/ucloud-test
lrwxrwxrwx 1 root root 21 Aug 7 13:15 K02ucloud-test -> ../init.d/ucloud-test
lrwxrwxrwx 1 root root 21 Aug 7 13:15 S17ucloud-test -> ../init.d/ucloud-test
lrwxrwxrwx 1 root root 21 Aug 7 13:15 S17ucloud-test -> ../init.d/ucloud-test
lrwxrwxrwx 1 root root 21 Aug 7 13:15 S17ucloud-test -> ../init.d/ucloud-test
lrwxrwxrwx 1 root root 21 Aug 7 13:15 S17ucloud-test -> ../init.d/ucloud-test
lrwxrwxrwx 1 root root 21 Aug 7 13:15 K02ucloud-test -> ../init.d/ucloud-test
Если я попытаюсь прочитать некоторые из этих символических ссылок, он покажет код моего демона (это должно быть правильно).
root@id135728-2:/etc# cat rc0.d/K02ucloud-test
После перезагрузки похоже, что мой демон не запущен (приложение не работает и в моем файле журнала ничего нет). Но если я сам запустил этот демон, приложение будет работать, и в моем журнале будет запись.
/etc/init.d/ucloud-test start
Кто-нибудь знает, где может быть проблема? Спасибо Роман
Трудно сказать, что может происходить без дальнейшей отладки (что означало бы обширное ведение журнала из самого скрипта, чтобы выяснить, что не так, как вы ожидали), но действительно хорошее место для начала с такого рода проблемой в Squeeze - это то документация по соглашениям о комментариях к сценарию инициализации которые помогают управлять зависимостями. Потому что в 99% случаев, если ваш сценарий инициализации «просто работает» после загрузки, это проблема зависимости.
Что вы используете для логирования, нужно ли запускать? Как насчет сетей? Может, нужно подключиться к базе данных? Тогда ваш загрузочный скрипт обязательно должен быть запущен позже.
Вместо того, чтобы создавать ссылки вручную, попробуйте добавить это в верхней части сценария инициализации:
### BEGIN INIT INFO
# Provides: ucloud-test
# Required-Start: $all
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop:
# Description: Test script that needs to run after boot
### END INIT INFO
Затем запустите insserv ucloud (обратите внимание, я исключил уровни выполнения 1 и 6)
Теперь, если окажется, что все, что вам нужно, это сеть (включая устройства с обратной связью и мосты !!!) (что, как я подозреваю, так и есть), вы можете изменить $all к $network, но это может быть сложно при расширенных сетевых настройках. Если это так, вам, вероятно, следует проверить более детальные загрузочные хуки (systemd / systemctl).
Еще нужно сделать /etc/ucloud-test/ucloud-defaults и включите его в свой сценарий после информации об инициализации, вместо того, чтобы полагаться на другие вещи, чтобы поместить их в среду, но я сильно подозреваю, что вам просто нужно подождать до запуска процесса загрузки.
В любом случае, это должно дать вам основу, на которой можно это понять. Ключевой вывод: не создавайте вручную ссылки инициализации, если у вас нет очень конкретная причина для этого, что влечет за собой нежелание определенного поведения, которое системные утилиты для управления этим могли бы принести.