DEV Community: Lucas Riboli

Daemons: From Physics (?) to Linux System Control

Lucas Riboli — Sat, 27 Sep 2025 23:21:30 +0000

If there's one set of concepts and stories I've always liked, it's those related to physics, mythology, and computing. While going about my business on the interwebs and in my daily work, I once stumbled upon DAEMONS. Well, the name immediately grabs your attention, and in my opinion, the concept do too. So, let's take a closer look.

In 1871 (although he had cited it earlier in 1867), James Clerk Maxwell, to explain the second law of thermodynamics, proposed a thought experiment to refute it. He imagined a finite being, capable of manipulating molecules in a closed system, who observed and made decisions about opening or closing a door to allow the passage of fast molecules—basically, a being he considered impossible to exist. Later, Lord Kelvin called this being a "daemon," not in the negative sense (he wasn't talking about a kid's backpack, 7-skins, or cold synthetic... This are brazilian ways to call the devil), but referring to a supernatural creature that works behind the scenes, the concept of the daemon from Greek mythology: invisible beings to humans, carrying out important tasks.

This "daemon" concept is often associated with computing, although the link might not even exist, as, in the context of computers, the term has taken on its own specific technical meaning (but let's suppose the link exists; it makes everything cooler).

But why would there be this connection?

Well, the general idea is the same, but no longer as a thought experiment, but as something virtual. In operating systems, we have to keep the complex system under constant observation and action, without direct user intervention—that is, a true Greek daemon.

And voilà, there we have it: Linux Daemons. They remain in a state of slumber (they aren't actually off, but I'll explain this better later), being executed by a trigger, at regular intervals (usually seconds or milliseconds), or continuously processing queues. They exist for all types and functions, but the constant is: they operate autonomously, without depending on user action, maintaining the operation of the operating system or managing functions that may eventually be used by interactive processes.

One important example of a daemon management system, widely adopted in many modern distributions, is systemd. It functions as a central manager: it starts and controls many other services, analyzing .service files to determine the execution order, the location of the process binary, and how to manage its inputs and outputs.

In practice, daemons are the foundation of Linux, operating at various levels, from functions close to the hardware to user applications. Almost everything we use or see in our workflow has a daemon behind it. And the best part is, we can create our own daemons to execute tasks that don't require our direct attention, running in the background.

Today, in many modern systems, systemd is a widely used daemon manager, although alternatives like OpenRC, runit, and s6 have their own merits and proponents. With systemd, we can, for example, create a service that monitors hardware temperature and automatically generates logs, or run "one-shot" applications under its control, managing their execution, status, and eventual errors.

Of course, there are many other daemons—as I said, they are everywhere, even where we might not expect (?). Take the Apache HTTP Server (httpd), a popular web server that operates as a daemon (I didn't know until I looked into it). There's also crond, responsible for scheduled tasks present in cronjobs, and this one has an interesting point: if we think about it directly, it executes tasks we create and ask to run at certain times or at regular intervals, and when they're not running, they are idle—very similar to daemons themselves!

So, are my schedulers daemons too? The line can be thin, as they share characteristics. The main difference is that many daemons are not actually "dormant"; they are actually assuming different "states." (I said I'd mention this again)

Interruptible Sleep (S): In this state, they are actively executing, monitoring events, interfaces, or ports. For example, sshd is always waiting for connections on port 22, or cupsd is waiting for someone to send something for printing.
Uninterruptible Sleep (D): In this state, it is waiting for an I/O operation to complete. For example, during a large file copy, rsync might appear in state D.

In other words, some use polling, others operate based on system events or task queues, etc. In fact, both daemons and schedulers can face delays due to system conditions, although daemons are typically designed to maximize efficiency and responsiveness.

It's also interesting to know that there are several ways to create a daemon—some old and conventional, others modern and very resilient, or somewhere in between.

A traditional way would be a script in init.d, which is part of the SysV initialization system. This model preceded systemd and was the standard in Linux distributions for many years. SysV init uses scripts in /etc/init.d/ to start, stop, and manage services in different runlevels, offering a simpler but less parallelized system than systemd. This approach is still supported in many distributions for compatibility reasons.

We can also create direct scripts with a loop or by observing queues without any control—possibly the easiest way, but the most problematic: the application runs without any control, management, etc.

But not everything is so black and white. Within the Linux community, there are those who see systemd as an unacceptable paradigm shift. The Unix philosophy preaches to "Do One Thing and Do It Well." Systemd does many things; for some, this is practical and a very favorable application design; for others, it's complexity and increased risk.

Hands On - Systemd

Well, we've seen the theory, and although I find the idea very cool, let's move on to some practice now.

I must warn you that I will only cover systemd in this Hands-On; I have nothing against the other ways of creating a daemon, it's just for the practicality and visualization we'll have.

Before getting our hands dirty and creating a daemon, let's analyze some existing ones within a small lab. So, let's go.

Lab:

Troubleshooting Laboratory with Systemd and Journal

The idea in this lab is to practice how to create a daemon using systemd and perform troubleshooting using journalctl and systemd itself.

Part 1:

1.

Create a simple script that will serve as our service:

sudo vi /usr/local/bin/my-service.sh

And inside the service, let's add a small loop made with bash:

#!/bin/bash
echo "Starting my-service"
logger "my-service started"
count=1
while true; do
    echo "my-service is running: iteration $count"
    logger "my-service is running: check #$count"
    count=$((count+1))
    sleep 15
done

NOTE: Any content can be used, but you can use this if you want something ready.

2.

Now let's allow this service to run:

sudo chmod +x /usr/local/bin/my-service.sh

3.

Great, if everything is correct so far, now let's create a systemd config file for the service:

sudo vi /etc/systemd/system/my-service.service

Add the following content:

[Unit]
Description=My test service
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/my-service.sh
Restart=always
RestartSec=5
StandardOutput=journal
StandardError=journal

SyslogIdentifier=my-service

[Install]
WantedBy=multi-user.target

4.

Okay, now let's start everything. To do this, follow these steps:

sudo systemctl daemon-reload
sudo systemctl enable my-service.service
sudo systemctl start my-service.service

5.

To check if the service is running correctly, we can execute the following command:

sudo systemctl status my-service.service

If you see it's running, congratulations! We've successfully created our first daemon using systemd.

6.

Now let's check the logs of our service:

sudo journalctl -u my-service.service -f

The -f (follow) parameter shows the messages in real time.

Part 2:

Ah, great, our daemon is running, everything is fine and peaceful. But it's time to break things...

Let's break the service in various ways to practice troubleshooting.

Scenario 1: Corrupt the service script

Let's access the script code again:

sudo vi /usr/local/bin/my-service.sh

Let's insert some syntax error:

Restart the service:

sudo systemctl restart my-service.service

Scenario 2: Modify script permissions

sudo chmod -x /usr/local/bin/my-service.sh
sudo systemctl restart my-service.service

Part 3:

Now let's use the systemd and journal tools to diagnose the problems.

1. Check service status

sudo systemctl status my-service.service

Observe the error codes, messages, and status.

# View all service logs
sudo journalctl -u my-service.service

# View only error logs
sudo journalctl -u my-service.service -p err

# View logs from a specific period
sudo journalctl -u my-service.service --since "10 minutes ago"

# View logs from the current boot
sudo journalctl -u my-service.service -b

# Check service dependencies
sudo systemctl list-dependencies my-service.service

# Check service configuration
sudo systemctl cat my-service.service

# Check processes
ps aux | grep my-service

All these commands will help you in troubleshooting. I recommend running them and seeing what each one does, trying to grasp every nuance. Now, try to find the errors within the logs, break it again (or more), correct them, and restart the daemon. In the end, that's the idea...

Practice so that if one day you have to create one and work on it, everything will be smooth.

Daemons Linux na Prática: Da Teoria ao Troubleshooting

Lucas Riboli — Sun, 18 May 2025 14:21:30 +0000

Daemons: Da Física ao Controle de Sistemas Linux

Em 1871, James Clerk Maxwell, para explicar a segunda lei da termodinâmica, propôs um experimento mental bastante curioso. Ele imaginou um ser finito, capaz de manipular moléculas em um sistema fechado, observando e tomando decisões sobre abrir ou fechar uma porta para permitir a passagem de moléculas rápidas. Mais tarde, Lord Kelvin chamou esse ser de "demônio", não no sentido de uma entidade maléfica, mas referindo-se a uma criatura sobrenatural que trabalha nos bastidores, como o conceito de daemon na mitologia grega — seres invisíveis aos humanos, executando tarefas importantes.

Esta analogia com o conceito de "daemon" é frequentemente citada em discussões sobre o termo em computação, embora a ligação histórica direta seja objeto de debate. No contexto dos computadores, o termo assumiu seu próprio significado técnico específico— mas vamos supor que seja verdade, deixa tudo mais legal —.
Mas como essa ideia se aplica na prática?

A ideia central permanece: agora, não mais como um experimento mental, mas como algo concreto. Nos sistemas operacionais, enfrentamos o desafio de manter um sistema complexo sob constante observação e ação, sem a intervenção direta do usuário — ou seja, um verdadeiro daemon grego.

Para isso, surgiram os processos que rodam em segundo plano, conhecidos como daemons. Eles permanecem em estado de dormência — ele nao fica de fato off, mas vou explicar melhor mais a frente — , sendo executados por algum gatilho, em intervalos regulares (geralmente segundos ou milissegundos), ou ainda processando filas continuamente. Existem de todos os tipos e funções, mas a constante é: eles operam de forma autônoma, sem depender da ação do usuário, mantendo o funcionamento do sistema operacional ou gerenciando funções que, eventualmente, podem ser usadas por processos interativos.

Um exemplo importante de sistema de gerenciamento de daemons — e amplamente adotado em muitas distribuições modernas — é o systemd. Ele funciona como um gerenciador central: inicia e controla muitos outros serviços, analisando arquivos .service para determinar a ordem de execução, localização do binário do processo, e como gerenciar suas entradas e saídas.

Na prática, daemons são a base do Linux, atuando em diversos níveis, desde funções próximas ao hardware até aplicações de usuário. Quase tudo o que usamos ou vemos em nosso workflow tem um daemon por trás. E o melhor: podemos criar nossos próprios daemons para executar tarefas que não requerem nossa atenção direta, funcionando em segundo plano.

Hoje, em muitos sistemas modernos, o systemd é um gerenciador de daemons amplamente utilizado, embora existam alternativas como OpenRC, runit e s6 que têm seus próprios méritos e defensores. Com o systemd, podemos, por exemplo, criar um serviço que monitora a temperatura do hardware e gera logs automaticamente, ou executar aplicações "one shot" sob seu controle, gerenciando sua execução, status e eventuais erros.

Claro, existem diversos outros daemons — como eu disse, eles estão por tudo e até onde a gente talvez (?) nem imagine — como o Apache HTTP Server (httpd), que é um servidor web popular que opera como daemon. Existe o crond, responsável pelas suas tarefas agendadas presentes nos cronjobs, e esse cara tem um ponto interessante, pois se pensarmos de uma forma direta, ele executa tarefas que criamos e pedimos para rodar em determinados momentos ou de tanto em tanto tempo e quando não rodam eles ficam parados, muito semelhante aos próprios daemons!

Seriam meus schedulers daemons também? A linha pode ser tênue, pois compartilham características. A principal diferença é que muitos daemons não estão realmente "dormentes" como se poderia pensar - estão ativamente executando, monitorando eventos, interfaces ou portas, estão em Interruptible Sleep (S) ou Uninterruptible Sleep(D), sendo esperando algum evento e aguardando uma operação I/O ser concluída respectivamente. Alguns utilizam polling contínuo, outros operam baseados em eventos do sistema ou filas de tarefas. Na verdade, tanto daemons quanto schedulers podem enfrentar atrasos devido a condições do sistema, embora daemons sejam normalmente projetados para maximizar a eficiência e resposta.

É interessante também saber que existem várias formas de criar um daemon, algumas antigas e usuais, outras modernas e muito resilientes, ou meio-termo.

Uma forma tradicional seria um script no init.d, que faz parte do sistema de inicialização SysV. Este modelo precedeu o systemd e foi o padrão em distribuições Linux por muitos anos. O SysV init utiliza scripts em /etc/init.d/ para iniciar, parar e gerenciar serviços em diferentes runlevels, oferecendo um sistema mais simples mas menos paralelizado que o systemd. Essa abordagem ainda é suportada em muitas distribuições por razões de compatibilidade.

Também podemos criar scripts diretos com loop ou observando filas sem nenhum controle, possivelmente a forma mais fácil mas a mais problemática: a aplicação sem nenhum controle, gerenciamento etc.

Mas nem tudo é tão preto no branco assim, dentro da comunida Linux, há quem veja o systemd como um quebra de paradigmas inaceitavel. A filosofia Unix prega que "faça uma coisa e faça bem feito" ("Do One Thing and Do It Well"). O systemd faz muitas coisas, para alguns isso é praticidade e um design de aplicação muito favoravel para outros é complexidade e risco de mais. Ouve alguns posicionamentos de algumas figurinhas famosas na comunidade como o de Linus Torvalds que ve de forma neutra e até positiva.

Hands On - Systemd

Mas não basta entender o conceito — como isso aparece no Linux real que usamos todos os dias? Vamos olhar um pouco para a prática.

Fica aqui o alerta, que vou tratar apenas de systemd nesse hands On, nada contra as demais formas de criar um deamon, é apenas pela praticidade e visualização que teremos.

Antes de colocar a mão na massa e criar algum deamon, vamos analisar alguns ja existentes dentro de um pequeno lab, entao bora lá.

Laboratório de Troubleshooting com Systemd e Journal

A ideia nesse lab é a gente exercitar como seria criar um deamon usando o systemd e fazer troubleshooting usando journal e o proprio systemd

Parte 1: Criando um Serviço de Teste

1. Crie um script simples que servirá como nosso serviço

sudo nano /usr/local/bin/meu-servico.sh

Adicione o seguinte conteúdo:

#!/bin/bash
echo "Iniciando meu-servico"
logger "meu-servico iniciado com sucesso"
count=1
while true; do
    echo "meu-servico está funcionando: iteração $count"
    logger "meu-servico está rodando: verificação #$count"
    count=$((count+1))
    sleep 10
done

OBS: pode ser qualquer conteudo mas caso queira algo pronto pode usar esse.

2. Torne o script executável

sudo chmod +x /usr/local/bin/meu-servico.sh

3. Crie um arquivo de unidade systemd para o serviço

sudo nano /etc/systemd/system/meu-servico.service

Adicione o seguinte conteúdo:

[Unit]
Description=Meu servico executando
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/meu-servico.sh
Restart=always
RestartSec=5
StandardOutput=journal
StandardError=journal

SyslogIdentifier=meu-servico

[Install]
WantedBy=multi-user.target

4. Recarregue a configuração do systemd, habilite e inicie o serviço

sudo systemctl daemon-reload
sudo systemctl enable meu-servico.service
sudo systemctl start meu-servico.service

5. Verifique se o serviço está funcionando corretamente

sudo systemctl status meu-servico.service

Observe o status (deve estar "active (running)") e as linhas de log recentes.

6. Verifique os logs do serviço

sudo journalctl -u meu-servico.service -f

O parâmetro -f (follow) mostra as mensagens em tempo real.

Parte 2: Quebrando o Serviço Intencionalmente

Agora vamos quebrar o serviço de várias maneiras para praticar diagnóstico.

Cenário 1: Corromper o script do serviço

sudo nano /usr/local/bin/meu-servico.sh

Modifique o script inserindo um erro de sintaxe ou um comando inválido:

Reinicie o serviço:

sudo systemctl restart meu-servico.service

Cenário 2: Modificar as permissões do script

sudo chmod -x /usr/local/bin/meu-servico.sh
sudo systemctl restart meu-servico.service

Cenário 3: Dependência quebrada

Modifique o arquivo de unidade do serviço para criar uma dependência inexistente:

sudo nano /etc/systemd/system/meu-servico.service

Adicione uma linha de dependência para um serviço inexistente:

[Unit]
Description=Meu Serviço de Exemplo
After=network.target
Requires=servico-inexistente.service

Recarregue e tente reiniciar:

sudo systemctl daemon-reload
sudo systemctl restart meu-servico.service

Parte 3: Investigação e Diagnóstico

Agora vamos usar as ferramentas do systemd e journal para diagnosticar os problemas.

1. Verificar status do serviço

sudo systemctl status meu-servico.service

Observe os códigos de erro, mensagens e status.

2. Analisar logs do journal

# Ver todos os logs do serviço
sudo journalctl -u meu-servico.service

# Ver apenas os logs de erro
sudo journalctl -u meu-servico.service -p err

# Ver logs de um período específico
sudo journalctl -u meu-servico.service --since "10 minutes ago"

# Ver logs do boot atual
sudo journalctl -u meu-servico.service -b

3. Verificar dependências do serviço

sudo systemctl list-dependencies meu-servico.service

4. Verificar configuração do serviço

sudo systemctl cat meu-servico.service

5. Verificar processos

ps aux | grep meu-servico

Parte 4: Corrigindo os Problemas

Agora vamos corrigir os problemas que criamos:

Corrigir Cenário 1 (erro de sintaxe)

sudo nano /usr/local/bin/meu-servico.sh

DEsfaca o erro de sintexe ou comando invalido

Corrigir Cenário 2 (permissões)

sudo chmod +x /usr/local/bin/meu-servico.sh

Corrigir Cenário 3 (dependência quebrada)

sudo nano /etc/systemd/system/meu-servico.service

Remova a linha Requires=servico-inexistente.service.

Recarregar e reiniciar

sudo systemctl daemon-reload
sudo systemctl restart meu-servico.service

Conclusão

Acredito que passamos por diversos pontos desde a história e alguns fundamentos dos deamons até o lab com um pouco de mão na massa. Por fim era isso;
hehehehehe, thank you. - Resident Evil 4, Merchant