Scripts Init do Linux

O processo init

O processo init é o primeiro programa executado pelo kernel de qualquer sistema operacional Linux/Unix na sua inicialização.
Existem três versões do Init para o Linux para os serviços de inicialização do sistema: SysVinit, Upstart e o Systemd.
Neste artigo serão mostradas as diferenças de inicialização que existem entre as diversas distribuições Linux/Unix e como podemos personalizar a inicialização de um sistema Linux.
No momento em que o computador é ligado ou reinicializado (boot), o BIOS procura no primeiro setor do disco (master boot record) selecionado para carga do sistema operacional (que pode ser um disco rígido, um disquete, um CD-ROM, um ZIP-DRIVE ou um LS-120, e isto é definido no SETUP) um programa para executar, que será o carregador do sistema operacional (boot loader). O LILO e o GRUB são os programas de carga de sistema operacional mais comuns no Linux. Eles permitem selecionar qual partição será utilizada para carga do sistema operacional, possibilitando assim a escolha de múltiplos sistemas operacionais, ou mesmo versões diferentes do kernel do Linux.
Depois de carregado na memória, o kernel do Linux, normalmente compactado, é descompactado antes de iniciar a sua execução (isso é feito por meio de um pequeno programa colocado no início do arquivo do kernel do Linux). Logo em seguida, é exibida uma série de mensagens enviadas pelo kernel, durante a detecção e configuração do hardware existente no computador.
Depois de concluir a detecção e configuração do hardware, o kernel monta o root filesystem (o diretório /) a partir de um parâmetro fornecido ao LILO, pelo seu arquivo de configuração,
/etc/lilo.conf, ou ao GRUB, pelo seu arquivo de inicialização /boot/grub/menu.lst, e executa o processo init, que é o pai de todos os processos, carregando o programa /sbin/init. Todos os outros processos são denominados como sendo filhos deste e são monitorados pelo init. Este é o único processo que não pode ser abortado.
Existem dois estilos de inicialização para os sistemas operacionais Linux/Unix: SysV init e BSD init. A maioria das distribuições Linux utiliza inicialização estilo SysV init em virtude do maior número de recursos e da maior flexibilidade do que o BSD init.

SysV init
O sistema SystemV foi um dos mais utilizados (e por mais tempo) em diversas distribuições Linux e por isso é o mais conhecido entre os usuários. Ele funciona da seguinte forma:

1. O kernel carrega o programa init, que é o binário principal do SystemV init;
2. O init lê o arquivo de configuração /etc/inittab e identifica a linha que começa com si::sysinit: (system initialization). Esta linha contém o shell script que o init vai carregar logo após o kernel;
3. O shell script /etc/rc.sysinit é então executado. Ele contém todas as tarefas básicas do sistema pós-kernel: monta os psudeo sistemas de arquivos (proc, sys, entre outros), carrega módulos do kernel, define configurações de kernel (sysctl), monta e verifica sistemas de arquivos, entre outros;
4. Quando o script completa sua execução, o init espera por um nível de execução (runlevel). Como ele não tem nenhum ainda, ele lê a linha do /etc/inittab que tem a definição initdefault, e muda para este runlevel.

Por exemplo, em sistemas baseados em Red Hat:

1 2	# inicializa com o runlevel 3 (modo multi-usuário completo) id:3:initdefault:

5.Ainda no /etc/inittab, existem linhas que indicam o que vai ser executado em cada runlevel. Neste caso, o SystemV usa as seguintes linhas:

1 2 3 4 5 6 7

l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6

Cada linha dessa executa o script /etc/rc.d/rc com o parâmetro do runlevel que o init mudou. Por exemplo, se o runlevel for 3, o init executa o /etc/rc.d/rc 3.

6. O script /etc/rc.d/rc executa todos os arquivos executáveis do diretório /etc/rcX.d, onde X é o runlevel. Se o runlevel for 3, ele vai usar o diretório /etc/rc3.d;
7. Dentro desses diretório, há diversos links simbólicos começando com K (de kill, ou seja, para o processo) ou S (de start, ou seja, inicia o processo). Os arquivos são executados em ordem alfabética, então ele executa o que começa com K e depois o que começa com S;
8. Por fim, esses arquivos são todos links simbólicos para os reais scripts no diretório /etc/init.d. Estes scripts aceitam como parâmetros start (quando o link começa com S, o init chama o script com o parâmetro start) e stop (quando o link começa com K, o init chama o script com o parâmetro stop).

Formato do script init

O shell script do /etc/init.d deve aceitar, no mínimo, os parâmetros start e stop. Nada melhor que um exemplo para mostrar:

• Exemplo: /etc/init.d/meu-servico

#!/bin/bash # ### BEGIN INIT INFO # Provides: meu-servico # Required-Start: $network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: O Meu Serviço # Description: Uma descricao mais completa sobre o meu serviço ### END INIT INFO # chkconfig: 2345 95 20 start() { echo 'Eu executei start!' > /var/log/meu-servico.log stop() { echo 'Eu executei stop!' > /var/log/meu-servico.log restart() { stop start case "$1" in start) start stop) stop restart) restart echo $"Usage: $0 {start|stop|restart}" exit 1 esac exit $?

Depois é só tornar o script executável:

Tenha em mente também que são shell scripts, então apesar do funcionamento ser geralmente o mesmo, o código pode variar bastante de script para script. Há uma diversidade de scripts em cada serviço de cada distribuição. Por isso, antes de fazer um script para seu serviço, dê uma olhada nos que já existem para sua distribuição e não se esqueça de aprender shell script.

Nota: Scripts são arquivos que agem como programas, passando instruções a um interpretador para realizar determinada tarefa. Diferente de programas compilados, scripts são arquivos de texto que podem ser manipulados em qualquer editor de texto não formatado.

Usando

Na prática, você já pode executar o script init com os comandos:

service meu-servico start

service meu-servico stop

service meu-servico restart

ou (prefira o service aos comandos diretos abaixo):

/etc/init.d/meu-servico start

/etc/init.d/meu-servico stop

/etc/init.d/meu-servico restart

Execute os comandos e veja o arquivo de log /var/log/meu-servico.log para cada um deles.

1. Quando o serviço inicia, ele cria um arquivo contendo o PID do próprio serviço. Esses arquivos geralmente ficam em /var/run e terminam com extensão .pid;
2. O shell script de init ao receber o parâmetro status procura esse arquivo. Se ele existir, o processo está rodando no PID contido no arquivo. Se o arquivo não existir, é porque o serviço não está rodando.
3. Quando o serviço para, ele remove o arquivo contendo o seu PID.

Gerenciando os serviços na inicialização (runlevel)

Com o script colocado no lugar certo e com permissão de execução, existem comandos que gerenciam estes scripts e os colocam (fazem os links simbólicos) nos diretórios /etc/rcX.d corretamente.

• Distribuições baseadas em Red Hat

# inclui um serviço

chkconfig --add meu-servico

# habilita o serviço na inicialização

chkconfig meu-servico on

# desabilita o serviço na inicialização

chkconfig meu-servico off

# retira todos os links simbolicos

chkconfig --del meu-servico

# lista todos os serviços, e quando estão habilitados e desabilitados em quais runlevels

chkconfig --list

# lista apenas um serviço

chkconfig --list meu-servico

• Distribuições baseadas em Debian e Ubuntu

# inclui um serviço com prioridade 20 (o link fica como S20meu-servico)

update-rc.d meu-servico defaults

# inclui um serviço com prioridade 80 (o link fica como S90meu-servico)

update-rc.d meu-servico defaults 80

# retira todos os links simbolicos (-f é para forçar mesmo que o script exista no /etc/init.d)

update-rc.d -f meu-servico remove

Como funciona o /etc/inittab

