Como manter a execução de um programa, mesmo após finalizar a sessão no Linux

Ao finalizar uma sessão no Linux (na GUI ou na CLI), o sistema operacional entende que todos os programas e processos iniciados pelo usuário devem ser fechados.
Terminar uma sessão não é a mesma coisa que desligar o computador.
Comumente, as pessoas encerram uma sessão, para iniciar outra, sob um novo perfil de usuário.
Este pode ser o momento ideal para executar programas de manutenção, como um script de backup, por exemplo.
O truque pode ser realizado com o utlitário nohup.

O nohup executa comandos imunes a hangups e envia seus resultados (output) a um terminal non-tty.
Em resumo, ele mantém o comando vivo, em execução, mesmo após o fim da sua sessão.
O nome é derivado da junção dos 2 termos: no hangup.

Veja um exemplo, tirado do manual do comando:


nohup wget site.com/file.zip

Outro caso em que ele pode ser útil, é na atualização do sistema.
Se você estava adiando o update, para não sobrecarregar a sua conexão, pode rodar o procedimento ao sair:


nohup sudo apt update

Webmasters podem se valer deste utilitário, para manter procedimentos em funcionamento, mesmo após se desconectarem do servidor remoto.
Como padrão, um arquivo será gerado no diretório local, em que o nohup foi executado, com o nome de nohup.out — contendo as saídas do comando que ele executou.
Para atualizar o sistema, abra um novo terminal e autentique-se como root. Agora rode o procedimento de atualização:


nohup apt update; apt -y full-upgrade


nohup: ignorando entrada e anexando saída a 'nohup.out'
Lendo listas de pacotes... Pronto
Construindo árvore de dependências
Lendo informação de estado... Pronto Calculando atualização... Pronto ...

Pode fechar o terminal.
Quando quiser verificar o andamento da sua atualização, basta dar uma olhada no arquivo nohup.out:


sudo cat nohup.out

linux terminal nohup apt

Como listar processos no Linux em ordem de uso do processador ou da memória

Listar os processos em execução no sistema é fácil.
Neste post, vou mostrar como ordená-los, de maneira que você fique sabendo quem está consumindo mais memória ou quem está usando mais a capacidade de processamento do seu hardware.
O procedimento é simples e pode revelar os vilões do seu sistema. 😉
O comando ps, sozinho, exibe os processos em execução, tal como o comando top.
O top pode ser usado para obter os mesmos resultados, também. Mas vamos ter que abordar seu uso em outro post.
Veja um exemplo de uso do ps:


ps

  PID TTY          TIME CMD
 2037 pts/1    00:00:00 ps
18101 pts/1    00:00:01 bash

O comando ps pode mostrar mais do que apenas isso, com o acréscimo de alguns parâmetros.
Você pode usar o utilitário combinado ao less, para poder ver uma lista maior, com mais conforto:


ps axu | less

Note que os valores de consumo da CPU e da MEMÓRIA se encontram listados na 3a e 4a colunas, respectivamente.
Com o comando, abaixo, vamos ordenar ascendentemente os valores pela coluna 3 (CPU):


ps axu | sort -nk 3

Achou a lista grande? Use o comando tail!


ps axu | sort -nk 3 | tail

www-data 27070  0.0  0.1 405488  9892 ?        S    00:06   0:00 /usr/sbin/apache2 -k start
www-data 32462  0.0  0.1 405488  9892 ?        S    13:35   0:00 /usr/sbin/apache2 -k start
www-data   621  0.0  0.1 362384  7900 ?        S    set25   0:00 php-fpm: pool www
www-data   622  0.0  0.1 362384  7900 ?        S    set25   0:00 php-fpm: pool www
justinc+  1911  0.1  4.7 2044808 375484 tty2   SNl+ set25   5:33 /usr/lib/tracker/tracker-extract
justinc+  1816  0.2  0.1 2215372 15384 ?       S<l  set25   6:33 /usr/bin/pulseaudio --start --log-target=syslog
Root       304  0.5  0.0      0     0 ?        S    set25  18:37 [irq/28-iwlwifi]
justinc+  1790  1.3  4.9 2370480 388544 tty2   Sl+  set25  41:37 /usr/bin/gnome-shell
justinc+  1697  1.5  2.4 514556 194524 tty2    Sl+  set25  49:27 /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3
justinc+ 10865 30.4 29.4 5285500 2315972 tty2  Rl+  set25 972:35 /usr/lib/firefox-esr/firefox-esr

