LINUX.ORG.RU

systemd — новый подход к инициализации системы

 , , smf, ,


2

2

Lennart Poettering, сотрудник компании Red Hat, представил концепцию принципиально нового механизма управления инициализацией системы — systemd (system daemon), которая вобрала в себя достоинства классического System V init и более современных launchd (Mac OS X), SMF (Solaris) и Upstart (Ubuntu, Fedora), но при этом лишена многих их недостатков. В разработке этого проекта ему помогали сотрудники Red Hat, Novell, IBM, Intel и Nokia.

systemd опирается на современные linux-технологии: cgroups, AutoFS, D-Bus, и при этом совместим с исторически устоявшимися механизмами: init-скриптами, стандартными командами shutdown, poweroff и т.п. Предоставляемый systemd функционал позволяет заменить не только систему инициализации, но и ряд других подсистем, в частности, cron, (x)inetd, xdm/kdm/gdm/..., частично даже SELinux.

Основные идеи, использованные при создании systemd:

  • Контроль над сокетами. Многие демоны, запускаемые при инициализации, взаимодействуют с другими демонами через unix domain и сетевые сокеты, и большинство существующих систем инициализации запускают демона-клиента только после того, как демон-сервер запустится и создаст сокет. Вместо этого, systemd создает сокеты, а затем запускает демонов, передавая им эти сокеты. Даже если демон-клиент запустится быстрее и начнет использовать сокет раньше сервера, ничего страшного не произойдет: его запрос будет буферизован и передан серверу, как только тот сможет его обработать. Такой подход уже используется в Mac OS X (launchd), позволяя этой ОС достигать впечатляющей скорости загрузки.

    Аналогичный принцип используется systemd и при запуске служб, использующих шину D-Bus.

    Кроме того, возможен автоматический запуск служб при обращении к заданным сокетам (см. ниже).

  • Фоновое монтирование. Такие операции, как монтирование, проверка и активация квот файловых систем, занимают весьма значительную долю загрузочного времени. В большинстве современных систем они выполняются последовательно, до запуска всех демонов. systemd же предлагает монтировать не-жизненно-важные ФС только тогда, когда они кому-то понадобятся. Для этого используется механизм AutoFS. Например, многие служебные демоны вовсе не обязаны ждать, пока смонтируется огромный и к тому же зашифрованный /home.

    Разумеется, этот подход неприменим к /, /proc, /sys и т.п.

  • Минимизация числа вспомогательных процессов. В настоящее время значительная часть работ по инициализации производится шелл-скриптами, что приводит к колоссальным времязатратам. В частности, Леннарт пишет:

    On my system the scripts in /etc/init.d call grep at least 77 times. awk is called 92 times, cut 23 and sed 74,

    при этом замечая, что почти каждый такой запуск влечет накладные расходы на поиск библиотек, подгрузку данных интернационализации (i18n) и т.п.

    В качестве альтернативы Леннарт предлагает предлагает переписать критичные участки на C, а также вынести часть функционала в самих демонов и в systemd. Сейчас для systemd уже готовы написанные на C подсистемы монтирования и установки имени хоста. До полной победы, отмечает Леннарт, работа предстоит огромная, но результат того стоит.

  • Отслеживание процессов. В ныне используемых системах инициализации в принципе возможна такая ситуация, когда при неправильном форке процесс может «потеряться». Например, так может произойти с некорректно написанным CGI-приложением, и процесс останется работать даже после остановки веб-сервера.

    Для предотвращения таких ситуаций systemd использует интегрированный в ядро Linux механизм контрольных групп (cgroups). Если приложение не имеет доступа к псевдо-ФС, управляющей работой cgroups, то оно не может самостоятельно покинуть свою группу и «потеряться».

    Также к этой группе задач относится и автоматический перезапуск демонов, перенаправление их stdout/stderr на выбранные TTY или в системный журнал, регистрация всех запусков и остановок служб, и многое другое.

  • Ограничение процессов. systemd предоставляет множество возможностей ограничить или расширить полномочия процессов, контролируя такие параметры, как uid, gid, umask, рабочий и корневой каталоги, класс и приоритет CPU и I/O, наличие доступа на чтение и запись к смонтированным файловым системам и отдельным каталогам и т.п. Также можно использовать возможности по ограничению ресурсов, предоставляемые cgroups.