O arquivo /etc/inittab contém a configuração principal do SystemV init. Na prática, para tudo que o comando init faz, este arquivo é consultado primeiro. Nele, temos uma configuração para cada linha. Anteriormente vimos que o init, ao mudar para o runlevel 3, executou uma série de arquivos dentro do /etc/rc3.d. Veja a linha dentro do /etc/inittab que fez isso:

l3:3:wait:/etc/rc.d/rc 3

Podemos dividir essa linha em campos separados por dois pontos (:), tendo assim os campos:

id:runlevels:ação:comando

Cada campo representa:

• id: um ID unico para identificar a linha, com até 4 caracteres.
• runlevels: quais os runlevels que essa linha vai funcionar (2345 significa que funciona no 2, no 3, no 4 e no 5)
• ação: o que fazer com essa linha (que ação tomar), explicado mais pra frente
• comando: qual comando/processo deve ser executado

Voltando ao exemplo anterior:

l3:3:wait:/etc/rc.d/rc 3

Significa: a linha de configuração l3 vai funcionar quando o runlevel for 3, vai executar o comando /etc/rc.d/rc 3 e esperar (wait) até o runlevel acabar ou mudar. Particularmente, o campo de ação pode ter várias opções. Algumas delas:

• respawn: executa o comando, e quando ele finalizar, executa-o novamente. Exemplos: terminais console (gettys);
• wait: executa o comando uma vez, mesmo quando ele finalizar, espera até o runlevel acabar ou mudar para saber o que fazer;
• sysinit: o primeiro comando que é executado logo após a inicialização (já explicado anteriormente);
• initdefault: qual o primeiro runlevel que o init ficar logo após a inicialização;
• ctrlaltdel: qual comando executar quando alguem precionar CTRL+ALT+DEL no terminal.

Alguns exemplos que podemos verificar:

x:5:respawn:/etc/X11/prefdm -nodaemon

No exemplo de cima, quando o sistema for pro runlevel 5, executar o comando /etc/X11/prefdm -nodaemon (que é o ambiente gráfico em sistemas baseados em Red Hat). Se o usuário sair do sistema gráfico, ele executa novamente (respawn).

2:2345:respawn:/sbin/mingetty tty2

No exemplo de cima, se o runlevel for 2, 3, 4 ou 5, executar o comando /sbin/mingetty tty2. Este comando é o console em modo texto do Linux (CTRL+ALT+F2). Se o usuário fizer logout no console, o processo é finalizado, mas o init executa novamente devido ao respawn.

Obs.: Os caracteres # (quase sempre), ; e ! (algumas vezes) são usados para fazer comentários, sendo ignorados todos os caracteres seguintes a eles que se encontram na mesma linha. No Linux/Unix, isto se aplica a todos os arquivos de configuração, scripts e programas-fonte.
O nível de execução atual do sistema pode ser visualizado pelo comando runlevel e modificado pelo comando init , onde n é o runlevel.

Upstart

O Upstart foi concedido para resolver as limitações do SystemV init para a distribuição Ubuntu e logo foi
adotado por outras distribuições Linux. Seu princípio é ser baseado em eventos: o Upstart cria um ou vários
eventos e os serviços podem ser associados à estes eventos. Ele é quem define o que fazer quando um evento
começa, muda ou termina (por exemplo: iniciando e parando serviços).
Se vários serviços estão dentro de um evento e ele ocorre, o Upstart pode por exemplo, iniciar todos estes
serviços paralelamente. Se um evento tem que ocorrer apenas depois de outro, quando o primeiro evento
terminar, ele começa a rodar este outro dependente. Mas vamos ver isso melhor.
Como antes, quando o kernel é iniciado, ele chama o daemon do Upstart, o /sbin/init. Este daemon, quando
iniciado, carrega todos os arquivos de configuração do diretório /etc/init. São todos os arquivos que tem
extensão .conf. Cada um desses arquivos define um Job. Este Job significa uma tarefa ou serviço. Vale notar
também que qualquer alteração nos arquivos vai ser imediatamente lida pelo Upstart, sem precisar recarregar ou
algo parecido.

Exemplo simples de um arquivo de configuração de job:

• /etc/init/hostname.conf

01 # hostname ‐ set system hostname
02 #
03 # This task is run on startup to set the system hostname from /etc/hostname,
04 # falling back to "localhost" if that file is not readable or is empty and
05 # no hostname has yet been set.
06
07 description "set system hostname"
08
09 start on startup
10
11 task
12 exec hostname ‐b ‐F /etc/hostname

Esta configuração de Job serve para, na inicialização da máquina, o sistema definir o seu nome lendo o arquivo
/etc/hostname. O que podemos ver de cara no exemplo:

Linha 7: uma descrição simples do que faz o job
Linha 9: qual estado executar e quando executar (neste caso, iniciar na inicialização
Linha 11: a configuração é uma tarefa: algo que vai ser executado e depois termina sozinho (exemplo:
um shell script)
Linha 12: O comando que será executado por esta tarefa.

Uma tarefa bem simples, não? Todos os scripts que tem a linha start on startup são os primeiros a serem
executados. O que acontece é que depois que o init é carregado e lê todas as configurações, ele emite o evento
startup. É deste evento que começa toda a cadeia de outros eventos (por exemplo, a tarefa hostname que
mostramos).

Resumo da inicialização:
Podemos resumir que a inicialização acontece então nesta ordem:
1. O upstart é iniciado pelo kernel, executando o /sbin/init;
2. O upstart lê todos os arquivos .conf do diretório /etc/init e define todos os jobs;
3. O upstart emite o evento startup;
4. Os jobs hostname e mountall são executados por causa do evento startup;
5. O job mountall emite os eventos: virtualfilesystems, localfilesystems, e por aí vai;
6. Devido ao evento virtualfilesystems…
1. O job procps é iniciado (configura os sysctls do arquivo /etc/sysctl.conf);
2. O job udev é iniciado (daemon udev que gerencia os eventos do kernel);
7. Devido ao evento localfilesystems…
1. O job dbus é iniciado (daemon de mensagens dbus)
2. O job networking é iniciado (interfaces de rede) apenas se os jobs udevcontainer
ou container
estiverem parados;
3. O job networking emite os eventos: staticnetworkup e netdeviceup;
4. Devido ao evento staticnetworkup…
1. O job procps pode ser iniciado (se já não foi antes);
2. O job rcsysinit é iniciado (serviços em runlevels, assim como no SystemV)…
1. Emite o evento runlevel, com o runlevel padrão 2 (em sistemas Debian);
2. Todos os jobs que estão inscritos no evento runlevel [2] são iniciados;
3. O job rc é iniciado (compatibilidade com o SystemV;
8. Devido ao evento netdeviceup…
1. O job mountallnet é iniciado (monta sistemas de arquivos remotos);
2. O job upstartsocketbridge é iniciado (recebe eventos em socket e retransmite pro upstart);

Runlevels
Como deu pra perceber no resumo da inicialização, os jobs mais simples e que não tem muitas dependências
podem obedecer o sistema de runlevels, criado pelo rc­sysinit. Veja o exemplo do job atd:

• /etc/init/atd.conf

01 # atd ‐ deferred execution scheduler
02 #
03 # at is a standard UNIX program that runs user‐specified programs at
04 # scheduled deferred times
05
06 description "deferred execution scheduler"
07
08 start on runlevel [2345]
09 stop on runlevel [!2345]
10 
11 expect fork
12 respawn
13
14 exec atd

• Ele vai ser iniciado quando o evento runlevel for chamado com o nível 2, 3, 4 ou 5.
• Ele vai ser parado quando o evento runlevel for chamado com o nível que não seja 2, 3, 4 ou 5.

Outras coisas legais de se falar sobre os runlevels:

• Se você mudar a variável DEFAULT_RUNLEVEL do arquivo rc­sysinit.conf, você muda o runlevel
  inicial do sistema. É a mesma coisa que alterar o initdefault do /etc/inittab no SystemV. Inclusive, o
  Upstart lê um possível /etc/inittab para procurar por essa linha também;
• O job rc­sysinit também procura na linha do kernel (/proc/cmdline) por níveis de execução (s para single,
  2 para runlevel 2, e por aí vai) e o usa para o runlevel inicial;
• Um dos jobs que é chamado em todo runlevel é o rc, que é o modo de compatibilidade com o SystemV;
• O comando telinit emite um evento com o runlevel desejado, exemplo: telinit 3 emite o evento runlevel
  [3].

Compatibilidade com o SystemV init
O modo com que o Upstart funciona faz dele bem flexível e abstrato. Por isso, dá para você pensar e montar
esquemas de gerência de serviços diversos. Um dos principais esquemas de serviços é justamente a
compatibilidade com o SystemV init. Imagine, se não colocassem uma compatibilidade, muita coisa poderia parar de funcionar de uma versão de distribuição para outra. Acho que ninguém ia querer isso né?
Uma das coisas que o job rcsysinit chama através do evento runlevel é o job rc. Este job, que é o responsável
pela compatibilidade SystemV, executa o script /etc/init.d/rc $RUNLEVEL, onde $RUNLEVEL é o runlevel
atual. Funciona igualzinho ao SystemV.
Em outras palavras, em sistemas novos com Upstart você não precisa se preocupar se existirem arquivos de
start/stop dentro do /etc/init.d. Inclusive o comando service também funcionará perfeitamente. Mas se você
estiver fazendo um serviço novo para as distribuições com Upstart, é recomendável usar o Upstart.

Manipulando os serviços
Até agora aprendemos como o Upstart funciona e como definir os seus serviços. Mas e para gerenciálos?
O comando do momento aqui é o initctl. Com ele você consegue gerenciar os serviços já existentes. Vamos aos
exemplos:
Listando todos os serviços disponíveis:

initctl list

Obs.: E não apenas lista, como mostra o status de cada um)

Os estados dos jobs / serviços
Ao fazer um initctl status job, podemos ver o estado do serviço, ou seja, em que fase de execução está o job.
Um job pode ter duas ações: start e stop. Cada uma dessas ações também tem seus estados e significam em que
ponto do start ou do stop o job está. Veja uma lista desses estados:

• waiting: Estado inicial (esperando algo acontecer);
• starting: Está para ser iniciado;
• prestart: Executando a seção prestart (preparação para iniciar);
• spawned: Executando a seção exec ou script
• poststart:Executando a seção poststart (depois que iniciou)
• running: O serviço está rodando
• prestop: Executando a seção prestop (preparação para parar)
• stopping: O serviço está parando
• killed: O serviço já parou, agora o job está quase para parar
• poststop: Executando a seção poststop (depois que parou)

Alguns exemplos:

# initctl status tty1
tty1 start/running, process 1265

O job tty1, que fornece a console 1 (CTRL+ALT+F1) está na fase de start (iniciar) e está em execução com o PID 1265.

# initctl status mountall
mountall stop/waiting

O job mountall está na fase de stop (parou) e aguardando algo acontecer/mudar. Muitos jobs estarão neste estado, e isso pode significar que o job já foi executado uma vez (como é o caso desse exemplo).

Ligando e desligando serviços na inicialização

Nos sistemas SystemV, desligar ou ligar serviços na inicialização significava mexer nos links simbólicos do
diretório /etc/rcX.d (onde o X é o runlevel). No Upstart, as coisas mudam um pouco. Não há mais shell scripts
de execução, apenas configurações de job do /etc/init. O que fazer para impedir que eles sejam executados?
Primeiro identifique se o job é do tipo Upstart ou está utilizando o sistema legado SystemV.
Caso o serviço já tiver sido convertido para Upstart, o comando initctl status vai ficar assim:

# initctl status rsyslog
rsyslog start/running, process 579

Se for do tipo SystemV, vai ficar assim:

# initctl status nscd
initctl: Unknown job: nscd

(Não existe o job no Upstart (unknown job) mas existe o script /etc/init.d/nscd)
Se o script for do tipo SystemV, utilize os mesmos procedimentos da primeira parte deste tutorial.
Se for um job Upstart, você tem duas alternativas…

Desabilitando do boot

• Desde o Upstart 1.3, crie um arquivo de override para o job da seguinte forma:

# echo "manual" >> /etc/init/job.override

O parâmetro manual vai fazer com que o serviço só seja iniciado manualmente. O arquivo override é um
jeito de complementar a configuração do job sem ter que modificar o arquivo original;

• Ou se a versão for mais antiga, comente (colocar #) todas as linhas que começam com start na
  configuração do job (/etc/init/job.conf).

Habilitando no boot

Partindo do suposto de que o serviço já está desabilitado:

• Desde o Upstart 1.3, apague o arquivo override:

# rm ‐f /etc/init/job.override

Ou se o arquivo override não existir, verifique e retire a linha manual dentro da configuração do job;

• Ou se a versão for mais antiga, descomente (tirar #) todas as linhas que começam com start na
  configuração do job (/etc/init/job.conf).

Systemd

O systemd é um sistema de gerenciamento de serviços para o Linux, compatível com o SysV e Scripts de init LSB. Ele prove paralelização agressiva, utilizando socket e ativações D-Bus para iniciar serviços, oferece arranque de serviços sob demanda, mantém auditoria de processos através dos cgroups do Linux, suporta snapshotting e restauração de estado de sistema, mantém pontos de montagem mount e automount e implementa um elaborado sistema transacional baseado em dependências para controle lógico dos serviços. O systemd funciona como um substitudo por completo do sysvinit.

O systemd inicia e supervisiona o sistema como um todo, e é baseado na notação de unidades, compostas de um tipo que correspondem a um arquivo de configuração com o mesmo nome e tipo(ex: a unidade avahi.service é um arquivo de configuração de mesmo nome, que encapsula o daemon do Avahi). Existem sete tipos diferentes de unidades. A tradução das unidades não será feita por completo, visto que elas utilizam arquivos com a extensão em inglês, em seus arquivos de configuração:

1. service – serviço: a mais óbvia das unidades: daemons que podem ser iniciados, parados, reiniciados e recarregados.
2. socket – socket: esta unidade encapsula um socket no sistema de arquivos ou na Internet. O systemd atualmente suporta sockets do tipo AF_INET, AF_INET6, AF_UNIX, de stream, datagrama e pacote sequencial. Também suporta os clássicos FIFOs como transporte. Cada unidade socket tem uma unidade service equivalente, que é iniciado quando a primeira conexão se iniciar ao um socket ou FIFO(ex: nscd.socket inicia o nscd.service em uma conexão de entrada).
3. device – dispositivo: esta unidade encapsula um dispositivo na árvore de dispositivos do Linux. Se um dispositivo é marcado através de regras no udev, ele será exposto a um dispositivo de unidade no systemd. Propriedadoes configuradas com o udev podem ser utilizadas como origem de configuração par o systemd, para ajustar dependencias entre dispositivos.
4. mount: esta unidade encapsula um ponto de montagem, na hierarquia do sistema de arquivos.
5. automount: este tipo de unidade encapsula um ponto de montagem automático(automount) na hierarquia do sistema de arquivos. Cada unidade automount, tem uma unidade mount correspondente, que é iniciada(montada) assim que o diretório automount é acessado.
6. target – alvo: este tipo de unidade é usado para agrupamento lógico de unidades. Ao invés de fazer algo, ela simplesmente referencia outras unidades, que podem ser controladas então de forma conjunta(ex: multi-user.target, é uma unidade que basicamente equivale a regra do run-level 5 no clássico SysV; ou o bluetooth.target que executa requisições assim que o bluetooth ficar disponível e simplesmente carrega serviços relacionados ao mesmo, que por algum motivo, não precisavam ser iniciados: bluetoothe a obexd por exemplo).
7. snapshot: similar a unidade target, a unidade snapshot não faz nada por si so a não ser referenciar outras unidades.

Características do systemd

O systemd possui as seguintes características:

• Paralelismo agressivo utilizando socket: Para aumentar o tempo de boot e o iniciar mais processos de forma paralela, o systemd cria os sockets de escuta antes de subir o serviço(daemon) e após este processo, apenas passa os sockets para eles. Todos os sockets referentes a todos os serviços são criados de uma vez durante o init, e então um segundo passo roda todos os daemons de uma vez. Se um serviço necessita outro que não está completamente pronto, acontecerá que a conexão é enfileirada no referente serviço e o cliente será bloqueado naquela requisição. Porém, apenas aquele cliente será bloqueado para aquela requisição. Desta forma, dependências entre serviços não necessitam ser configurados para uma inicialização paralelizada: todos os sockes são iniciados de uma vez, e um serviço quando precisar do outro, garantindo a conexão ao socket.

• Ativação D-Bus para iniciar serviços: Utilizando uma ativação bus, um serviço pode ser iniciado a primeira vez que é acessado. A ativação bus requer uma mínima sincronização por requisição para iniciar os provedores e consumidores de serviços D-Bus ao mesmo tempo: iniciando um serviço ao mesmo tempo que outro, e caso um seja mais rápido, então através de ativação bus o D-Bus enfileira a requisição até que outro serviço consiga se enomear.

• Oferece inicialização de daemons sob demanda

• Rastreamento de processos utilizando http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups]: Cada processo executado tem seu próprio cgroup e é muito fácil de configurar o systemd para interagir com cgroups configurados externamente, como por exemplo, através dos utilitários do libcgroups.

• Suporta snapshotting e restauração de estados do sistema: Snapshots podem ser utilizados para salvar/restaurar o estado de todos os serviços e unidades do sistema init. Possui dois casos de uso primários: permitir ao usuário para entrar temporariamente em algum estado, como uma “Shell de emergência”, terminando todos os processos correntes, e prover uma forma fácil para retornar ao estado anterior, subindo novamente dodos os serviços colocados em um estado temporário de “parada”.

• mantem pontos de montagem(mount) e montagem automática(automount): O systemd monitora todos os pontos de montagem e a forma como vão e chegam, e tambem pode ser utilizado para montar e desmontar pontos de montagem. /etc/fstab pode ser utilizado para configuração adicional para estes pontos de montagem. Utilizando a opção comment= no arquivo /etc/fstabpermite que as entradas podem ser automaticamente controladas pelo systemd, através de seu recurso de automount.

• implementa e elabora uma logica de controle de serviços transacional, baseado em dependências: O systemd suporte diversos tipos de dependências baseadas em serviços(ou unidades) utilizando as opções After/Before, Requires e Wants no arquivo de configurações de unidade para corrigir o ordenamento de como as unidades são ativadas. Requires e Wants, exprimem um requisito positivo de dependencia, mandatório ou opcional. Existe a expressão Conflicts, que exprime um requisito de dependência negativa, e outras expressões menos utilizadas. Como controle transacional, se uma unidade requer o inicio e parada, o systemd adicionará todas as dependências a uma transação temporária, verificando se a transação é consistente(ou o ordenamento através de After/Before de todas as unidades não forma um loop). Se não possuir sucesso, o systemd não tentará corrigir, removendo todas as ações não essenciais que podem acarretar no loop.

E:

• Para cada processo criado, ele controla: O ambiente, limites de recursos, diretório atual e root, umask, Ajuste de travas a OOM(falta de memória), nice, classe de IO e prioridade, política e prioridade de CPU, afinidade de CPU, timer, user id, group id, ids de grupos complementares, diretórios de leitura/escrita/inacessíveis, flags de montagem shared/private/slave, configurações de capabilities, secure bits, reinicio de scheduler de CPU, name-space privado de /tmp, controle de cgroup e vários subsistemas. Também pode facilmente conectar stdin/stdout/stderr para serviços como syslog, /dev/kmsg, TTYs arbitrárias. Se uma TTY for conectada o systemd gerenciará o acesso exclusivo de processos, opcionalmente esperando, ou forçando.

• A configuração de arquivos do sistema possui uma sintaxe parecida da encontrada aos arquivos .desktop: É uma sinaxe simples, onde “parsers” existem em vários frameworks. Também permite a reutilização de ferramentas existentes para i18n para descrições de serviços, e similares, evitando que administradores de sistemas tenham que aprender novas sintaxes.

systemadm
Existe uma interface gráfica mínima, batizada systemadm que permite a parada/inicio e instrospecção de serviços. Este é parte do pacote systemd-gtk e está em pesado desenvolvimento não sendo ainda funcional, porém é uma ferramenta util para debug. É escrita em Vala. Não utilize a não ser que você seja um desenvolvedor

• Compatibilidade com os antigos scripts SysV: Tomando vantagem da LSB e cabeçalhos chkconfig quando disponíveis, se não, utiliza as informações constantes em outras localizações como por exemplo, as em /etc/rc.d. Estes init scripts são simplesmente considerados diferentes fontes de configuração, provendo um fácil caminho de atualização para o systemd.

• arquivo de configuração /etc/fstab: apenas uma outra fonte de configuração. Utilizando a opção do fstab comment=, é possível marcar as entradas do /etc/fstab para serem controladas pelo systemd, através de pontos automáticos de montagem.

• Suporte a simples mecanismo de template/instancias: Por exemplo, ao invés de possuir seis arquivos de configuração para seis gettys, apenas um arquivo enomeado getty@.service que será inicializado para getty@tty2.service e assim por diante. A parte de interface do systemd pode herdar dependências através de expressões como por exemplo, o serviço dhcpcd@eth0.service, que carrega o avahi-autoipd@eth0.service deixando a string eth0 como coringa de dependência.

• Compatibilidade, em partes com o /dev/initctl. Esta compatibilidade é de fato implementada através de serviços ativados via FIFO, que apenas traduz estas requisições legadas para requisições D-Bus. Efetivamente, isto signigica que antigos comandos de shutdown, poweroff e similares do Upstart e sysvinit continuam a funcionar com o systemd.

• Compatibilidade com utmp e wtmp (Extendendo de forma mais saudável, levando em conta o quão crufty o wtmp e utmp são).

Ferramentas

• systemctl: utilizado para inspecionar e controlar o estado do sistema systemd e gerenciador de serviços.
• systemd-cgls: exibe recursivamente o conteúdo da árvore de hierarquia de um determinado grupo de controle do Linux.
• systemadm: interface grávica pra gerenciamento de serviços no systemd que permite inspecionar e controlar o systemd. éÉ parte do pacote systemd-gtk. Não utilize a não ser que você seja um desenvolvedor, pois está em uma versão não muito madura.

Referências:

Devin:www.devin.com.br

Fedora Project: https://fedoraproject.org/wiki/Systemd/pt-br

Wiki Ubuntu: https://wiki.ubuntu.com/SystemdForUpstartUsers

Comandos Manipulação de Arquivos

Uma das coisas essenciais ao usar um sistema operacional é saber como lidar os arquivos e diretórios dentro dele.

Em sistemas operacionais como o Linux, mexer com arquivos é essencialmente tudo o que você vai fazer ao configurar o sistema e seus serviços.

pwd – Exibe o diretório atual

Sintaxe:  pwd 

Mostra de forma simples em qual diretório o usuário está localizado no momento.

cd – Navegando entre diretórios

Sintaxe:  cd [nome_do_diretório] Muda o diretório atual.

Exemplo: 
 pwd
/usr/games
cd ~
pwd
/home/zezin

No exemplo acima, estávamos no diretório /usr/games e com um simples cd para o diretório ~, fomos para o diretório HOME (/home/zezin). Neste caso utilizamos o ~ que é uma espécie de atalho para o diretório HOME do usuário. Alguns destes “atalhos”: . (ponto) – Diretório atual .. (dois pontos) – Diretório anterior (um nível acima) ~ (til) – Diretório HOME do usuário / (barra) – Raiz do sistema – (hífen) – Último diretório (Voltar) Se você deseja ir para um diretório que está na raiz diretamente, usa-se a / antes, exemplo:

  pwd
  /usr/local/bin
  cd /etc/rc.d
  pwd
  /etc/rc.d
  cd -
  pwd
  /usr/local/bin

Ao utilizar uma barra antes do diretório, especificamos o caminho absoluto do diretório, ou seja, todo o seu caminho desde a raiz. Se não colocamos a barra para especificar a raíz, quer dizer que estamos especificando um caminho relativo, ou seja, de acordo com o diretório atual. Em outras palavras, se eu estou no diretório /home/zezin, os dois comandos a seguir farão a mesma coisa, só que um usando o caminho relativo e o outro o caminho absoluto: cd .. cd /home

ls – Listar arquivos

Sintaxe: ls [opções] [arquivo/diretório]

Este comando lista os arquivos, nada mais que isso. Se você executar apenas o ls sozinho, ele vai mostrar todos os arquivos existentes no diretório atual. Há também as opções extras: Parâmetro Significado -l Lista os arquivos em formato detalhado. -a Lista os arquivos ocultos (que começam com um .) -h Exibe o tamanho num formato legível (combine com -l) -R Lista também os subdiretórios encontrados Exemplo:

ls -l

Podemos também usar no ls os wildcards, ou seja, caracteres que substituem outros. Exemplo: eu quero listar todos os arquivos que têm a extensão .txt, faço o seguinte:

ls *.txt

O wildcard é o *, que representa “tudo”.txt. Existem outros wildcards, exemplo disso é o ponto de interrogação (?), que substitui apenas 1 caractere, exemplo:

ls manual?.txt

Existe outro wildcard, que envolve os colchetes. Por exemplo:

ls manual[3-7].txt

Lista todos os arquivos que tiverem como manual?.txt, onde o?pode ser substituído por 3, 4, 5, 6 e 7. mkdir – Cria um diretório Sintaxe: mkdir <nome_do_diretório> Cria um diretório.

Exemplo:
 mkdir ~/paginas
 Esse comando cria um diretório dentro do HOME do usuário que o executou.

rmdir – Remove um diretório vazio

Sintaxe: rmdir Apaga um diretório que esteja vazio.

Exemplo:
 rmdir /tmp/lixo
 Isto apagará o diretório /tmp/lixo apenas se ele estiver vazio. 
Para apagar um diretório com seu conteúdo, use o comando rm.

cp – Cópia de arquivos e diretórios

Sintaxe: cp [opções]

O comando cp copia arquivos e diretórios. Como opções dele, podemos ver: Parâmetro Significado -i                                       Modo interativo. Pergunta se você quer sobrescrever ou não (confirmações) -v Mostra o que está sendo copiado. -R                                     Copia recursivamente (diretórios e subdiretórios)

Exemplos:
 Quero copiar brasil.txt para livro.txt, 
com a opção de modo interativo.cp -i brasil.txt livro.txt
cp: sobrescrever `livro.txt’?
Como o arquivo livro.txt já existia, ele pergunta se quer sobrescrever,
responda y (sim) ou n (não). 
Agora eu quero copiar o diretório /home/ftp com tudo dentro (até seus subdiretórios)
para/home/ftp2, faço o seguinte:
$ cp -R /home/ftp /home/ftp2

mv – Move arquivos e diretórios

Sintaxe: mv 

Este comando simplesmente move algum arquivo para outro lugar. Ele também é usado para renomear um arquivo. Por exemplo, se eu quero renomear o industria.txt para fabrica.txt, eu faço o seguinte:

mv industria.txt fabrica.txt
 Se eu quiser mover o industria.txt para /home/usuario com o mesmo nome, faço:
 mv industria.txt /home/usuario

rm – Deleta arquivos e diretórios

Sintaxe: rm [opções]

Este comando apaga definitivamente o arquivo ou diretório.

Exemplo:
 rm arquivo.bin
 Para apagar um diretório com todo seu conteúdo, usa-se a opção -r, assim:
 rm -r /tmp/lixo

Cuidado O comando rm -rf / é muito perigoso. Tente nunca usá-lo, senão todo seu sistema será apagado.

find – Procurando arquivos

Sintaxe: find [-name nomedoarquivo]

O comando find procura por arquivos no diretório especificado. Em seu uso mais simples, ele procura pelos nomes dos arquivos, mas pode também procurar por permissões, última modificação, etc. Como base, usaremos um exemplo para procurar o nome de um arquivo:

find /home/eitch -name arquivo.txt
Isso irá procurar o arquivo.txt dentro do diretório /home/zezin. Os wildcards mostrados
no comando ls também podem ser usados:
find /home/zezin -name documento*.odp

O find irá procurar todos os arquivos que tem o nome que começam com documento e terminam com .odp.

ln – Linkando arquivos

Sintaxe: ln -s [link simbólico]

Este comando é usado para gerar links simbólicos, ou seja, que se comportam como um arquivo ou diretório, mas são apenas redirecionadores que mandam seu comando para outro arquivo ou diretório.

Exemplo:
 $ ln -s /manual /home/linux-manual

Este comando criará o link /home/linux-manual, se você der um ls -l você verá que o diretório /home/linux-manual está apontando para /manual. Se você ir para o /home/linux-manual, você na verdade estará no /manual, mas como é um link, não há diferença.

cat – Exibe o conteúdo de um arquivo ou direciona-o para outro

Sintaxe: cat 

Este comando existe para mostrar o conteúdo de um arquivo, ou para fazer a cópia deste arquivo, ou uma junção. Vejamos um exemplo, se eu quiser mostrar o conteúdo de /home/usuario/contato, eu digito:

cat /home/zezin/contato

Aparecerá o conteúdo do arquivo contato: Zezin zezin_arroba_tetin_ponto_com_ponto_br Este comando pode também servir de direcionador para outro arquivo. Indicadores são usados para isso. Indicador > faz uma cópia,

exemplo:
 cat contato1 > contato2

Indicador >> acrescenta um arquivo ao outro,

exemplo:
 cat contato1 > contato2

O cat pode fazer coisas que nem você imagina, como tocar sons. Para fazer isso é simples, ele direciona o arquivo som para o dispositivo de áudio (que no linux é representado por um arquivo). Primeiro vamos gravar com um microfone o seu som:

cat gravacao.au < /dev/audio

Agora escute o som que voce gravou com o comando: cat gravacao.au > /dev/audio

file – Indicando o tipo de arquivo

Sintaxe: file 

Este comando identifica o tipo de arquivo ou diretório indicado pelo usuário conforme os padrões do sistema operacional. Há vários tipos de retorno, vamos aqui ver alguns mais importantes: ASCII text C Program source directory ELF-Executable data Bourn-again shell-script

Apenas um exemplo deste comando:
 file linux.txt
 ASCII Text

O Kernel no Linux

Anatomia do Kernel Linux
Histórico e Decomposição Arquitetural

O kernel Linux® é o núcleo de um sistema operacional complexo e grande e, apesar do tamanho, é bem organizado em termos de subsistemas e camadas. Neste artigo, explore a estrutura geral do kernel Linux e conheça seus principais subsistemas e interfaces centrais.

Como o objetivo deste artigo é apresentá-lo o kernel Linux e explorar sua arquitetura e componentes principais, vamos começar por um breve tour pelo histórico do kernel Linux, em seguida, observaremos sua arquitetura e, finalmente, examinaremos seus principais subsistemas. O kernel Linux é formado por mais de seis milhões de linhas de código.

Introdução ao Kernel Linux

Agora passemos a uma visão mais ampla da arquitetura do sistema operacional GNU/Linux. É possível imaginar um sistema operacional a partir de dois níveis, conforme mostra a Figura.

Na parte superior, temos o espaço de usuário ou do aplicativo. Este é o espaço no qual os aplicativos de usuário são executados. Abaixo do espaço de usuário está o espaço do kernel. Aqui, o kernel Linux existe.

Há também a GNU C Library (glibc). Ela fornece a interface de chamada do sistema que se conecta ao kernel e fornece o mecanismo para transição entre o aplicativo de espaço de usuário e o kernel. Isso é importante, pois o kernel e o aplicativo do usuário ocupam espaços de endereços diferentes e protegidos. E embora cada processo de espaço de usuário ocupe seu próprio espaço de endereço virtual, o kernel ocupa um único espaço de endereço.

O kernel Linux pode ainda ser dividido em três níveis completos. Na parte superior, a interface de chamada do sistema, que implementa as funções básicas, como read e write. Abaixo da interface de chamada do sistema está o código do kernel, que pode ser mais precisamente definido como o código do kernel independente da arquitetura. Esse código é comum a todas as arquiteturas do processador às quais o Linux oferece suporte. Abaixo, está o código dependente da arquitetura, que forma o que é mais comumente chamado de BSP (Board Support Package). Este código atua como o processador e o código específico da plataforma para a arquitetura em questão.

Propriedades do Kernel Linux

Ao discutir a arquitetura de um sistema amplo e complexo, é possível visualizar o sistema sob várias perspectivas. Um objetivo de uma decomposição de arquitetura é fornecer um modo de compreender melhor a origem, e é isso que faremos aqui.

O kernel Linux implementa vários atributos importantes de arquitetura. Em um nível avançado e em níveis mais baixos, o kernel é dividido em camadas em diversos subsistemas distintos. O Linux pode também ser considerado monolítico porque agrupa todos os serviços básicos dentro do kernel. Isso o diferencia da arquitetura de microkernel, na qual o kernel fornece serviços básicos, como comunicação, E/S e gerenciamento de memória e processo, e serviços mais específicos são plugados na camada do microkernel. Cada um tem suas próprias vantagens, mas vou me afastar desse debate.

Com o tempo, o kernel Linux tornou-se eficaz tanto em termos de memória quanto de uso da CPU, além de ser extremamente estável. Contudo, o aspecto mais interessante do Linux, considerando seu tamanho e sua complexidade, é sua portabilidade. Ele pode ser compilado para executar uma grande quantidade de processadores e plataformas com diferentes limitações e necessidades de arquitetura. Um exemplo é a capacidade do Linux em executar em um processo com uma Memory Management Unit (MMU), bem como em processos que não fornecem MMU. A porta uClinux do kernel Linux é fornecida para suporte a não-MMU.

Principais Subsistemas do Kernel Linux

Vejamos agora alguns dos principais componentes do kernel Linux utilizando a perspectiva mostrada na Figura  como guia.

O que é um Kernel?
Como mostrado na Figura , um kernel, na verdade, não é nada mais do que um gerenciador de recursos. Se o recurso que está sendo gerenciado for um processo, uma memória ou um dispositivo de hardware, o kernel gerencia e intermedeia o acesso ao recurso entre os vários usuários concorrentes (no kernel e no espaço do usuário).

Interface de Chamada do Sistema
A SCI é uma camada fina que fornece meios para efetuar as chamadas de funções a partir do espaço de usuário no kernel. Conforme discutido anteriormente, essa interface pode ser dependente da arquitetura, mesmo dentro da mesma família de processadores. A SCI é, na verdade, um interessante serviço de multiplexação e desmultiplexação de chamada de funções. É possível encontrar a implementação da SCI em ./linux/kernel, bem como as partes dependentes da arquitetura em ./linux/arch.

Gerenciamento de Processos
O gerenciamento de processo tem foco na execução de processos. No kernel, eles são chamados de encadeamentos e representam uma virtualização individual do processador (código de encadeamento, dados, pilha e registros de CPU). No espaço do usuário, o termo processo geralmente é utilizado, embora a implementação do Linux não separe os dois conceitos (processos e encadeamentos). O kernel fornece uma Interface de Programação de Aplicativo (API) através da SCI para criar um novo processo (funções fork, exec, ou Portable Operating System Interface [POSIX]), parar um processo (kill, exit) e executar a comunicação e sincronização entre eles (mecanismos signal ou POSIX).
Além disso, no gerenciamento de processo há a necessidade de compartilhar a CPU entre os encadeamentos ativos. O kernel implementa um novo algoritmo de planejamento que opera em tempo constante, independentemente do número de encadeamentos competindo pela CPU. Isso é chamado de planejador O(1), denotando que se leva a mesma quantidade de tempo para planejar um encadeamento ou muitos. O planejador O(1) também oferece suporte a vários processadores (chamado Symmetric MultiProcessing, ou SMP). É possível encontrar as origens do gerenciamento de processo em ./linux/kernel e as origens dependentes de arquitetura em ./linux/arch).

Gerenciamento de Memória
Outro importante recurso gerenciado pelo kernel é a memória. Em termos de eficiência, dada a forma como o hardware gerencia a memória virtual, a memória é gerenciada no que são chamadas páginas (de 4KB na maioria das arquiteturas). O Linux inclui os meios para gerenciar a memória disponível, assim como os mecanismos de hardware para mapeamento físico e virtual.

Mas o gerenciamento de memória é muito mais do que gerenciar buffers de 4KB. O Linux fornece abstrações acima de buffers de 4KB, como o alocador slab. Esse esquema de gerenciamento de memória utiliza buffers de 4KB como base, mas, em seguida, aloca estruturas internamente, rastreando quais páginas estão completas, parcialmente usadas e vazias. Isso permite que o esquema aumente e diminua dinamicamente, com base nas necessidades do sistema geral.

Ao oferecer suporte de memória a vários usuários, há ocasiões em que a memória disponível pode esgotar-se. Por isso, as páginas podem ser movidas da memória para o disco. Esse processo é chamado de troca porque as páginas são trocadas da memória para o disco rígido. É possível encontrar as origens de gerenciamento de memória em ./linux/mm.

Sistema de Arquivo Virtual
O Sistema de Arquivo Virtual (VFS) é um aspecto interessante do kernel Linux, porque fornece uma abstração de interface aos sistemas de arquivos. O VFS fornece uma camada de troca entre a SCI e os sistemas de arquivos aos quais o kernel oferece suporte, conforme a figura abaixo.

O VFS Fornece uma Malha de Comutação Entre Usuários e Sistemas de Arquivos

No topo do VFS há uma abstração comum de funções da API como open, close, read e write. Na parte inferior do VFS encontram-se as abstrações do sistema de arquivo que definem como as funções da camada superior são implementadas. Elas são plug-ins para o sistema de arquivos fornecido (existem mais de 50 deles). É possível encontrar as origens do sistema de arquivos em ./linux/fs.

Abaixo da camada do sistema de arquivos está o cache do buffer, que fornece um conjunto comum de funções à camada do sistema de arquivos (independente de qualquer sistema de arquivos específico). Essa camada de armazenamento em cache otimiza o acesso aos dispositivos físicos mantendo os dados por perto durante um breve período (ou especulativamente já lidos, para que fiquem disponíveis quando necessários). Abaixo do cache do buffer estão os drivers de dispositivo, que implementam a interface para o dispositivo físico específico.

Pilha de Redes
A pilha de redes, pela estrutura, segue uma arquitetura em camadas modelada após os próprios protocolos. Lembre-se de que o Protocolo de Internet (IP) é o protocolo principal de camadas de rede situado abaixo do protocolo de transporte (mais comumente o Protocolo de Controle de Transmissões ou TCP). Acima do TCP está a camada de soquetes, que é chamada pelo SCI.

A camada de soquetes é a API padrão para o subsistema de rede e fornece uma interface com o usuário para vários protocolos de rede. Desde o acesso a quadros brutos às unidades de dados de protocolo IP (PDUs) e até o TCP e o User Datagram Protocol (UDP), a camada de soquetes fornece um modo padronizado de gerenciar conexões e mover dados entre terminais. É possível encontrar as origens de rede no kernel em ./linux/net.

Drivers de Dispositivo
A maioria dos códigos-fonte no kernel Linux existe nos drivers de dispositivo que tornam utilizável um determinado dispositivo de hardware. A árvore de códigos-fonte do Linux fornece um subdiretório de drivers que é posteriormente dividido pelos vários dispositivos suportados, como Bluetooth, I2C, serial, etc. É possível encontrar as origens do driver de dispositivo em ./linux/drivers.

Código Dependente de Arquitetura
Embora grande parte do Linux seja independente da arquitetura na qual ele é executado, existem elementos que devem considerar a arquitetura para o funcionamento normal e por questões de eficácia. O subdiretório ./linux/arch define a parte dependente da arquitetura da origem do kernel contido em diversos subdiretórios específicos a esta arquitetura (formando coletivamente o BSP). Em um desktop típico, é utilizado o diretório i386. Cada subdiretório de arquitetura contém diversos outros subdiretórios que se concentram em um aspecto particular do kernel, como boot, kernel, gerenciamento de memória e outros. É possível encontrar o código dependente da arquitetura em ./linux/arch.

Recursos Interessantes do Kernel Linux
Se a portabilidade e a eficácia do kernel Linux não bastarem, ele fornece outros recursos que não puderam ser classificados na decomposição anterior.

Sendo o Linux um sistema operacional em produção e um software livre, ele é um grande teste para novos protocolos e aprimoramentos desses protocolos. O Linux oferece suporte a um grande número de protocolos de rede, inclusive o típico TCP/IP, e também uma extensão para rede de alta velocidade (acima de 1 Gigabit Ethernet [GbE] e 10 GbE). O Linux também oferece suporte a protocolos como o Stream Control Transmission Protocol (SCTP), que fornece vários recursos avançados, acima do TCP (como o protocolo de nível de transporte de substituição).

O Linux também é um kernel dinâmico, oferecendo suporte à inclusão e remoção de componentes de software durante a execução. Eles são chamados módulos de kernel dinamicamente carregáveis, e podem ser inseridos durante a inicialização quando necessários (quando um determinado dispositivo é encontrado, solicitando o módulo) ou a qualquer momento pelo usuário.

Um avanço recente no Linux é seu uso como sistema operacional para outros sistemas operacionais (chamado de hypervisor). Recentemente, foi feita uma modificação no kernel, chamada Kernel-based Virtual Machine (KVM). Essa modificação permitiu uma nova interface para o espaço do usuário, possibilitando que outros sistemas operacionais fossem executados no kernel ativado pelo KVM. Além de executar outra instância do Linux, o Microsoft® Windows® também pode ser virtualizado. A única restrição é que o processador subjacente deve oferecer suporte às novas instruções de virtualização.

Créditos: http://www.ibm.com/developerworks/br/library/l-linux-kernel

Comandos Iniciais

COMANDOS

O básico do básico, os primeiros passos para entender o sistema, a estrutura de diretórios, o que significam esses prompts de comando, como se virar na hora das dúvidas… São assuntos essenciais para quem quer mexer bem com este sistema operacional e com o tempo ficar ligeiro para usar o sistema e solucionar dúvidas.

Inicialização do Sistema Linux

Ao iniciar um sistema Linux, geralmente muitas informações aparecem na tela. Estas informações são o que chamamos de mensagens do kernel. Estas mensagens mostram o que está sendo carregado na memória do sistema, como por exemplo dispositivos de disco, CDs, drivers de rede, entre outros. Estas mensagens são muito importantes, pois no futuro irão ajudar a diagnosticar problemas, ver o que está sendo reconhecido pelo kernel, entre outras coisas mais. Pode ser que em sua distribuição de escolha, as mensagens não apareçam, ou então uma janela gráfica aparecerá no lugar. Neste caso, para visualizar as mensagens de boot posteriormente, utilize o seguinte comando:

dmesg

Todas estas mensagens do kernel também são gravadas no arquivo /var/log/messages, mas este arquivo só pode ser lido pelo administrador do sistema (root). Logo após as mensagens de kernel, o init entra em ação. O init é o encarregado de iniciar todos os serviços da distribuição, como serviços de impressão, fontes, configurações de teclado e mouse, interfaces de rede, entre muitos outros. Para fins de informação, estes scripts de serviços se encontram geralmente no diretório /etc/init.d. É importante observar a inicialização do Linux para ver se está tudo ok, se os serviços não deram erros ou se algo que não é preciso está sendo iniciado. Login e Linha de Comando Após todas as mensagens de boot, o sistema irá pedir uma tela de login de usuário. Como veremos mais adiante, o Linux é multiusuário, ou seja, suporta vários usuários. Dependendo da configuração usada na instalação, esta tela de login pode ser em modo gráfico ou texto. Na instalação, geralmente se escolhe uma senha para o root e também é criado um usuário normal. Logue-se como root ou como usuário normal usando o nome do usuário e a senha escolhida. Neste curso, a senha do usuário root é poder e o usuário normal é o zezin, com a senha digital. Novamente, dependendo da sua configuração inicial de distribuição, você irá acessar a interface gráfica ou o console (modo texto). Se você está no modo gráfico, primeiro vamos trabalhar no modo texto. Aperte a combinação de teclas: CTRL+ALT+F1. A tela de login no modo texto será apresentada, logue-se com o usuário zezin. Feito o login, você estará logado e receberá um prompt de comando, o qual chamamos de shell. zezin@maquina:~$ ou [zezin@maquina ~]$ A diferença entre tipos de prompts variam de distribuição para distribuição. No caso acima, o primeiro campo de cada prompt representa o usuário, que no nosso caso é “eitch”. O segundo campo especifica o nome da máquina, que no exemplo são respectivamente aluno1 e aluno2 (portanto, duas máquinas diferentes). O terceiro campo é o diretório em que o usuário se encontra, no nosso caso o “~”, que significa o diretório padrão do usuário. O último caracter do prompt, que no nosso caso é o “$”, significa que tipo de usuário você é e tem apenas duas possibilidades: “$”, que significa usuário normal; e “#”, que significa super-usuário (root). O modo com que o prompt é apresentado pode ser controlado através da variável de shell PS1. O modo texto, por padrão nas distribuições, está disponível em 6 telas diferentes. Em cada uma das telas é possível abrir uma “sessão” de usuário. Experimente apertar a combinação de teclas CTRL+ALT+F1, CTRL+ALT+F2, CTRL+ALT+F3, […] até CTRL+ALT+F6. Isto o levará para os consoles de número 1, 2, 3, 4, 5 e 6. A partir do 7, o Linux reserva especialmente para as interfaces gráficas funcionarem. Apesar de parecer rudimentar, o ambiente texto possui tudo o que é preciso para usar um sistema operacional. Dependendo do que se usa, é completamente viável utilizar o sistema sem uma interface gráfica. Podemos utilizar o links para navegar na Web, ler e-mails com o mutt, editar textos com o vi, emacs ou nano, criar tarefas automatizadas com o shell-script e muito mais.

Modo Gráfico

Inicialmente, o Linux como todo UNIX tinha como interface principal entre o usuário e o sistema um terminal texto, o chamado console. Ao longo do tempo, foram desenvolvidas várias soluções que implementavam uma interface gráfica, com o conceito de mouse e janelas. Apesar disso, as pessoas não costumavam usar as interfaces gráficas dos sistemas Unix e por isso nunca houve uma grande aceitação. Com a popularização do Linux por ele ser um software livre e estar disponível para toda a Internet, alguns ambientes gráficos promissores começaram a aparecer. Em todas as distribuições Linux é incluído o X.org, um servidor X totalmente gratuito e de código-aberto.

O servidor X é quem vai fornecer o recurso de gerar a interface gráfica e conversar com a placa de vídeo, monitor e dispositivos de entrada como teclado e mouse. Para que haja um desktop, é necessário também a existência de um gerenciador de janelas. Os gerenciadores de janelas são responsáveis por gerar as janelas, controlar o comportamento das mesmas (minimizar, maximizar…), agrupar e gerenciar as telas dos programas, fornecer temas gráficos para o ambiente ficar mais agradável, entre outros. Os gerenciadores de janelas utilizam as bibliotecas gráficas do servidor X para gerar suas janelas. Sem um gerenciador de janelas, é inútil se usar um servidor X.

Se você estiver no modo texto e o servidor X estiver ativo, aperte a combinação de teclas CTRL+ALT+F7 para ir ao modo gráfico. Como dito anteriormente, o Linux por padrão reserva os terminais 7 em diante para o modo gráfico. Se existisse um outro ambiente gráfico sendo executado (o que é possível), ele poderia estar também no terminal 8, podendo ser acesso através da combinação de teclas CTRL+ALT+F8. Caso aconteça algum problema no servidor X, ou alguma configuração que você fez estiver errada e algo ficar inacessível, a combinação de teclas CTRL+ALT+BACKSPACE mata o servidor X, forçando a saída de todos os programas do gerenciador de janelas e voltando ao modo texto.

Dentro do ambiente gráfico, pode-se executar programas como navegadores de Internet, leitores de e-mail, suíte de escritório, jogos, editores de imagens, entre muitos outros programas que já vem no Linux. É possível também executar uma janela de terminal, que seria o equivalente a se logar no modo texto. Conceito de Multi-Usuário Como você pôde notar através das possibilidades de login, o Linux é o que chamamos de multi-usuário. Para um sistema ser multiusuário, ele deve ser capaz de abrir sessões de vários usuários simultâneamente. Foi o que ocorreu anteriormente, quando pudemos nos logar em 6 terminais textos diferentes, com usuários distintos, e uma vez no ambiente gráfico. Apesar de que no começo podemos nos logar “apenas” em 7 lugares diferentes, pode-se muito bem criar outras formas de login e aumentar esse número. Por exemplo, ao utilizar o utilitário ssh para acesso remoto, temos a possibilidade de nos logar com quantos usuários quiser, pois cada conexão é um login diferente.

Sabendo disso, podemos afirmar também que em termos de sistema operacional, tudo dentro do Linux é multi-usuário. Cada usuário tem seus arquivos, seus diretórios e seus programas. Cada um pode executar tarefas diferentes e simultâneamente. Isso é o que chamamos também de ser multi-tarefa. Por exemplo, você pode consultar um arquivo texto que está em um certo diretório, enquanto outro usuário acessa um CD-ROM, enquanto outro navega pela Internet, tudo ao mesmo tempo. Apesar deste conceito parecer comum, em tempos passados haviam sistemas mono-tarefas e mono-usuários, onde só se podia executar uma coisa de cada vez, com apenas um usuário.

É importante ressaltar que com essa divisão por usuários, os arquivos e programas também terão restrições. O usuário principal do Linux é chamado de root e ele é o usuário que pode acessar, controlar e fazer tudo no sistema: o administrador. Enquanto os usuários normais só poderão acessar seus documentos e executar apenas algumas aplicações, o root poderá fazer tudo, inclusive definir quais usuários poderão fazer o quê. Uma prática comum e importante no Linux é nunca utilizar o usuário root, a não ser que seja para tarefas realmente administrativas que requerem o root. É recomendável que você crie um usuário comum e use-o para as tarefas do dia-a-dia.

Como todos nós podemos cometer erros, cometendo um erro como usuário normal não fará mal algum ao sistema como um todo, já que só o root pode alterá-lo. id O usuário de uma sessão geralmente é identificado pelo seu UID (User ID): um número único que identifica o usuário. Este número é geralmente associado com um nome de usuário. Uma vez logado no sistema, uma maneira de descobrir posteriormente quem é o seu usuário é utilizando o comando id:

A História do Linux.

História do Linux

A EVOLUÇÃO DO SISTEMA OPERACIONAL GNU/LINUX

O nome Linux, surgiu da mistura de Linus +Unix. Linus é o nome do criador do Linux,Linus Torvalds e Unix, é o nome de umsistema operacional de grande porte, noqual contaremos sua história agora, para quevocê entenda melhor a do Linux: A origem do Unix tem ligação com o sistema operacional Multics, projetado na década de 1960.
Esse projeto era realizado pelo Massachusets Institute of Technology (conhecido como MIT), pela General Eletric (GE) e pelos laboratórios Bell (Bell Labs) e American Telephone Telegraph (AT&T ). A intenção era de que o Multics tivesse características de tempo compartilhado (vários usuários compartilhando os recursos de um único computador), sendo assim, o sistema mais arrojado da época.
Em 1969, já existia uma versão do Multics rodando num computador GE645. Ken Thompsom, era um pesquisador do Multics e trabalhava na Bell Labs. No entanto, a empresa se retirou do projeto tempos depois, mas ele continuou seus estudos no sistema; desde então, sua ideia não era continuar no Multics original e sim criar algo menor, mas que conservasse as ideias básicas do sistema. A partir daí, começou a saga do sistema Unix. Brian Kernighan, também pesquisador da Bell Labs, foi quem deu esse nome.
Em 1973, outro pesquisador da Bell Labs, Dennis Ritchie, rescreveu todo o sistema Unix numa linguagem de alto nível, chamada C , desenvolvida por ele mesmo. Por causa disso, o sistema passou a ter grande aceitação por usuários externos à Bell Labs. Entre 1977 e 1981, a AT&T, alterou o Unix, fazendo algumas mudanças particulares e lançou o System III. Em 1983, após mais uma série de modificações, foi lançado o conhecido Unix System IV, que passou a ser vendido. Até hoje esse sistema é usado no mercado, tornando-se o padrão internacional do Unix. Esse sistema é comercializado por empresas como IBM, HP, Sun, etc. O Unix, é um sistema operacional muito caro e é usado em computadores poderosos por diversas multinacionais.
Mas, qual a relação entre o Unix e o Linux, ou melhor, entre o Unix e Linus Tor valds? Para responder essa pergunta, é necessário falar de outro sistema operacional, o Minix. O Minix é uma versão do Unix,porém, gratuita e com o código fonte disponível. Isso significa que qualquer programador experiente pode fazer alterações nele. Ele foi criado originalmente para uso educacional, para quem quisesse estudar o Unix em casa. No entanto, vale citar que ele foi escrito do “zero” e apesar de ser uma versão do Unix, não contém nenhum código da AT&T e por isso pode ser distribuído gratuitamente. A partir daí, “entra em cena”, Linus Torvalds.
Ele era um estudante de Ciências da Computação da Universidade de Helsinki, na Finlândia. E em 1991, por hobby, Linus decide desenvolver um sistema mais poderoso que o Minix. No mesmo ano, ele disponibilizou a versão do kernel (núcleo dos sistemas operacionais) 0.02 e continuou trabalhando até que em 1994, quando disponibilizou a versão 1.0. Até o momento em que este artigo estava sendo escrito, a versão atual do kernel do linux é o 2.6.26. O Linux é um sistema operacional livre, e é uma reimplementação das especificações POSIX (padronização da IEEE, Instituto de Engenharia Elétrica e Eletrônica) para sistemas com extensões System V e BSD. Isso significa que o Linux, é bem parecido com Unix, mas não vem do mesmo lugar e foi escrito de outra forma.
GNU é um sistema operacional tipo Unix idealizado por Richard Stallman. Este sistema operacional começou em 1984 quando Stallman teve a ideologia de criar um sistema operacional completamente livre. Em 1991 o sistema operacional GNU já possuia diversos programadores e softwares, porém, necessitava de um núcleo (“kernel”). Este impasse foi resolvido adotando o Kernel Linux de Linus Tor valds aos softwares GNUs.Desde então algumas pessoas adotam o termo GNU/Linux para creditar os softwares GNU que estão no núcleo Linux.