Estou usando um arquivo de unidade systemd para controlar um processo python em execução em um servidor (com systemd v247).

Este processo deve ser reiniciado 60 segundos após sua saída, seja em caso de falha ou sucesso, exceto se falhar 5 vezes em 600 segundos.

Este arquivo de unidade vincula outro serviço para notificar falhas por e-mail.

/etc/systemd/system/python-test.service

[Unit]
After=network.target
OnFailure=mailer@%n.service

[Service]
Type=simple

ExecStart=/home/debian/tmp.py

# Any exit status different than 0 is considered as an error
SuccessExitStatus=0

StandardOutput=append:/var/log/python-test.log
StandardError=append:/var/log/python-test.log

# Always restart service 60sec after exit
Restart=always
RestartSec=60

# Stop restarting service after 5 consecutive fail in 600sec interval
StartLimitInterval=600
StartLimitBurst=5

[Install]
WantedBy=multi-user.target

/etc/systemd/system/[email protected]

[Unit]
After=network.target

[Service]
Type=oneshot

ExecStart=/home/debian/mailer.py --to "[email protected]" --subject "Systemd service %I failed" --message "A systemd service failed %I on %H"

[Install]
WantedBy=multi-user.target

O acionamento de OnFailurefuncionou muito bem durante o teste básico. No entanto, quando adicionei a seção a seguir ao arquivo da unidade, ela OnFailurefoi acionada apenas quando as 5 falhas consecutivas ocorreram.

StartLimitInterval=600
StartLimitBurst=5

Este não é o comportamento que eu gostaria, pois quero ser notificado sempre que o processo falhar, mesmo que o limite de burst ainda não tenha sido atingido.

Ao verificar o status do processo, a saída não é a mesma quando o limite de rajada não é atingido