Базовым элементом systemd являются модули (units), которые связаны между собой и имеют определенный тип. Каждый модуль может требовать для своей работы другие модули, конфликтовать с модулями, запускаться только после или до определенного модуля (директивы конфигурации Requires, Conflicts, Before, After, Wants). Из типов модулей определены:

  • service — обычный демон, поддерживающий операции start, stop, restart, reload. Может быть представлен родным (native) файлом конфигурации systemd или System V init-скриптом.
  • socket. При обращении к сокету генерируется событие, для которого можно настроить обработчик. Например, автоматически запускать определенные службы при обращении к заданному сокету. В этом отношении systemd похож на давно известный (x)inetd, однако при этом поддерживает unix domain сокеты и FIFO.
  • device. Отметив нужные устройства в конфигурации udev, впоследствии можно использовать такие события, как появление и удаление устройства, в качестве событий systemd, назначив на них обработчики. Например, при появлении устройства bluetooth будет запущена соответствующая служба.
  • mount. systemd контролирует все точки монтирования файловых систем. В целях обратной совместимости поддерживается сбор информации о точках монтирования из /etc/fstab.
  • automount. Для помеченных таким образом точек монтирования, монтирование выполняется только при обращении к ним.
  • target. Более гибкий аналог уровней исполнения (runlevels), используемых в System V init. Представляет собой группу служб, объединенных по функциональному назначению. Например, multi-user.target идентичен runlevel 5, а bluetooth.target приводит к инициализации подсистемы bluetooth.
  • snapshot — во многом похож на target. Позволяет «запомнить» существующую конфигурацию units (запущенных служб, открытых сокетов, смонтированных ФС) с тем, чтобы в дальнейшем восстановить это состояние. Позволяет, например, перейти в emergency shell (сейчас это init 1), а затем полностью восстановить набор запущенных служб. Другой пример — выход системы из состояния suspend.

Надо заметить, что systemd отличается от SMF, во-первых, тем, что позволяет оперировать не только зависимостями между службами, но и событиями, например, «готовность устройства» или «обращение к сокету». Во-вторых, systemd использует более простой формат файлов конфигурации (.desktop aka .INI против XML в SMF).

От upstart же systemd отличается более высокой степенью параллелизации, и как следствие, более высокой скоростью загрузки. Например, если демон A требует для работы сокет, открытый демоном B, то upstart сначала запустит демона B, а затем демона A, в то время как systemd создаст сокет сам и запустит обоих демонов одновременно, что занимает примерно в два раза меньше времени. Используемый в upstart принцип, когда ключевыми событиями является лишь запуск и остановка демона, Леннарт и его коллеги считают изначально неэффективным.

Well, the point of the part about Upstart above was to show that the core design of Upstart is flawed, in our opinion. Starting completely from scratch suggests itself if the existing solution appears flawed in its core. However, note that we took a lot of inspiration from Upstart's code-base otherwise.

>>> Подробности

★★★★

Проверено: isden ()
Последнее исправление: isden (всего исправлений: 2)

Ответ на: комментарий от vga

>В той же бубунте рисуется прогресс бар и все. Один, большой. Что там проконтролируешь

Осиль уже убрать quiet в конфиге груба (или галку ткнуть не помню где)

Можно заодно и сплэш выкинуть

matimatik
()
Ответ на: комментарий от AlexM

>Немного выше я говорил про специализированный DSL или, на крайний случай, урезанный perl/python/javascript со специализированным набором библиотек, чтобы конфигурировать и поднимать сервисы.

А ниже про урезку баша ;) Вместо DSL хотелось бы что-то более знакомое (хотя в обсуждаемые варианты это похоже не входит), perl и js тут имхо смотрятся странновато, а python — может и ничего, но глядя на то, сколько памяти жрет тот же yum..

anonymous
()
Ответ на: комментарий от matimatik

> Как запустить апач строго после мускуля?

Как-как...

/usr/local/sbin/mysqld $MYSQLD_ARGS
...
/usr/local/sbin/apachectl start

PS сейчас фряхи под руками нету, ставить лень, поэтому возможны непринципиальные вариации :)

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

>> Для этих служб и init-скрипт был бы из одного case, но это вырожденный случай.

Он для бОльшей части сервисов такой, см. убунтячьи upstart'овые скрипты.

