Mudanças no Fedora 16 (II)
No Fedora 15, o systemd estreou como init padrão. Porém poucos daemons (acho que na verdade nenhum) tiveram seus scripts de inicialização convertidos para arquivos de unidade nativos ou foram adaptados para usarem ativação por soquete. Como existe compatibilidade com os scripts legados SysV, apesar da novidade, o systemd não é aproveitado em sua totalidade no F15.
O comitê de engenharia do Fedora (FESCo) decidiu que, para a versão 16, todos os serviços presentes no live CD obrigatoriamente deverão ser portados para arquivos de unidade:
http://fedoraproject.org/wiki/Features/SysVtoSystemd
(está desatualizada a página)
Um trabalho e tanto, basta acompanhar este bug report que foi criado para gerenciar o que está pendente:
https://bugzilla.redhat.com/show_bug.cgi?id=713562
Para exemplificar o que isso significa, compare o script SysV que gerencia o Squid no Fedora 15 com o arquivo de unidade que será usado no Fedora 16.
F15
F16
O Fedora 16 Beta saiu faz poucos dias e a conversão para os arquivos unit está bem avançada. Não será possível converter todos os daemons presentes na distribuição, mas boa parte deles já o foi. Os arquivos unit quase sempre removem qualquer shell script antes envolvido, o que torna o gerenciamento dos daemons mais rápido e robusto.
Além de simplificar, os arquivos de unidade não são amarrados às distribuições. O mesmo arquivo unit pode ser usado em qualquer distribuição que use o systemd. A propósito, a meta é que eles sejam distribuídos pelo upstream — o que já acontece com alguns daemons.
Além da conversão para os aquivos de unidade, o uso da ativação por soquete é outro recurso que o systemd disponibiliza. Para entender como funciona, recomendo a leitura deste post de Lennart Poettering, onde ele mostra como adaptou o CUPS:
http://0pointer.de/blog/projects/socket-activation2.html
Muito interessante. No caso do CUPS, não tem por que manter o daemon ativo, nem muito menos inicia-lo durante o boot! Com ativação por soquete, ele será ativado automaticamente quando você mandar imprimir alguma coisa. Aí que está a diferença com a implementação atual do SysVinit, Upstart, etc. Com eles você tem apenas duas opções: ou ativa ou desativa o daemon. Se desativar, não pode usar o serviço. Com a ativação por soquete do systemd é tudo sob demanda. O daemon não é iniciado, mas o soquete está lá; quando aparecer algo para imprimir, daí sim o systemd inicia o daemon e todos ficam felizes.
Ativação por soquete envolve modificar o código upstream, ou seja, o programa de origem. Por isso, adaptar os programas para usá-la será um processo mais longo. Por enquanto, além do CUPS, poucos daemons foram adaptados, entre eles rsyslog, avahi, dbus. A equipe do Fedora/Red Hat sempre tenta trabalhar junto ao upstream, enviando as modificações que fazem.
O comitê de engenharia do Fedora (FESCo) decidiu que, para a versão 16, todos os serviços presentes no live CD obrigatoriamente deverão ser portados para arquivos de unidade:
http://fedoraproject.org/wiki/Features/SysVtoSystemd
(está desatualizada a página)
Um trabalho e tanto, basta acompanhar este bug report que foi criado para gerenciar o que está pendente:
https://bugzilla.redhat.com/show_bug.cgi?id=713562
Para exemplificar o que isso significa, compare o script SysV que gerencia o Squid no Fedora 15 com o arquivo de unidade que será usado no Fedora 16.
F15
#!/bin/bash # chkconfig: - 90 25 # pidfile: /var/run/squid.pid # config: /etc/squid/squid.conf # ### BEGIN INIT INFO # Provides: squid # Short-Description: starting and stopping Squid Internet Object Cache # Description: Squid - Internet Object Cache. Internet object caching is \ # a way to store requested Internet objects (i.e., data available \ # via the HTTP, FTP, and gopher protocols) on a system closer to the \ # requesting site than to the source. Web browsers can then use the \ # local Squid cache as a proxy HTTP server, reducing access time as \ # well as bandwidth consumption. ### END INIT INFO PATH=/usr/bin:/sbin:/bin:/usr/sbin export PATH # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network if [ -f /etc/sysconfig/squid ]; then . /etc/sysconfig/squid fi # don't raise an error if the config file is incomplete # set defaults instead: SQUID_OPTS=${SQUID_OPTS:-""} SQUID_PIDFILE_TIMEOUT=${SQUID_PIDFILE_TIMEOUT:-20} SQUID_SHUTDOWN_TIMEOUT=${SQUID_SHUTDOWN_TIMEOUT:-100} SQUID_CONF=${SQUID_CONF:-"/etc/squid/squid.conf"} # determine the name of the squid binary [ -f /usr/sbin/squid ] && SQUID=squid prog="$SQUID" # determine which one is the cache_swap directory CACHE_SWAP=`sed -e 's/#.*//g' $SQUID_CONF | \ grep cache_dir | awk '{ print $3 }'` RETVAL=0 probe() { # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 1 [ `id -u` -ne 0 ] && exit 4 # check if the squid conf file is present [ -f $SQUID_CONF ] || exit 6 } start() { probe parse=`$SQUID -k parse -f $SQUID_CONF 2>&1` RETVAL=$? if [ $RETVAL -ne 0 ]; then echo -n $"Starting $prog: " echo_failure echo echo "$parse" return 1 fi for adir in $CACHE_SWAP; do if [ ! -d $adir/00 ]; then echo -n "init_cache_dir $adir... " $SQUID -z -F -f $SQUID_CONF >> /var/log/squid/squid.out 2>&1 fi done echo -n $"Starting $prog: " $SQUID $SQUID_OPTS -f $SQUID_CONF >> /var/log/squid/squid.out 2>&1 RETVAL=$? if [ $RETVAL -eq 0 ]; then timeout=0; while : ; do [ ! -f /var/run/squid.pid ] || break if [ $timeout -ge $SQUID_PIDFILE_TIMEOUT ]; then RETVAL=1 break fi sleep 1 && echo -n "." timeout=$((timeout+1)) done fi [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$SQUID [ $RETVAL -eq 0 ] && echo_success [ $RETVAL -ne 0 ] && echo_failure echo return $RETVAL } stop() { echo -n $"Stopping $prog: " $SQUID -k check -f $SQUID_CONF >> /var/log/squid/squid.out 2>&1 RETVAL=$? if [ $RETVAL -eq 0 ] ; then $SQUID -k shutdown -f $SQUID_CONF & rm -f /var/lock/subsys/$SQUID timeout=0 while : ; do [ -f /var/run/squid.pid ] || break if [ $timeout -ge $SQUID_SHUTDOWN_TIMEOUT ]; then echo return 1 fi sleep 2 && echo -n "." timeout=$((timeout+2)) done echo_success echo else echo_failure if [ ! -e /var/lock/subsys/$SQUID ]; then RETVAL=0 fi echo fi return $RETVAL } reload() { $SQUID $SQUID_OPTS -k reconfigure -f $SQUID_CONF } restart() { stop start } condrestart() { [ -e /var/lock/subsys/squid ] && restart || : } rhstatus() { status $SQUID && $SQUID -k check -f $SQUID_CONF } case "$1" in start) start ;; stop) stop ;; reload|force-reload) reload ;; restart) restart ;; condrestart|try-restart) condrestart ;; status) rhstatus ;; probe) probe ;; *) echo $"Usage: $0 {start|stop|status|reload|force-reload|restart|try-restart|probe}" exit 2 esac exit $?
F16
[Unit] Description=Squid caching proxy After=syslog.target network.target nss-lookup.target [Service] Type=forking EnvironmentFile=/etc/sysconfig/squid ExecStartPre=/usr/libexec/squid/cache_swap.sh ExecStart=/usr/sbin/squid $SQUID_OPTS -f $SQUID_CONF ExecReload=/usr/sbin/squid $SQUID_OPTS -k reconfigure -f $SQUID_CONF ExecStop=/usr/sbin/squid -k shutdown -f $SQUID_CONF PIDFile=/var/run/squid.pid [Install] WantedBy=multi-user.target
O Fedora 16 Beta saiu faz poucos dias e a conversão para os arquivos unit está bem avançada. Não será possível converter todos os daemons presentes na distribuição, mas boa parte deles já o foi. Os arquivos unit quase sempre removem qualquer shell script antes envolvido, o que torna o gerenciamento dos daemons mais rápido e robusto.
Além de simplificar, os arquivos de unidade não são amarrados às distribuições. O mesmo arquivo unit pode ser usado em qualquer distribuição que use o systemd. A propósito, a meta é que eles sejam distribuídos pelo upstream — o que já acontece com alguns daemons.
Além da conversão para os aquivos de unidade, o uso da ativação por soquete é outro recurso que o systemd disponibiliza. Para entender como funciona, recomendo a leitura deste post de Lennart Poettering, onde ele mostra como adaptou o CUPS:
http://0pointer.de/blog/projects/socket-activation2.html
Muito interessante. No caso do CUPS, não tem por que manter o daemon ativo, nem muito menos inicia-lo durante o boot! Com ativação por soquete, ele será ativado automaticamente quando você mandar imprimir alguma coisa. Aí que está a diferença com a implementação atual do SysVinit, Upstart, etc. Com eles você tem apenas duas opções: ou ativa ou desativa o daemon. Se desativar, não pode usar o serviço. Com a ativação por soquete do systemd é tudo sob demanda. O daemon não é iniciado, mas o soquete está lá; quando aparecer algo para imprimir, daí sim o systemd inicia o daemon e todos ficam felizes.
Ativação por soquete envolve modificar o código upstream, ou seja, o programa de origem. Por isso, adaptar os programas para usá-la será um processo mais longo. Por enquanto, além do CUPS, poucos daemons foram adaptados, entre eles rsyslog, avahi, dbus. A equipe do Fedora/Red Hat sempre tenta trabalhar junto ao upstream, enviando as modificações que fazem.
Comentários
Postar um comentário