O tail pode ser usado para exibir apenas as últimas 10 linhas da saída de um comando.
Para obter os valores referentes a coluna 4 (memória), use o comando da seguinte forma:


ps axu | sort -nk 4 | tail

root       569  0.0  0.4 362384 32712 ?        Ss   set25   0:11 php-fpm: master process (/etc/php/7.0/fpm/php-fpm.conf)
root       851  0.0  0.4 466684 37800 ?        Ssl  set25   0:24 /usr/lib/packagekit/packagekitd
justinc+  1509  0.0  0.5 619264 42560 ?        Ssl  set25   0:25 /usr/lib/gnome-terminal/gnome-terminal-server
mysql      749  0.0  0.8 686288 66008 ?        Ssl  set25   3:06 /usr/sbin/mysqld
justinc+ 18219  0.0  1.1 946796 92580 ?        Sl   set26   0:04 /usr/bin/gnome-software --gapplication-service
Debian-+   659  0.0  1.3 1789592 108340 tty1   Sl+  set25   1:10 /usr/bin/gnome-shell
justinc+  1697  1.5  2.4 515752 194632 tty2    Sl+  set25  49:29 /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3
justinc+  1911  0.1  4.7 2044808 375484 tty2   SNl+ set25   5:33 /usr/lib/tracker/tracker-extract
justinc+  1790  1.3  4.9 2370740 389348 tty2   Sl+  set25  41:40 /usr/bin/gnome-shell
justinc+ 10865 30.4 28.8 5282432 2268520 tty2  Sl+  set25 973:25 /usr/lib/firefox-esr/firefox-esr

Fácil, não é?

A evolução do procfs para o sysfs

O Linux herdou do UNIX a metodologia para permitir que programas se informassem sobre os processos em andamento no sistema diretamente das estruturas armazenadas na memória do kernel —— ou seja, lendo diretamente o /dev/mem e interpretando os dados “nus e crus” contidos ali.
Era assim que o comando ps funcionava inicialmente.
Com o tempo, parte da informação passou a ser disponibilizada através de system calls.
Expor dados do sistema diretamente ao espaço do usuário, via /dev/mem se provou uma metodologia ineficiente e insegura, com o tempo.
Um novo método foi introduzido para facilitar o acesso a aos dados estruturados do sistema para os aplicativos do user-space — que foi a criação do sistema de arquivos /proc.
Com o /proc, as interfaces e as estruturas (diretórios e arquivos) poderiam se manter, mesmo havendo mudanças nas camadas internas do kernel.
Este método é menos frágil que o anterior e aguenta melhor o aumento na escala de trabalho do sistema.
O /proc filesystem foi projetado originalmente para publicar informações de processos e alguns atributos chave de sistema, requisitados por comandos como o ‘ps’, o ‘top’ e o ‘free’, por exemplo.
Sendo mais fácil de usar e obter informações a partir deste meio – tanto pelo lado do kernel quanto do lado do user-space – ele se tornou um verdadeiro depósito de informações de todo o tipo, vindas do sistema.
Além disto, ganhou arquivos com permissão de gravação, a serem usados para ajustar configurações e controlar a operação do kernel ou algum de seus vários subsistemas.
Em resumo, o aumento no uso do /proc para implementar controle de interfaces contribuiu para reduzir sua eficiência.

Isto levou os desenvolvedores a implementar, no kernel 2.6, uma nova metodologia, através do sysfs.
O sysfs ou /sys filesystem já foi projetado para adicionar suporte à estrutura do /proc e prover uma maneira uniforme de expor as informações do sistema e pontos de controle (sistema ajustável e atributos de drivers) para o user-space a partir do kernel.
Agora o framework de drivers, dentro do kernel, cria automaticamente os diretórios sob /sys a cada vez que um driver é registrado, baseado em seu tipo e nos valores contidos nas suas estruturas de dados.
Isto significa que os drivers de um tipo particular terão todos os mesmos elementos exibidos via sysfs.
O Linux vive uma fase de transição. Hoje, muitas informações “legadas” do sistema ainda são acessíveis no /proc. Contudo, todos os novos bus e drivers precisam expor suas informações e pontos de controle via sysfs — é para lá que estamos caminhando.

Referências

