parando um serviço systemd ao iniciar outro

3

Eu escrevi um arquivo zram.service simples que irá configurar o espaço de swap compactado para eu evitar mastigar demais meus discos. O zram tem prioridade mais alta que os outros dispositivos de troca.

O problema é que quando eu tento hibernar meu sistema, ele escreve o estado do sistema para trocar, que neste caso é zram, e como o conteúdo da memória é perdido quando a energia desaparece, é claro que não funciona.

A solução é parar meu zram.service antes de executar o hibernate systemctl e iniciá-lo novamente quando o sistema estiver em backup.

Até onde eu descobri, o systemctl hibernate inicia o /lib/systemd/system/systemd-hibernate.service. Eu copiei este serviço para / etc / systemd / system / para substituí-lo, e provavelmente posso fazer isso funcionar usando a sub-rotina 'ExecStartPost =', mas acho que deve haver uma maneira melhor de interromper um serviço systemd quando outro é começou e vice-versa.

Edit: o serviço zram em funcionamento em um sistema Debian para os interessados

[Unit]
Description=ZRAM swap
Conflicts=hibernate.service

[Service]
Environment=ZRAM_MEM=1G
Environment=ZRAM_CMPALGO=lz4
Environment=ZRAM_CMPSTREAMS=2


Type=oneshot
User=root
ExecStartPre=/bin/sh -c "/sbin/modprobe zram num_devices=1"
ExecStartPre=/bin/sh -c "echo $ZRAM_CMPALGO >/sys/block/zram0/comp_algorithm"
ExecStartPre=/bin/sh -c "echo $ZRAM_CMPSTREAMS >/sys/block/zram0/max_comp_streams"
ExecStartPre=/bin/sh -c "echo $ZRAM_MEM > /sys/block/zram0/disksize"
ExecStartPre=/bin/sh -c "/sbin/mkswap /dev/zram0"
ExecStart=/sbin/swapon /dev/zram0 -p 10

ExecStop=/sbin/swapoff /dev/zram0
ExecStop=/bin/echo 1 > /sys/block/zram0/reset
ExecStop=/sbin/rmmod zram

RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
    
por Waxhead 05.03.2016 / 12:35

1 resposta

3

Defina Conflicts= no arquivo de unidade do systemd.

Na página do sistema systemd.unit:

Conflicts=

A space-separated list of unit names. Configures negative requirement dependencies. If a unit has a Conflicts= setting on another unit, starting the former will stop the latter and vice versa. Note that this setting is independent of and orthogonal to the After= and Before= ordering dependencies.

If a unit A that conflicts with a unit B is scheduled to be started at the same time as B, the transaction will either fail (in case both are required part of the transaction) or be modified to be fixed (in case one or both jobs are not a required part of the transaction). In the latter case, the job that is not the required will be removed, or in case both are not required, the unit that conflicts will be started and the unit that is conflicted is stopped.

    
por 29.03.2016 / 10:27