● python-test.service
     Loaded: loaded (/etc/systemd/system/python-test.service; disabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Thu 2022-12-22 19:51:23 UTC; 2s ago
    Process: 1421600 ExecStart=/home/debian/tmp.py (code=exited, status=1/FAILURE)
   Main PID: 1421600 (code=exited, status=1/FAILURE)
        CPU: 31ms

Dec 22 19:51:23 test-vps systemd[1]: python-test.service: Failed with result 'exit-code'.

Do que quando é

● python-test.service
     Loaded: loaded (/etc/systemd/system/python-test.service; disabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2022-12-22 19:52:02 UTC; 24s ago
    Process: 1421609 ExecStart=/home/debian/tmp.py (code=exited, status=1/FAILURE)
   Main PID: 1421609 (code=exited, status=1/FAILURE)
        CPU: 31ms

Dec 22 19:51:56 test-vps systemd[1]: python-test.service: Failed with result 'exit-code'.
Dec 22 19:52:02 test-vps systemd[1]: python-test.service: Scheduled restart job, restart counter is at 5.
Dec 22 19:52:02 test-vps systemd[1]: Stopped python-test.service.
Dec 22 19:52:02 test-vps systemd[1]: python-test.service: Start request repeated too quickly.
Dec 22 19:52:02 test-vps systemd[1]: python-test.service: Failed with result 'exit-code'.
Dec 22 19:52:02 test-vps systemd[1]: Failed to start python-test.service.
Dec 22 19:52:02 test-vps systemd[1]: python-test.service: Triggering OnFailure= dependencies.

Não consegui encontrar nada explicando como modificar o acionamento de OnFailuredentro do arquivo da unidade.

Existe uma maneira de notificar os e-mails sempre que o processo falhar e ainda manter o limite de rajada?

Eu tenho uma regra udev que monta automaticamente o dispositivo usb quando conectado

A regra é a seguinte:

# cat /etc/udev/rules.d/10-usbdetectd.rules 
KERNEL!="sd[a-z]*", GOTO="media_by_label_auto_mount_end"
# Import FS infos
IMPORT{program}="/sbin/blkid -o udev -p %N"
# Global mount options
ACTION=="add", ENV{mount_options}="relatime"
# Filesystem-specific mount options
ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,uid=1000,gid=1000,umask=022"
# Mount the device
ACTION=="add", RUN+="/bin/mount -o $env{mount_options} /dev/%k /media/usb"
# Clean up after removal
ACTION=="remove", RUN+="/bin/umount -l /media/usb" 
# Exit
LABEL="media_by_label_auto_mount_end"

Esta regra está funcionando bem, porém, gostaria de montar o dispositivo com permissões totais. Para fazer isso, tenho que definir umask = 000

Quando estou tentando manualmente, funciona como esperado

# ls -dl /media/usb/
drwxr-xr-x    2 root     root          4096 Jan 29  2019 /media/usb/

# mount -o relatime,utf8,uid=1000,gid=1000,umask=000 /dev/sda1 /media/usb/

# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root              6643016     86356   6199492   1% /
devtmpfs                223204         0    223204   0% /dev
tmpfs                   256484         0    256484   0% /dev/shm
tmpfs                   256484        48    256436   0% /tmp
tmpfs                   256484       132    256352   0% /run
/dev/mmcblk0p1           20185      2854     17331  14% /boot
/dev/sda1              1957600        96   1957504   0% /media/usb

# ls -dl /media/usb/
drwxrwxrwx    2 user    user        16384 Jan  1  1970 /media/usb/

Porém quando a montagem é feita pelo udev, a máscara não é aplicada

# ls -dl /media/usb/
drwxr-xr-x    2 root     root          4096 Jan 29  2019 /media/usb/

[USB drive plug]

# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root              6643016     86356   6199492   1% /
devtmpfs                223204         0    223204   0% /dev
tmpfs                   256484         0    256484   0% /dev/shm
tmpfs                   256484        52    256432   0% /tmp
tmpfs                   256484       132    256352   0% /run
/dev/mmcblk0p1           20185      2854     17331  14% /boot
/dev/sda1              1957600        96   1957504   0% /media/usb

# ls -dl /media/usb/
drwxr-xr-x    2 root     root         16384 Jan  1  1970 /media/usb/

Parece que quando a montagem é feita pelo udev, nenhuma das opções de montagem é aplicada.

uid=1000 e gid=1000 correspondem ao meu usuário

# cat /etc/passwd 
[...]
user:x:1000:1000:- Standard user:/home/user:/bin/bash
[...]

Tenho um Linux embarcado em uma placa personalizada e gostaria de enviar e receber arquivos pela porta serial.

A única maneira de se comunicar com este dispositivo é via serial e o dispositivo oferece um console nesta porta serial.

Esta placa não tem kermitnem busybox rxnem lrzsz.

- Envio de arquivo para controle remoto

Consegui enviar o arquivo para o conselho seguindo este tópico .

Host side                              Remote side

cat file | base64 > file_b64
                                       cat > file_b64
minicom's ctrlA-S => send 'file_b64'
                                       cat file_b64 | base64 --decode > file

- Obtendo arquivo do controle remoto

Agora eu gostaria de recuperar um arquivo do sistema remoto.

O Minicom tem uma ferramenta para recebimento de arquivos mas como só tenho o console da porta serial usando o minicom para emitir comandos no lado remoto, não encontro como fazer.

Eu tentei usar o kermit no lado do host, mas parece que também preciso ter o kermit no lado remoto.

EDITAR:

Eu também tentei reverter o método de envio, mas sem sucesso, pois não recebo nada da porta serial no lado do host.

Host side                              Remote side

                                       cat file | base64 > file_b64
                                       (sleep 10; cat file_b64 > /dev/ttyS0) &
                                       minicom's ctrlA-X => exit minicom
cat /dev/ttyUSB0 > file_b64

Não é possível usar a ferramenta de recebimento do minicom porque ela suporta apenas xmodem, ymodem, zmodeme kermittransferências e não ascii.

Existe uma maneira de recuperar arquivos do controle remoto sem precisar digitar comandos em seu console?

Como posso verificar o formato do sistema de arquivos de uma imagem de disco?

Sei que posso verificar com o filecomando, mas gostaria de automatizar o comportamento.

$ file img.raw
img.raw:   data

$ file img.ext4
img.raw:   Linux rev 1.0 ext4 filesystem data, UUID=346712e7-1a56-442b-a5bb-90ba4c6cc663 (extents) (64bit) (large files) (huge files)

$ file img.vfat
img.vfat:  DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 16, reserved sectors 16, root entries 512, Media descriptor 0xf8, sectors/FAT 256, sectors/track 32, heads 64, sectors 1024000 (volumes > 32 MB) , serial number 0x4b5e9a12, unlabeled, FAT (16 bit)

Gostaria de verificar se o disco de imagem fornecido está formatado com o formato fornecido.

Por exemplo checkfs <image> <format>, retorna 0 se a imagem contiver um sistema de arquivos 'formato', caso contrário, outro valor.

Pensei em fazer algo como file <image> | grep <format>verificar o código de retorno, no entanto, para sistemas de arquivos vfat, 'vfat' não está aparecendo na filesaída do 's.

Eu também poderia escrever um script para fazer isso, mas não consigo encontrar ferramentas que me permitam obter o formato do sistema de arquivos de uma imagem de disco.

Eu também tentei com as seguintes ferramentas: fdisk, partede df.

Existe uma ferramenta que me permita verificar um formato de sistema de arquivo de imagem de disco e que funcione com os formatos de sistema de arquivo mais usados?

Atualmente, estou começando a programação do kernel implementando um driver de dispositivo de bloco. Consegui fazer uma implementação "simples" e gostaria de aprofundar o que o subsistema de blocos oferece.

Para fazer isso, gostaria de emular meu próprio sistema operacional usando o qemu para evitar travar meu sistema operacional de desenvolvimento sempre que cometer um erro no código do dispositivo do kernel.

Configuração do sistema host

Na minha estação de trabalho estou usando o Debian 9 rodando com o kernel 4.9.0.

$ uname -a
Linux PC325 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux

Criação de disco de imagem

Para criar a máquina virtual, criei uma imagem bruta de 500M comdd if=/dev/zero of=vm-image.raw bs=1M count=512

E, em seguida, formate-o para ext4 usandomkfs.ext4 vm-image.raw

ATUALIZAÇÃO após o comentário @meuh: Preenchi
a imagem do disco da seguinte maneira:

mount vm-image.raw /mnt
mkdir /mnt/dev /mnt/lib /mnt/proc /mnt/root /mnt/run /mnt/sbin /mnt/sys
cp -r /etc /mnt/
cp -r /lib/systemd /mnt/lib
ln -s /lib/systemd/systemd /mnt/sbin/init

Agora estou tentando inicializar o sistema operacional emulado, mas estou tendo problemas para configurá-lo.

Comando de execução

$ qemu-system-x86_64 -k fr -kernel /boot/vmlinuz-$(uname -r) -initrd /boot/initrd.img-$(uname -r) -hda vm/vm-image.raw -append "initrd=/boot/initrd.img-$(uname -r) root=/dev/sda rw console=ttyS0" -nographic

Rastreamento de inicialização

[...] Kernel boot sequence [...]

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... [    2.015241] tsc: Refined TSC clocksource calibration: 3392.292 MHz
[    2.016768] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x30e5dd94d34, max_idle_ns: 440795304975 ns
[    2.895630] random: fast init done
Begin: Waiting for suspend/resume device ... Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
[   11.111765] random: crng init done
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for suspend/resume device
done.
Begin: Will now check root file system ... fsck from util-linux 2.29.2
[/sbin/fsck.ext4 (1) -- /dev/sda] fsck.ext4 -a -C0 /dev/sda 
/dev/sda: clean, 3607/32768 files, 12617/131072 blocks
done.
[   35.528453] EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null)
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.
run-init: /sbin/init: No such file or directory
[   35.569247] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[   35.569247] 
[   35.570469] CPU: 0 PID: 1 Comm: run-init Not tainted 4.9.0-6-amd64 #1 Debian 4.9.82-1+deb9u3
[   35.571599] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[   35.572695]  0000000000000000 ffffffff9792e074 ffff974c05e14d00 ffffa66e8003feb8
[   35.573741]  ffffffff9777cfbd ffff974c00000010 ffffa66e8003fec8 ffffa66e8003fe60
[   35.574780]  a4112d94e56af84a ffff974c05e14d80 0000000000000100 ffff974c05e84490
[   35.575793] Call Trace:
[   35.576132]  [<ffffffff9792e074>] ? dump_stack+0x5c/0x78
[   35.576815]  [<ffffffff9777cfbd>] ? panic+0xe4/0x23f
[   35.577453]  [<ffffffff9767c2de>] ? do_exit+0xade/0xae0
[   35.578136]  [<ffffffff978058b4>] ? vfs_write+0x144/0x190
[   35.578830]  [<ffffffff9767c313>] ? SyS_exit+0x13/0x20
[   35.579510]  [<ffffffff97603b7f>] ? do_syscall_64+0x8f/0xf0
[   35.580223]  [<ffffffff97c113b8>] ? entry_SYSCALL_64_after_swapgs+0x42/0xb0
[   35.581209] Kernel Offset: 0x16600000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[   35.582584] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[   35.582584] 

Problemas

1 - Tentando ler disquete

Na inicialização, parece que o kernel tenta ler de um dispositivo de disquete que não existe ou não pode ser lido. O kernel desistiu após 30 tentativas, portanto não é um problema crítico, mas está diminuindo a sequência de inicialização em 30 segundos.

Eu tentei executar qemu com -no-fd-bootchkopção, mas não mudou nada

ATUALIZAÇÃO:
Precisando-fda floppy.imgdefloppy.img1ko suprime as mensagens de erro relacionadas ao disquete e economiza até 20 segundos na inicialização. No entanto, como você pode ver no rastreamento de inicialização,/scripts/local-blockainda está sendo executado várias vezes e leva até 10 segundos antes de passar para a próxima etapa.

2 - Não foi possível inicializar o sistema

ATUALIZAÇÃO após o comentário @meuh:

Parece que o kernel não consegue encontrar um script init valib. No entanto /sbin/init, está presente na imagem do disco e é um link simbólico para /lib/systemd/systemd.

Estou experimentando um kernel panic, mas não sei o que está causando isso.

Pergunta

Sou muito novo no qemu e acho que não estou tão longe de ter meu sistema emulado funcionando, mas não posso ir além.

Tentei brincar com os parâmetros, mas não consigo encontrar uma solução para inicializar totalmente e ter um prompt bash em vez de initramdisk.

ATUALIZADO após o comentário do @meuh:
O que devo copiar para a imagem do disco para poder inicializar o sistema ?

No momento, estou tentando implementar uma conexão PAN via bluetooth entre duas placas.

A primeira placa é uma Raspberry Pi Zero e a segunda uma personalizada baseada em Atmel Sama5d2.
As placas estão rodando respectivamente Linux 4.9.75+ e Linux 4.9.30 e usando BlueZ v5.43 e BlueZ v5.46.

Consigo me conectar à conexão bluetooth conectada do meu telefone com ambas as placas usando o script bt-pan .

Aqui está o rastreamento de uma conexão com a conexão com fio do meu telefone

# bt-pan --debug client 60:45:CB:2F:C6:4C --wait
DEBUG:root:Using local device (addr: B8:27:EB:20:54:45): /org/bluez/hci0
DEBUG:root:Using remote device (addr: 60:45:CB:2F:C6:4C): /org/bluez/hci0/dev_60_45_CB_2F_C6_4C
DEBUG:root:Connected to network (dev_remote: /org/bluez/hci0/dev_60_45_CB_2F_C6_4C, addr: 60:45:CB:2F:C6:4C) uuid 'nap' with iface: bnep0

Aqui está o que fiz até agora (usando rpi como cliente e placa personalizada como servidor):

As placas são emparelhadas

Lado do servidor

[bluetooth]# paired-devices
Device B8:27:EB:20:54:45 raspberrypi[/code]

Lado do cliente

[bluetooth]# paired-devices
Device 00:16:A4:0A:15:13 BlueZ 5.46

Interface de ponte de configuração no lado do servidor

#brctl addbr bnep0
#brctl setfd bnep0 0
#brctl stp bnep0 off
#ip addr add 10.5.0.5/255.255.0.0 dev bnep0
#ip link set bnep0 up

Inicie o script bt-pan como servidor no lado do servidor

#bt-pan --debug server bnep0
DEBUG:root:Using local device (addr: 00:16:A4:0A:15:13): /org/bluez/hci0
DEBUG:root:Registered uuid 'nap' with bridge/dev: bnep0 / 00:16:A4:0A:15:13

Inicie o script bt-pan como cliente no lado do cliente

# bt-pan --debug client 00:16:A4:0A:15:13 --wait
DEBUG:root:Using local device (addr: B8:27:EB:20:54:45): /org/bluez/hci0
DEBUG:root:Using remote device (addr: 00:16:A4:0A:15:13): /org/bluez/hci0/dev_00_16_A4_0A_15_13
Traceback (most recent call last):
  File "/usr/bin/bt-pan", line 238, in <module>
    if __name__ == '__main__': sys.exit(main())
  File "/usr/bin/bt-pan", line 210, in main
    try: iface = net.Connect(opts.uuid)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 145, in __call__
    **keywords)
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "Connect" with signature "s" on interface "org.bluez.Network1" doesn't exist