http://unix.stackexchange.com/questions/4884/what-is-the-difference-between-procfs-and-sysfs.

Systemd para administradores, parte 2

Na primeira parte desta série de artigos sobre o systemd, procurei mostrar como é simples obter uma relação dos serviços disparados durante a inicialização do sistema.
Depois do boot, o systemd segue seu trabalho iniciando outros processos.
Neste texto vamos abordar alguns métodos para descobrir qual processo é dono de quais outros processos.
systemd logo
Há um número substancial de processos rodando, por padrão, na maioria dos sistemas GNU/Linux.
Saber o que cada processo faz e a que ele pertence, pode ser uma tarefa difícil para um administrador.
Alguns serviços mantém certos processos ativos, que “se misturam”, na saída do comando ps, e podem ser difíceis de identificar.
Este é o caso, por exemplo, de daemons que geram arbitrariamente processos e mais processos.
Uma forma de remediar esta situação é exibir a relação de processos por ordem de herança, através do comando ‘ps xaf’:

ps xaf

Segue o resultado parcial, obtido no meu sistema:


...

 2440 ?        Ssl    0:00 /usr/sbin/gdm3
 2450 ?        Sl     0:00  \_ gdm-session-worker [pam/gdm-launch-environment]
 2468 tty1     Ssl+   0:00  |   \_ /usr/lib/gdm3/gdm-wayland-session gnome-sessi
 2470 tty1     S+     0:00  |       \_ dbus-daemon --print-address 3 --session
 2471 tty1     Sl+    0:00  |       \_ /usr/lib/gnome-session/gnome-session-bina
 2481 tty1     Sl+    0:04  |           \_ /usr/bin/gnome-shell
 2507 tty1     Sl+    0:00  |           |   \_ /usr/bin/Xwayland :1024 -rootless
 2629 tty1     Sl+    0:00  |           \_ /usr/lib/gnome-settings-daemon/gnome-
 2671 ?        Sl     0:00  \_ gdm-session-worker [pam/gdm-password]
 2719 tty2     Ssl+   0:00      \_ /usr/lib/gdm3/gdm-x-session --run-script defa
 2721 tty2     S+    10:15          \_ /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth
 2754 tty2     S+     0:00          \_ dbus-daemon --print-address 4 --session
 2756 tty2     Sl+    0:00          \_ /usr/lib/gnome-session/gnome-session-bina
 2813 ?        Ss     0:00              \_ /usr/bin/ssh-agent x-session-manager
 2843 tty2     Sl+    4:55              \_ /usr/bin/gnome-shell
 2981 tty2     Sl+    0:01              \_ zeitgeist-datahub
 2982 tty2     Sl+    0:00              \_ /usr/bin/python3 /usr/share/system-co
 2983 tty2     Sl+    0:00              \_ /usr/lib/evolution/evolution-alarm-no
 3002 tty2     SNl+   0:00              \_ /usr/lib/tracker/tracker-miner-apps
 3003 tty2     SNl+   0:10              \_ /usr/lib/tracker/tracker-miner-fs
 3004 tty2     SNl+   0:00              \_ /usr/lib/tracker/tracker-miner-user-g
 3005 tty2     Sl+    0:01              \_ /usr/bin/gnome-software --gapplicatio
 5613 tty2     Sl+    0:02              \_ /usr/lib/gnome-settings-daemon/gnome-

...

O resultado deste método, contudo, não é muito confíável, uma vez que os processos — cujos ascendentes morrem — tem seu “parentesco” realocado ao PID 1, fazendo com que toda informação sobre sua árvore se perca.
Se um processo sofrer um “double fork, ele já perde seu relacionamento com o processo que o gerou.
Isto não é um defeito e está dentro da lógica tradicional de lidar com daemons do Unix.
O problema é que não serve para o que se quer no momento.
A possibilidade de um processo mudar seu nome – com o PR_SETNAME ou ajustando o argv – é um recurso que também atrapalha este objetivo.
Com os métodos tradicionais de identificação de processos, o administrador pode acabar no meio de um jogo (sem graça) de “esconde-esconde” com os seus processos.

A abordagem do systemd

