Где мой /etc/init.d/skeleton на OpenSuse 12.3?

При новой установке OpenSuse 12.3 я хочу «демонзировать» программу. И, по всем примерам, найденным в Интернете, я вижу, что мне нужно сначала создать /etc/init.d/myscript на основе /etc/init.d/skeleton

Но у меня нет /etc/init.d/skeleton … Есть ли место для этого файла? Или, может быть, мне нужно что-то установить?

  • Настройка xinetd для OpenSuSE
  • как запустить службу systemd до начала работы сети?
  • Как получить меньше ttys с помощью Systemd?
  • Запуск сценария init.d создает «start-stop-daemon: not found»
  • Восстановите файлы внутри папки, которая была заменена пустой. (openSUSE, Ext4)
  • Отключить неверно настроенные сетевые настройки в systemd с помощью etckeeper?
  • Система обновлена, я сначала ее проверил.

    Я знаю, что могу попытаться скопировать другой существующий скрипт /etc/init.d и изменить его, или создать новый, но я бы знал, что я ошибаюсь, или если есть другой особый способ сделать это на OpenSuse.

  • перезагрузка с одноразовыми параметрами ядра
  • Является ли 32bit еще предпочтительнее 64 бит?
  • Как настроить сеть для подключаемого сетевого адаптера в ArchLinux (systemd)?
  • Ограничение открытого файла Daemon достигается даже при увеличении системных ограничений
  • общая массивная конфигурация vhost вызывает 404 код состояния для каждого запроса vhost
  • Предоставление переменных среды для последующих процессов началось в скрипте init.d
  • One Solution collect form web for “Где мой /etc/init.d/skeleton на OpenSuse 12.3?”

    Я не уверен, где файл /etc/init.d/skeleton исчез, но я ожидал бы, что это изменение связано с заменой традиционного SysV init daemon на systemd с OpenSUSE 12. systemd полностью совместим с хорошо известными initscripts, но я бы предпочитают использовать systemd модель для запуска служб.

    На мой взгляд, традиционные initscripts могут быть сложными, и иногда они могут потребовать более глубокого знания сценариев оболочки. С другой стороны, systemd «initscript» или файл конфигурации unit для службы ( man systemd.unit ) легче поддерживать, поскольку он имеет простой синтаксис, подобный файлам .INI . Вы можете попытаться записать файл единицы и включить его, отбросив файл в каталоге /etc/systemd/system . Этот каталог имеет более высокий приоритет, чем каталог по умолчанию /usr/lib/systemd/system . Пример демона sshd :

     [Unit] Description=OpenSSH Daemon After=syslog.target network.target [Service] EnvironmentFile=/etc/sysconfig/ssh ExecStartPre=/usr/sbin/sshd-gen-keys-start ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=always [Install] WantedBy=multi-user.target и [Unit] Description=OpenSSH Daemon After=syslog.target network.target [Service] EnvironmentFile=/etc/sysconfig/ssh ExecStartPre=/usr/sbin/sshd-gen-keys-start ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=always [Install] WantedBy=multi-user.target 

    Или вы можете использовать «устаревшие» initscripts, как вы привыкли. Но вы потеряете некоторые опрятные функции systemd такие как:

    • более быстрое время загрузки, реальный параллельный запуск сервисов
    • автоматическая обработка зависимостей
    • мотивирование служб и их автоматический перезапуск разбитых
    • и многое другое

    Наконец, имейте в виду, что если есть единица ( sshd.service ) с тем же самым базовым именем, что и initscript ( /etc/init.d/sshd ), тогда initscript игнорируется, и система systemd будет использоваться и использоваться.

    Linux и Unix - лучшая ОС в мире.