Rogach's questions

Um colega meu montou um volume incorreto no diretório e, em seguida, montou o volume correto no mesmo diretório. Existe uma maneira de desmontar esse volume "incorreto" sem tocar no volume "correto"?

Aqui está um exemplo reproduzível dessa situação:

$ dd if=/dev/zero of=file-a bs=1M count=1
$ mkfs.ext4 file-a
$ dd if=/dev/zero of=file-b bs=1M count=1
$ mkfs.ext4 file-b
$ mkdir target
$ sudo mount -o loop file-a target
$ sudo mount -o loop file-b target

Aqui está a situação após esses comandos:

$ findmnt
TARGET                                SOURCE         FSTYPE         OPTIONS
/                                     /dev/xxx       ext4           
└─/home/user/test-umount/target       /dev/loop1     ext4           rw,relatime
  └─/home/user/test-umount/target     /dev/loop2     ext4           rw,relatime

Então, queremos desmontar o /dev/loop1dispositivo aqui, mas mantenha o /dev/loop2montado no target.

Fazer umount targetirá desmontar o segundo volume, o que não é o efeito pretendido. Tentar desmontar o próprio dispositivo de loop fornece:

$ sudo umount /dev/loop1
$ umount: /dev/loop1: umount failed: Invalid argument.

Existe alguma maneira de resolver este enigma?

Por exemplo, o seguinte comando funciona:

$ cat some-file | md5sum
8981da1a6a4838c915e333820640d213  -
$ cat some-file | ssh user@host "md5sum"
user@host's password:
8981da1a6a4838c915e333820640d213  -

Por que o ssh consegue obter a senha do usuário? Presumi que ele leu a senha do stdin, mas claramente não é o caso.

Estou usando o Ubuntu 16.04 e estou vendo um comportamento estranho ao analisar logs journalctl.

Aqui está a saída não filtrada (usei a saída json para incluir todos os campos relevantes):

$ journalctl -o json-pretty --since "2018-01-11 12:00:00" --until "2018-01-11 12:00:05"
{
"__CURSOR" : "s=bac060082d1c447a972958f176cdcec7;i=1d2a2e;b=a948062f9f0b4091ae299c0523a99111;m=337bc483bf3;t=5627c5f8a3bae;x=7fd2518d6b70b9d",
"__REALTIME_TIMESTAMP" : "1515661201914798",
"__MONOTONIC_TIMESTAMP" : "3537916935155",
"_BOOT_ID" : "a948062f9f0b4091ae299c0523a99111",
"_TRANSPORT" : "stdout",
"PRIORITY" : "6",
"SYSLOG_FACILITY" : "3",
"SYSLOG_IDENTIFIER" : "start.sh",
"_PID" : "6474",
"_UID" : "1000",
"_GID" : "1000",
"_COMM" : "start.sh",
"_EXE" : "/bin/bash",
"_CMDLINE" : "/bin/bash /usr/local/malibu/start.sh",
"_CAP_EFFECTIVE" : "0",
"_SYSTEMD_CGROUP" : "/system.slice/malibu.service",
"_SYSTEMD_UNIT" : "malibu.service",
"_SYSTEMD_SLICE" : "system.slice",
"_MACHINE_ID" : "f03ff2ad269ea529c82323dd57f29b00",
"_HOSTNAME" : "terminal",
"MESSAGE" : "2018-01-11 12:00:01.914 DEBUG: malibu.devices.validator.ValidatorPortService$ - health check succeeded"
}

Como você pode ver, a saída contém uma única mensagem de log.

Mas se eu adicionar filtro pelo nome da unidade ( -u malibu.service), essa mensagem desaparece:

$ journalctl -u malibu.service -o json-pretty --since "2018-01-11 12:00:00" --until "2018-01-11 12:00:05"

O nome da unidade é exatamente igual ao _SYSTEMD_UNITcampo na saída não filtrada. Por que o journalctl não o exibe na versão filtrada?

EDIT: Acontece que eu estava usando a versão antiga do systemd - 229, enquanto a mais recente é 236, e usar o journalctl mais recente corrige esse problema. Infelizmente, 229 é a versão systemd mais recente disponível para 16.04 LTS, então não vejo uma solução sensata para o problema (além de construir o systemd mais recente no espaço do usuário e usar o binário journalctl recém-criado diretamente).