Com o systemd, colocamos cada processo novo em um grupo de controle (ou control group) — que leva o nome do seu serviço.
Os control groups ou cgroups na sua forma mais básica são simplesmente grupos de processos que pode ser organizados em uma hierarquia e rotulados individualmente.
Quando processos geram processos filhos, estes se tornam automaticamente membros dos cgroups de seus pais. Sem privilégios, não é possível abandonar um cgroup.
Por isto é que os cgroups podem ser usados como meio eficiente de rotular processos a partir do serviço a que cada um pertence. Além de nos dar a certeza de que os serviços não irão se livrar de seus rótulos, independente da quantidade de vezes em que fizerem forks de si mesmos ou se renomearem.
Neste post, quero introduzir dois comandos que podem ajudar a relacionar serviços e processos do systemd.
O primeiro é o (já conhecido) ps e o segundo é o systemd-cgl.

Relacione processos com o comando ps

O comando ps tem opções para exibir informações dos cgroups junto aos outros detalhes dos processos.
Veja um exemplo (com resultado parcial) do uso do comando:

ps xawf -eo pid,user,cgroup,args
 PID  USER     CGROUP                      COMMAND

...

 2410 root     7:pids:/system.slice,3:devi /usr/sbin/irqbalance --pid=/var/run/irqbalance.pid
 2411 root     7:pids:/system.slice,3:devi /usr/lib/policykit-1/polkitd --no-debug
 2421 root     7:pids:/system.slice,3:devi /usr/sbin/cups-browsed
 2429 colord   7:pids:/system.slice,3:devi /usr/lib/colord/colord
 2440 root     7:pids:/system.slice,3:devi /usr/sbin/gdm3
 2450 root     7:pids:/user.slice/user-116  \_ gdm-session-worker [pam/gdm-launch-environment]
 2468 Debian-+ 7:pids:/user.slice/user-116  |   \_ /usr/lib/gdm3/gdm-wayland-session gnome-session --autostart /usr/share/gdm/greete
 2470 Debian-+ 7:pids:/user.slice/user-116  |       \_ dbus-daemon --print-address 3 --session
 2471 Debian-+ 7:pids:/user.slice/user-116  |       \_ /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greete
 2481 Debian-+ 7:pids:/user.slice/user-116  |           \_ /usr/bin/gnome-shell
 2507 Debian-+ 7:pids:/user.slice/user-116  |           |   \_ /usr/bin/Xwayland :1024 -rootless -noreset -listen 4 -listen 5 -displ
 2629 Debian-+ 7:pids:/user.slice/user-116  |           \_ /usr/lib/gnome-settings-daemon/gnome-settings-daemon
 2671 root     7:pids:/user.slice/user-100  \_ gdm-session-worker [pam/gdm-password]
 2719 justinc+ 7:pids:/user.slice/user-100      \_ /usr/lib/gdm3/gdm-x-session --run-script default
 2721 justinc+ 7:pids:/user.slice/user-100          \_ /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -back
 2754 justinc+ 7:pids:/user.slice/user-100          \_ dbus-daemon --print-address 4 --session
 2756 justinc+ 7:pids:/user.slice/user-100          \_ /usr/lib/gnome-session/gnome-session-binary
 2813 justinc+ 7:pids:/user.slice/user-100              \_ /usr/bin/ssh-agent x-session-manager
 2843 justinc+ 7:pids:/user.slice/user-100              \_ /usr/bin/gnome-shell
 2981 justinc+ 7:pids:/user.slice/user-100              \_ zeitgeist-datahub
 2982 justinc+ 7:pids:/user.slice/user-100              \_ /usr/bin/python3 /usr/share/system-config-printer/applet.py
 2983 justinc+ 7:pids:/user.slice/user-100              \_ /usr/lib/evolution/evolution-alarm-notify
 3002 justinc+ 7:pids:/user.slice/user-100              \_ /usr/lib/tracker/tracker-miner-apps
 3003 justinc+ 7:pids:/user.slice/user-100              \_ /usr/lib/tracker/tracker-miner-fs
 3004 justinc+ 7:pids:/user.slice/user-100              \_ /usr/lib/tracker/tracker-miner-user-guides
 3005 justinc+ 7:pids:/user.slice/user-100              \_ /usr/bin/gnome-software --gapplication-service
 5613 justinc+ 7:pids:/user.slice/user-100              \_ /usr/lib/gnome-settings-daemon/gnome-settings-daemon
 2455 root     7:pids:/system.slice,3:devi /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
 2462 Debian-+ 7:pids:/user.slice/user-116 /lib/systemd/systemd --user
 2463 Debian-+ 7:pids:/user.slice/user-116  \_ (sd-pam)
 2485 root     7:pids:/system.slice,3:devi /usr/lib/upower/upowerd
 2532 Debian-+ 7:pids:/user.slice/user-116 /usr/lib/at-spi2-core/at-spi-bus-launcher
 2551 Debian-+ 7:pids:/user.slice/user-116  \_ /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --n