То есть времени на их выполнение не требуется совсем (или почти совсем). ЧТД, собственно.

И сколько таких сервисов, в штуках, которым нужны отдельные драйверы, подгружаемые ни раньше, ни позже как в момент старта сервиса?

Единицы. Но это значит, что см. предыдущий пункт,

Ты хоть смотрел на реальные init-скрипты? :)

И вот в этом месте очень хочется ответить вопросом на вопрос... Но не буду

Ты хотел спросить писал ли я их? Нормальный вопрос. Да, писал, и сейчас пишу.

Скажу лишь, что первую версию udev'овской обвязки для альта писал именно я.

С ALT незнаком, из udev-обвязки писал только файлы правил, которые, в общем-то, не скрипты ни разу.

P.S. JIT для shell - это бред.

tailgunner ★★★★★
()
Ответ на: комментарий от r

И что есть такая бытовая библиотека которая например проверит /etc/sysconfig/network?

Думаю, такие файлы могут перегенерироваться на базе основных файлов конфигурации systemd по ходу загрузки, при обнаружении изменений.

Жесть. Загляни в свой rc.d.

Смотрим комп с работы (F12):

# ls -w 110 /etc/init.d
acpid                 dhcpd          ices           multipathd  ntpd         rpcsvcgssd  vmware-autostart
akmods                dhcpd6         ipmievd        mysqld      ntpdate      rsyslog     vmware-core
XXXX-media-streaming  dhcrelay       iptables       nagios      nvidia       saslauthd   vmware-mgmt
XXXX-oo-server        dnsmasq        irqbalance     named       pcscd        sendmail    vncserver
apcupsd               firstboot      iscsi          nasd        portreserve  slapd       watchdog
auditd                freenx-server  iscsid         netconsole  postgresql   smartd      winbind
autofs                functions      kdump          netfs       rdisc        smb         wpa_supplicant
avahi-daemon          gpm            killall        netplugd    restorecond  snmpd       xinetd
cpuspeed              gpsd           lm_sensors     network     rfremixconf  snmptrapd   zvbid
crond                 haldaemon      lvm2-monitor   nfs         ris-linuxd   sshd
cups                  halt           mdmonitor      nfslock     rpcbind      tgtd
dc_client             httpd          messagebus     nmb         rpcgssd      udev-post
dc_server             icecast        microcode_ctl  nscd        rpcidmapd    vmware

# ls /etc/init.d | wc -l
87

