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