...

Na terceira coluna, da listagem, é exibido o cgroup dado pelo systemd a cada processo.
Se você pretende rodar este comando com frequência, crie um alias para ele:

alias psc='ps xawf -eo pid,user,cgroup,args'

Agora, basta usar o alias psc.

Relacione os processos com o systemd-cgls

Talvez você julgue mais adequado relacionar processos com seus cgroups usando a ferramenta systemd-cgls.
Ela exibe cada cgroup hierarquicamente, dentro de uma árvore.
Veja um exemplo:

systemd-cgls

...

│ ├─polkitd.service
│ │ └─2411 /usr/lib/policykit-1/polkitd --no-debug
│ ├─cups-browsed.service
│ │ └─2421 /usr/sbin/cups-browsed
│ ├─NetworkManager.service
│ │ ├─2332 /usr/sbin/NetworkManager --no-daemon
│ │ └─2583 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /
│ ├─irqbalance.service
│ │ └─2410 /usr/sbin/irqbalance --pid=/var/run/irqbalance.pid
│ ├─rsyslog.service
│ │ └─2337 /usr/sbin/rsyslogd -n
│ ├─gdm.service
│ │ └─2440 /usr/sbin/gdm3
│ ├─bluetooth.service
│ │ └─7068 /usr/lib/bluetooth/bluetoothd
│ └─rtkit-daemon.service
    └─2569 /usr/lib/rtkit/rtkit-daemon

...

Novamente, o resultado exibido no meu exemplo está resumido (cortado) para tentar evitar informações irrelevantes para o contexto deste artigo.
Aqui, são exibidos os processos, por cgroups e, consequentemente, por serviços, uma vez que o systemd etiqueta os cgroups pelos seus serviços.

Referências

Outros posts sobre o systemd.
Systemd para administradores – parte 1.
http://0pointer.de/blog/projects/systemd-for-admins-2.html.

Entenda o que é kernel mode e user mode no Linux

Neste texto são introduzidos dois conceitos aos quais nos referimos comumente quando falamos de sistemas operacionais, relacionados aos modos de execução dos processos.
Nosso foco é GNU/Linux, mas a teoria se aplica a qualquer outro sistema moderno e de uso comum.
Embora seja um post de conteúdo teórico, espero conseguir resumir sem perder o significado dos conceitos. Clique nos links (no decorrer do texto e ao final), caso deseje se aprofundar mais no assunto.
O kernel mode ou modo kernel, costuma ser referenciado também como system mode.
Este é um dos dois modos distintos de operação da CPU no Linux.
O outro é o user mode, um modo desprivilegiado, que existe para rodar os programas dos usuários e todas as outras coisas que não sejam do kernel.
Nos próximos tópicos vamos detalhar cada um destes conceitos.

Entenda o que é o kernel mode

Quando a CPU se encontra no kernel mode é presumido que esteja rodando software confiável e, portanto, pode executar qualquer instrução e acessar qualquer endereço de memória.

O kernel é o núcleo do sistema operacional e tem total controle sobre tudo o que ocorre no sistema, como um todo.

Se, por um lado, o kernel é software confiável, todos os outros programas não o são.
Por isto, os programas em user mode, quando precisam requisitar o uso do kernel, o fazem através de uma system call (ou chamada de sistema). Só então podem (ou não) executar instruções de nível privilegiado — tais como criação de processos, entrada e saída de operações etc.
Em sistemas operacionais Unix-like ou semelhantes ao Unix, uma system call é a requisição de algum serviço do kernel, feita por um processo ativo.
Um processo é uma instância em execução de algum programa. Um processo ativo é uma instância cuja execução está em andamento dentro da CPU — enquanto outros processos estão esperando, na memória, por sua vez de usá-la.
Entrada/Saída (ou Input/Output) se refere a qualquer programa, operação ou dispositivo que realize transferência de dados da CPU ou a partir de um periférico (drives, teclados, impressoras etc.)
Até a versão 2.4, o kernel do Linux era non-preemptive — ou seja, quando um processo estivesse rodando em kernel mode ele não poderia ser arbitrariamente suspenso ou substituído por outro processo até que terminasse sua execução.