# grep 'cp ' /etc/rc.d/*
/etc/rc.d/rc.sysinit:                   cp -a --parents "$1" "$RW_MOUNT"
/etc/rc.d/rc.sysinit:   [ -d /dev/.initramfs/state ] && cp -a /dev/.initramfs/state/* $RW_MOUNT
/etc/rc.d/rc.sysinit:                           [ ! -e "$STATE_MOUNT$1" ] && cp -a --parents "$1" "$STATE_MOUNT"

# grep 'cp ' /etc/rc.d/init.d/*
/etc/rc.d/init.d/avahi-daemon:      cp -fp /etc/localtime /etc/avahi/etc >/dev/null 2>&1
/etc/rc.d/init.d/iptables:          cp -f $IPTABLES_DATA $IPTABLES_DATA.save \
/etc/rc.d/init.d/iptables:          cp -f $TMP_FILE $IPTABLES_DATA \
/etc/rc.d/init.d/iscsid:    modprobe -r iscsi_tcp 2>/dev/null
/etc/rc.d/init.d/kdump: cp --sparse=always /proc/vmcore $coredir/vmcore-incomplete
/etc/rc.d/init.d/named:    [ -s /etc/localtime ] && cp -fp /etc/localtime ${ROOTDIR}/etc/localtime;

Анализируем находки:

  • Копирование в rc.sysinit происходит в разделе, отвечающем за инициализацию в режиме stateless, посему, согласись, требуется отдельная обработка скриптом;
  • avahi-daemon - как понимаю, требуется для запуска в chroot - специальный случай, наверняка потребует отдельных параметров в конфиге systemd для копирования нужных файлов и запуска;
  • iptables - копирование производится в функции save, при запуске не нужна. Кстати, никогда не понимал, почему там cp а не mv;
  • iscsid - копирования нет;
  • kdump - особая служба, требует отдельного скрипта (как сейчас);
  • named - опять случай chroot.

Вывод: в большинстве скриптов копирование не нужно, только в специальных случаях.

ximeric
()
Ответ на: комментарий от Hug37r011

> Почему-то никто не произнёс волшебного слова lua. Произнесу. Lua.

Вероятно, потому, что мало кто хочет переписывать ворох init-скриптов.

tailgunner ★★★★★
()
Ответ на: комментарий от BSD

> Ад с редхатами познал в полной мере.
А нельзя ли подробнее? Вдруг я так и умру в неведении, что же это за сыс5инит-ад такой.

Lumi ★★★★★
()
Ответ на: комментарий от Dudraug

>А ты давай дальше фапай на ред хат
У меня то хоть есть причина фапать на редхат ибо они чего то добились кроме апстарта и перелопачивания внешнего вида гнума ;)

px ★★★
()
Ответ на: комментарий от tailgunner

>30 лет init-скрипты работали и всех устраивали, но в 2010 году ВНЕЗАПНО шелл и греп стали тормозить.

для кого внезапно, а для кого инит-скрипты всегда были слабоконтролируемой свалкой непроверенного кода.

Да, от создателя PulseAudio это звучит особенно убедительно.

а вот это настораживает...

AVL2 ★★★★★
()
Ответ на: комментарий от tailgunner

То есть времени на их выполнение не требуется совсем (или почти совсем). ЧТД, собственно.

Нет. Из того, что считанным (по пальцам одной руки) сервисам требуется от среды что-то большее, чем execve + kill, отнюдь не означает, что загрузка одного сервиса происходит пренебрежимо малое время. Напротив, от того, что среда по умолчанию предполагает полную свободу, не предоставляя никаких «коротких путей», происходят совершенно не нужные для большинства потери времени. DSL в стиле upstart - это как раз короткий путь для тех, кому не надо танцевать джигу при запуске сервиса.

Ты хоть смотрел на реальные init-скрипты? :)

Ты хотел спросить писал ли я их?

Нет, я хотел спросить, заглядывал ли ты в них. С учётом попыток рассказать мне, что в этих скриптах не принимается решений, нужно ли запускаться, и для чего нужен пресловутый case start)... - знаешь, вполне резонный вопрос. Но сдержался.

из udev-обвязки писал только файлы правил, которые, в общем-то, не скрипты ни разу.

Ну, в тот момент ( http://lists.altlinux.org/pipermail/sisyphus/2005-January/271111.html ) оно только-только внедрялось и тогда функционировало как обычный сервис, это сейчас его утащили в rc.sysinit, кажется....

AlexM ★★★★★
()
Ответ на: комментарий от tailgunner

А придёццо... Пример Убунты (и, вероятно, Генты) наглядно, тыкскыть, демонстрирует, что отказ от legacy существенно ускоряет и упрощает загрузку.

AlexM ★★★★★
()
Ответ на: комментарий от Hug37r011

туда обработку ошибок средствами языка уже приделали? А так да, для этой задачи нормальная замена упоминавшимся perl/python/js.

AlexM ★★★★★
()
Ответ на: комментарий от anonymous

> А под апстарт кто переделывал, в всяких убунтах

А под апстарт ничего, кроме init-скрипта переделывать не надо.

Есть еще такой момент, что не со всеми демонами можно использовать upstart-скрипты. И еще то, что неправильно написанный upstart-скрипт (например, expect daemon вместо expect fork) может доставить кучу головной боли.

Я не знаю, как обстоят дела с systemd, но upstart пока еще очень сырой, чтобы полностью отказываться от init-скриптов. Что в конечном итоге добавляет головную боль системному администратору - одна половина скриптов на upstart, другая - традиционные init.d

sjinks ★★★
()
Ответ на: комментарий от ximeric

> Bash - хорошая оболочка, сам использую только её, в т.ч для небольших системных скриптов, но сколько внешних команд и сколько раз запускается при старте системы

А что *сейчас* мешает писать инит-скрипты на C?

sjinks ★★★
()
Ответ на: комментарий от AlexM

> Из того, что считанным (по пальцам одной руки) сервисам требуется от среды что-то большее, чем execve + kill, отнюдь не означает, что загрузка одного сервиса происходит пренебрежимо малое время

Из того, что большинству сервисов не требуется ничего сложнее exec и kill, следует то, что накладные расходы bash на этих сервисах близки к нулю, и никакой JIT их не ускорит.

Ты хотел спросить писал ли я их?

Нет, я хотел спросить, заглядывал ли ты в них. С учётом попыток рассказать мне, что в этих скриптах не принимается решений, нужно ли запускаться,

Решение, запускать ли скрипт, принимается при конфигурировании ранлевела. Потом скрипт проверяет конфигурацию системы и может отказаться запускать демона (собственно, проверка - это его главная функция, иначе демона можно пускать из inetd),

знаешь, вполне резонный вопрос. Но сдержался.

Напрасно. Это не клуб благородных джентльменов, а ЛОР.

DSL в стиле upstart - это как раз короткий путь для тех, кому не надо танцевать джигу при запуске сервиса.

Возможно. Upstart похож как раз на то, о чем говорю я - описание графа зависимостей + обычные init-скрипты.

Пример Убунты (и, вероятно, Генты) наглядно, тыкскыть, демонстрирует, что отказ от legacy существенно ускоряет

То есть в Убунте init-скрипты уже не на shell, а на... чем?

tailgunner ★★★★★
()
Ответ на: комментарий от Lothlorien

> По топику: наверное, систем инициализаций должно быть несколько и должна быть возможность их выбора.

В данном случае «свобода выбора» - это головня боль мейнтэйнерам - им придется писать/тестировать скрипты подо все системы инициализации. Что не есть удобно.

sjinks ★★★
()
Ответ на: комментарий от px

Уже приводилось. upstart тот же который до сих пор использует в RH.

Dudraug ★★★★★
()
Ответ на: комментарий от px

Ну и фапай дальше, а я использую то что мне удобно. А тебя послушать весь линакс создали в ред хате, то же сообщество дебиана сделало куда больше, чем все коорпорации вместе взятые.

Dudraug ★★★★★
()
Ответ на: комментарий от tailgunner

То есть в Убунте init-скрипты уже не на shell, а на... чем?

Те, которые upstart - на смесе шелла и некоторого своего языка.

description     "Mount filesystems on boot"

start on startup
stop on rcS

expect daemon
task

emits virtual-filesystems
emits local-filesystems
emits remote-filesystems
emits all-swaps
emits all-filesystems
emits filesystem

# temporary, until we have progress indication
# and output capture (next week :p)
console output

script
    . /etc/default/rcS
    [ -f /forcefsck ] && force_fsck="--force-fsck"
    [ "$FSCKFIX" = "yes" ] && fsck_fix="--fsck-fix"
    [ -n "$TMPTIME" ] && tmptime="--tmptime=$TMPTIME"
    exec mountall --daemon $force_fsck $fsck_fix $tmptime
end script

post-stop script
    rm -f /forcefsck 2>dev/null || true
end script
sjinks ★★★
()
Ответ на: комментарий от tailgunner

>Это может быть за гранью дозволенного.

Всегда есть машина, на которой делают ./configure && make. Это прямо следует из куцести и убогости так называемых «энтерпрайзных» дистрибутивов, где стоит вылезти за рамки песочницы, называемой LAMP, как ощущается сильная нехватка софта в репозиториях.

А уж если init-скрипты правят на одной машине, а потом разносят правки на все, то тут абсолютно пофиг, текстовые ли это скрипты или ELF'ы.

linuxfan
()
Ответ на: комментарий от AVL2

>>30 лет init-скрипты работали и всех устраивали, но в 2010 году ВНЕЗАПНО шелл и греп стали тормозить.

для кого внезапно, а для кого инит-скрипты всегда были слабоконтролируемой свалкой

Да-да, конечно. Как вообще определяется «контролируемость»?

непроверенного кода.

Ага, очень редко запускаемого к тому же.

tailgunner ★★★★★
()
Ответ на: комментарий от sjinks

>> То есть в Убунте init-скрипты уже не на shell, а на... чем?

Те, которые upstart

Сколько таких в роцентах?

- на смесе шелла и некоторого своего языка.

Ы. Как это отлаживается?

tailgunner ★★★★★
()
Ответ на: комментарий от linuxfan

>> Это может быть за гранью дозволенного.

Всегда есть машина, на которой делают ./configure && make. Это прямо следует из куцести и убогости так называемых «энтерпрайзных» дистрибутивов

О чем ты вообще? O_o

tailgunner ★★★★★
()
Ответ на: комментарий от Dudraug

>сообщество дебиана сделало куда больше, чем все коорпорации вместе взятые
Какой ты наивный мальчоночка. Сообщество дебиана создало свои велосипеды и использует их только у себя в своих бубунтах. Недавно была в новостях тема где анализировалось кто и сколько влил кода. И у меня для тебя плохие новости.

px ★★★
()
Ответ на: комментарий от AlexM

>> И любой телевизор, если разраб с руками, будет чудесненько и быстренько запускаться с обычными стартовыми скриптами на bash.

А если это не телевизор, а «почти generic» медиацентр, в котором и браузер открыть можно, и страничку на печать послать, и какой-нибудь торрент запустить.


Что-то мне подсказывает, что после первого запуска можно смело пользовать suspend2disk на заменяемую флеш.

В чём проблема-то?

Lego_12239 ★★
()
Ответ на: комментарий от tailgunner

Сколько таких в роцентах?

Затруднюсь ответить, так как не все upstart-скрипты - аналоги init.d

На домашней машине так:

vladimir@sjinks:~$ ls -1 /etc/init | wc -l
55
vladimir@sjinks:~$ ls -1 /etc/init.d | wc -l
94

Ы. Как это отлаживается?

Хреново это отлаживается :-( Ошибка в описательной части (тот же expect) приводят к невозможности запускать/останавливать демон через upstart - до перезагрузки. В Ланчпаде даже баг есть по этому поводу.

sjinks ★★★
()
Ответ на: комментарий от px

>>сообщество дебиана сделало куда больше, чем все коорпорации вместе взятые

Какой ты наивный мальчоночка.

Какой ты толстый тролльчоночка.

Сообщество дебиана создало свои велосипеды и использует их только у себя в своих бубунтах.

Да ты еще и глуупенький. Не знаешь, что порт apt-get использовали даже на RedHat, когда yum еще не было. Не знаешь, что все эти yum'ы содраны с apt-get. И кстати, Убунта - самый распространенный Линукс, так что «велосипеды» Дебиана очень широко используются.

Недавно была в новостях тема где анализировалось кто и сколько влил кода.

Глупый тролльчонок, ты, наверное, меряешь вклад в строках кода?

tailgunner ★★★★★
()
Ответ на: комментарий от sjinks

> Ошибка в описательной части (тот же expect) приводят к невозможности запускать/останавливать демон через upstart - до перезагрузки.

Мама миа ! И ЭТИМ предлагают пользоваться ?

Darkman ★★★
()
Ответ на: комментарий от sjinks

> Ошибка в описательной части (тот же expect) приводят к невозможности запускать/останавливать демон через upstart - до перезагрузки.

Даже если исправить upstart-скрипт?

tailgunner ★★★★★
()
Ответ на: комментарий от px

Я тебя еще больше огорчу там была статистика по ядру и только по ядру. Прикладной софт по большей части пишет сообщество.

Dudraug ★★★★★
()
Ответ на: комментарий от Lego_12239

>Что-то мне подсказывает, что после первого запуска можно смело пользовать suspend2disk на заменяемую флеш.

В чём проблема-то?


В таких системах проблем с медленным стартом userspace вообще нет - там проблема со стартом ядра, кто будет инициализировать периферию после саспенда ? Вместо саспенда там намного логичней использовать XIP.

bengan
()
Ответ на: комментарий от sjinks

>> Даже если исправить upstart-скрипт?

Да. initctl просто зависнет при попытке запуска/остановки демона.

Шли бы они нафиг со своей быстрой загрузкой :) Пусть сначала баги выловят.

tailgunner ★★★★★
()

>В качестве альтернативы Леннарт предлагает предлагает переписать критичные участки на C,

Отказать!

Zubok ★★★★★
()
Ответ на: комментарий от sjinks

> https://bugs.launchpad.net/upstart/+bug/406397

Я правильно понимаю, что всё упирается в залипший статус процесса ?

Если да, то бага глупейшая - в Гентушных скриптах сколько лет как для таких случаев сделали команду 'zap'

Darkman ★★★
()
Ответ на: комментарий от Darkman

> Я правильно понимаю, что всё упирается в залипший статус процесса ?

Думаю, что да.

Но там багов и помимо этого хватает.

sjinks ★★★
()
Ответ на: комментарий от tailgunner

>yum'ы содраны с apt-get
Ты неадекватен

Глупый тролльчонок, ты, наверное, меряешь вклад в строках кода?

Бугогашенька ну а в чем же если не в этом?

px ★★★
()
Ответ на: комментарий от Dudraug

>Прикладной софт по большей части пишет сообщество.
насрать на прикладной софт. Его действительно в любой момент может написать каждый школьник. Линукс это в первую очередь ядро, и все свистоперделки это уже второстепенно.

px ★★★
()
Ответ на: комментарий от tailgunner

>О чем ты вообще? O_o

Я о том, что gcc присутствует в обязательном порядке. Иногда на соседней машине, но он есть и нет причин, которые бы помешали им воспользоваться.

Более того, интерпретатор перла, питона или что там еще сейчас модно, на машине, соприкасающейся с внешним миром, гораздо более опасная вещь, чем gcc. Я же правильно понял, что под «интерпретатором, который есть везде», ты не /bin/sh понимаешь?

linuxfan
()
Ответ на: комментарий от linuxfan

> Я о том, что gcc присутствует в обязательном порядке. Иногда на соседней машине, но он есть и нет причин, которые бы помешали им воспользоваться.

То есть тактика такова: вытаскиваем из сырцового пакета исходники init-скрипта, компилируем их на соседней машине, и подбрасываем бинарь на машину, где возникла проблема? Очень удобно,да..

Я же правильно понял, что под «интерпретатором, который есть везде», ты не /bin/sh понимаешь?

Неправильно. Я подразумеваю именно /bin/sh (или /bin/bash), на котором и пишутся сейчас init-скрипты.

tailgunner ★★★★★
()
Ответ на: комментарий от r

>пульсаудио <...> И выкосить нормально из системы нельзя.

Выкинь свой дистр на помойку. Я из федоры с лёгкостью удалял пульсаудио и всё начинало работать по-старому, т.к. в режиме войны между alsa, oss и esd.

legolegs ★★★★★
()
Ответ на: комментарий от ximeric

>Вывод: в большинстве скриптов копирование не нужно, только в специальных случаях.

Как меня радуют такие заявочки! Ими грешит один из менеджеров в нашей конторе, когда его спрашивают что софт будет делать в определенном случае - а он ответить не может. «Но у 90% пользователей такого случая не будет», или «но это же очень редко».

И что - по этому поводу сделать вид что данный юскейс не существует? Написать if(cond) then «90%» else operator-vikrutis'-kaknibud'?

r ★★★★★
()
Ответ на: комментарий от tailgunner

>Неправильно. Я подразумеваю именно /bin/sh (или /bin/bash), на котором и пишутся сейчас init-скрипты.

Ой, эти скрипты без sed'ов и прочих coreutils работать не будут. Авторы, кстати, правильно замечают, что на сторонние процессы тратися довольно-таки много времени. И мосье, видимо, давно не писал скриптов для /bin/sh — мягко говоря, не самое приятное занятие.

То есть тактика такова: вытаскиваем из сырцового пакета исходники init-скрипта, компилируем их на соседней машине, и подбрасываем бинарь на машину, где возникла проблема? Очень удобно,да..

Пользуюсь линуксом уже лет 6-7 и ни разу не было необходимости править что-то кроме rc.local. Проблема высосана из пальца, а корни ее следует искать в твоей боязни нативного кода.

linuxfan
()
Ответ на: комментарий от linuxfan

>> Я подразумеваю именно /bin/sh (или /bin/bash), на котором и пишутся сейчас init-скрипты.

Ой, эти скрипты без sed'ов и прочих coreutils работать не будут.

Без sed и прочих coreutils много чего работать не будет.

Авторы, кстати, правильно замечают, что на сторонние процессы тратися довольно-таки много времени

Нет веры этим авторам.

Пользуюсь линуксом уже лет 6-7 и ни разу не было необходимости править что-то кроме rc.local.

И даже --noscripts ни разу не поставил? «Не верю» (с)

И мосье, видимо, давно не писал скриптов для /bin/sh — мягко говоря, не самое приятное занятие.

в твоей боязни нативного кода.

Доктор, вы, походу, не доктор :)

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.