Pelo que entendi, parece que meu dispositivo bluetooth não exporta o método Connectpara interfaceorg.bluez.Network1

Alguém sabe por que o perfil de rede não é suportado?
Existe uma solução alternativa para resolver esse erro?

Quando salvo uma saída de comando que contém várias linhas em uma variável diretamente no meu terminal, tenho os seguintes resultados:

$ dirs=$(ls -1d /mnt/*/)
$ echo $dirs
/mnt/ext4/ /mnt/local/ /mnt/remote/ /mnt/test/
$ echo "$dirs"
/mnt/ext4/
/mnt/local/
/mnt/remote/
/mnt/test/

No entanto, ao usá-lo a partir de um script de shell posix, o resultado é diferente. aqui está o roteiro

#!/bin/sh

dirs=$(ls -1d $1)
echo "inline"
echo $dirs
echo "multiline"
echo "$dirs"

E aqui está a saída do script

$ ./test.sh /mnt/*/
inline
/mnt/ext4/
multiline
/mnt/ext4/

Isso acontece mesmo se eu usar bash em vez de sh.

Alguém sabe como eu poderia salvar a saída ls -1d /mnt/*/em uma variável mantendo a saída completa?
Gostaria de analisar cada um dos quatro caminhos de diretório dentro de um loop for.

Estou escrevendo um serviço systemd que pode ser iniciado ou interrompido usando comandos systemctl.

No entanto, este programa também pode retornar com vários códigos de retorno e eu gostaria de lidar com esses códigos de retorno.

Por exemplo, se o serviço foi interrompido systemctl stop <service>, não deve fazer nada. Mas se não foi morto por systemctl e retornado por si só, quero executar um pós-script no qual eu possa obter o código de retorno e executar ações dependendo de seu valor.

Modificado após a resposta @NarūnasK
Ao ter a versão systemd >= v232, tudo bem com a resposta @NarūnasK

No entanto, ao não ter a boa versão do systemd, como isso poderia ser feito?

Eu pensei em fazer algo como

ExecStart=/bin/sh -c '<service> -C /etc/<service_conf_file>; [ $? -eq 1 ] && { <action> }'

Como posso inicializar o Linux rootfs a partir do u-boot passando a partição rootfs por rótulo?

Estou usando o u-boot como bootloader e a placa é uma RedPitaya. O linux é um Linux customizado baseado na imagem estável do ubuntu disponível para a placa.

O U-boot é exibido na primeira partição do cartão SD com o kernel Linux e a árvore de dispositivos. Estou tentando inicializar o sistema de arquivos raiz em um disco rígido USB externo

Eu preciso que posso inicializar o HDD se eu usar a convenção de nomenclatura "clássica" /dev/sdxn.

Eu já tentei com os seguintes parâmetros, mas ambos falharam:

console=ttyPS0,115200 root=/dev/disk/by-label/ROOTFS rw rootfstype=ext4 earlyprintk rootwait isolcpus=1

console=ttyPS0,115200 root=LABEL=ROOTFS rw rootfstype=ext4 earlyprintk rootwait isolcpus=1

Pelo que entendi fazendo pesquisas, /dev/disk/by-label é preenchido pelo udev, portanto não está disponível no u-boot ao passar os argumentos de inicialização para o kernel do Linux.

Também descobri que a funcionalidade para inicializar a partir do rótulo não está integrada ao kernel do linux, como você pode ver neste arquivo do_mounts.c logo antes da dev_t name_to_dev_t(const char *name)definição da função.

Portanto, a partir de agora, gostaria de encontrar uma maneira de inicializar a partição rotulada como ROOTFSno disco rígido USB externo.

Eu vejo duas soluções diferentes lá:

1 - Integre a funcionalidade de inicialização por rótulo no kernel do Linux adicionando algo como

if (strncmp(name, "LABEL=", 6) == 0) {
        name += 6;
        res = devt_from_label(name);
        if (!res)
            goto fail;
        goto done;
}

e implemente a do_mounts.cfunção devt_from_label.

2 - Use um pequeno rootfs na segunda partição do cartão SD para resolver o nome do dispositivo de seu rótulo e reinicie a inicialização do kernel com o nome do dispositivo substituído.

O que você acha disso ? Qual seria o "mais simples" de implementar?

Talvez eu esteja esquecendo algo importante ou alguém já tenha conseguido fazer a mesma coisa.

De qualquer forma, eu ficaria feliz em ter alguma ajuda para alcançá-lo