Em um kernel preemptivo, o processo A é deixado sem terminar. O agendador decide depois se ele recebe tempo de execução na CPU ou não.
Em um kernel não-preemptivo, o processo A simplesmente teria usado todo o tempo que necessitasse da CPU até terminar ou voluntariamente decidir liberar seu tempo a outros processos.

Em um kernel preemptivo, um processo rodando no kernel mode pode ser substituído por outro processo enquanto se encontra no meio de uma função.
Uma interrupção é um sinal dado ao sistema operacional para informar que um evento acabou de ocorrer — o que resulta em uma mudança na sequência de instruções que são executadas pela CPU.
Interrupções de hardware podem ser causadas por teclado (quando um usuário pressiona uma tecla, por exemplo), por mouse etc.
Interrupções de software podem ser disparadas de dentro de um programa em user mode.

Uma interrupção de software, também chamada exceção, é uma suspensão causada por software, normalmente rodando em user mode.

O procedimento mais comum de mudança do user mode para kernel mode é chamar a interrupção de software 0x80.
Já as exceções (exceptions) são condições incomuns — tais como instruções inválidas dentro do código de algum programa.

O int 0x80 é uma instrução na linguagem assembly usada para invocar system calls no Linux executado na arquitetura x86.

Todos os processos começam sua execução em user mode. Alternam para o kernel mode apenas quando obtém algum serviço fornecido pelo kernel.

Quando o processo de um usuário roda uma porção do código do kernel via system call, ele se torna temporariamente um processo do kernel e em kernel mode.
Enquanto estiver neste modo, terá privilégios administrativos e acesso a recursos chave do sistema.
Depois de satisfeita a sua requisição, ele é retornado ao user mode.
Algumas CPUs são projetadas para acomodar mais de um modo de execução. Contudo todos os kernels padrão, em sistemas operacionais Unix-like comuns usam apenas estes dois.

Alguns sistemas operacionais, como o MS-DOS, que é predecessor do Windows, não possuem um kernel mode distinto. Em vez disto, permitem que programas de usuários interajam diretamente com os componentes do hardware.

Os sistemas operacionais que seguem a linha do Unix usam este mecanismo de dois modos para esconder todos os detalhes físicos da máquina dos programas lançados pelo usuário, como forma de assegurar a estabilidade e a segurança do sistema.
Com o lançamento da versão 2.6 do Linux kernel, ao final de 2003, este passou a ser preemptivo, ou seja, um processo rodando dentro do kernel mode pode ser suspenso de forma a dar lugar a outro. O que pode ser um benefício importante para aplicações de tempo real — ou seja, sistemas que precisam responder a eventos externos imediatamente.
Os kernéis Unix-like são também reentrantes, o que significa que vários processos podem se encontrar simultaneamente em kernel mode.
Em um sistema com um único processador, contudo, apenas um processo, qualquer que seja o modo, progredirá dentro da CPU a cada momento — os outros ficarão temporariamente bloqueados, até que lhes chegue a vez.

Entenda o que é o user mode

O user mode ou modo usuário é a outra parte dos dois modos de execução de processos no Linux, de que estamos falando neste texto.
Trata-se de um modo de execução não-privilegiado, no qual cada processo se inicia.
É dito “não-privilegiado” por que, nele, os processos são proibidos de acessar porções da memória RAM, que tenham sido alocadas para uso do kernel ou de outros programas.

O kernel não é um processo, mas um controlador de processos. Ele, sozinho, tem acesso a todos os recursos do sistema.

Quando um processo, em user mode, quer usar um serviço provido pelo kernel — ou seja, acessar recursos do sistema além do espaço limitado de memória alocado para ele — ele precisa ser movido temporariamente ao kernel mode, onde irá dispôr de privilégios administrativos (i.e., root). Uma vez satisfeita a requisição, é restaurado ao user mode.
Esta mudança é chamada de mode switch ou alternância de modo.

Referências

http://unix.stackexchange.com/questions/5180/what-is-the-difference-between-non-preemptive-preemptive-and-selective-preempti
http://www.linfo.org/kernel_mode.html
http://www.linfo.org/user_mode.html