Mathias Sven's questions

A configuração é que agora tenho duas pastas sob meu diretório atual, busybox-1.36.1e procps-4.0.4, e também tenho um serviço languagetoolem execução com DynamicUser=yes. Agora observe o comportamento diferente:

Legenda: ✅ Não trunca; ❌ trunca.

relógio busybox e busybox ps ✅

./busybox-1.36.1/bin/watch './busybox-1.36.1/bin/ps aux | grep languagetool'

Every 2.0s: ./busybox-1.36.1/bin/ps aux | grep languagetool                                                                           2025-03-17 23:20:02

1026972 61534    39:36 java ...languagetool...
4053857 mathiass  0:00 ./busybox-1.36.1/bin/watch ./busybox-1.36.1/bin/ps aux | grep languagetool
4053882 mathiass  0:00 sh -c -- ./busybox-1.36.1/bin/ps aux | grep languagetool
4053884 mathiass  0:00 grep languagetool

busybox watch e procps ps ✅

./busybox-1.36.1/bin/watch './procps-4.0.4/bin/ps aux | grep languagetool'

Every 2.0s: ./procps-4.0.4/bin/ps aux | grep languagetool

languag+ 1026972  0.1 13.6 14468788 4464816 ?    Ssl  Mar04  39:38 java ...languagetool...
mathias+ 4057218  0.0  0.0   4676  2244 pts/32   S+   23:35   0:00 ./busybox-1.36.1/bin/watch ./procps-4.0.4/bin/ps aux | grep languagetool
mathias+ 4057222  0.0  0.0 231736  3788 pts/32   S+   23:35   0:00 sh -c -- ./procps-4.0.4/bin/ps aux | grep languagetool
mathias+ 4057224  0.0  0.0 230732  2520 pts/32   S+   23:35   0:00 grep languagetool

procps watch e procps ps ❌

./procps-4.0.4/bin/watch './procps-4.0.4/bin/ps aux | grep languagetool'

Every 2.0s: ./procps-4.0.4/bin/ps aux | grep languagetool

mathias+ 4056463  0.0  0.0 230836  3320 pts/32   S+   23:31   0:00 ./procps-4.0.4/bin/watch ./procps-4.0.4/bin/ps aux | grep languagetool
mathias+ 4056540  0.0  0.0 230836  1532 pts/32   S+   23:32   0:00 ./procps-4.0.4/bin/watch ./procps-4.0.4/bin/ps aux | grep languagetool
mathias+ 4056541  0.0  0.0 231736  3556 pts/32   S+   23:32   0:00 sh -c -- ./procps-4.0.4/bin/ps aux | grep languagetool
mathias+ 4056543  0.0  0.0 230732  2244 pts/32   S+   23:32   0:00 grep languagetool

procps watch e busybox ps ✅

./procps-4.0.4/bin/watch './busybox-1.36.1/bin/ps aux | grep languagetool'

Every 2.0s: ./busybox-1.36.1/bin/ps aux | grep languagetool                                                                nixos: Mon Mar 17 23:33:31 2025

1026972 61534    39:38 java ...languagetool...
4056826 mathiass  0:00 ./procps-4.0.4/bin/watch ./busybox-1.36.1/bin/ps aux | grep languagetool
4056831 mathiass  0:00 ./procps-4.0.4/bin/watch ./busybox-1.36.1/bin/ps aux | grep languagetool
4056832 mathiass  0:00 sh -c -- ./busybox-1.36.1/bin/ps aux | grep languagetool
4056834 mathiass  0:00 grep languagetool

Pergunta

Parece estranho que em todos os outros casos os comandos se comportem como eu espero, exceto quando tento usar ambos pse watchfrom procps. Alguém sabe o que está acontecendo aqui?

O aplicativo em si não está em questão, só estou me perguntando como o Bash não está se comportando como eu esperava, como se, de alguma forma, qualquer comportamento que esse aplicativo tenha, estivesse vazando de uma forma que não consigo explicar o porquê.

Para contextualizar, o aplicativo é patsh , ele é destinado a coisas do Nix (como no gerenciador de pacotes), mas essencialmente ele pega um arquivo de entrada, e o reescreve com base em algumas regras e então o salva no arquivo de saída (que aqui é /dev/stdout), neste contexto, ele não reescreve nada, então é essencialmente cp. Aqui está a configuração:

$ cat <<EOF > foo
1
2
3
4
5
6
EOF

$ cat <<EOF > bar
a
b
c
EOF

$ { patsh -f bar /dev/stdout; } >> foo  # Using braces to avoid any ambiguity...

$ cat foo  # It replaced instead of appending
a
b
c
4
5
6

$ cat <(patsh -f bar /dev/stdout) >> foo  # Does what I expected

$ cat foo
a
b
c
4
5
6
a
b
c

Alguém pode explicar esse comportamento?

Vou ser breve, estou tentando entender melhor os diferentes padrões de interfaces de tipo de armazenamento, mas a saída de smartctlestá me confundindo um pouco. Isso é um problema real no meu sistema (como uma serra em outro post onde algum firmware estava desatualizado) ou estou entendendo mal a saída de smartctl.

Observar:

> sudo smartctl --scan
/dev/sda -d scsi # /dev/sda, SCSI device
/dev/nvme0 -d nvme # /dev/nvme0, NVMe device

Tenho um HDD e um NVMe, mas o HDD não é SCSI até onde eu sei, a menos que seja " Por que meus dispositivos SATA aparecem em /proc/scsi/scsi? ". Mas se for, por que posso usar ambos -d atae -d scsipara obter informações sobre isso:

> sudo smartctl -d ata --info /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.10.5] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Scorpio Black (AF)
Device Model:     WDC WD5000BPKT-75PK4T0
Serial Number:    WD-WX11EC114329
LU WWN Device Id: 5 0014ee 6ad29b3f3
Firmware Version: 01.01A01
User Capacity:    500,107,862,016 bytes [500 GB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Device is:        In smartctl database 7.3/5387
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Thu Aug 29 14:09:19 2024 WEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

> sudo smartctl -d scsi --info /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.10.5] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

User Capacity:        500,107,862,016 bytes [500 GB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
LU is fully provisioned
Rotation Rate:        7200 rpm
Logical Unit id:      0x50014ee6ad29b3f3
Serial number:        WD-WX11EC114329
Device type:          disk
Local Time is:        Thu Aug 29 14:09:35 2024 WEST
SMART support is:     Unavailable - device lacks SMART capability.

De acordo com a saída de ambos, ataé claramente o tipo "correto", mas sudo smartctl -d ata --scannão retorna nada (ao contrário de sudo smartctl -d scsi --scan).

Por que parece que posso usar ambos atae scsipara acessar informações, e por que isso é detectado como scsipor --scan?

Estou trabalhando em uma configuração systemd/udev que gostaria de compartilhar upstream, mas não consigo fazê-la funcionar de maneira não hackeada. Essencialmente, tenho este script como executivo de um serviço systemd:

      ICON="somepath/dslr-camera-white.png"

      function on-display() {
          local sdisplay=$(echo $XDG_SESSION_TYPE)
          if [ "$sdisplay" == "wayland" ]; then
          local display=":$(echo $WAYLAND_DISPLAY)"
          else
          local display=":$(ls /tmp/.X11-unix/* | sed 's#/tmp/.X11-unix/X##' | head -n 1)"
          fi
          
          local user=$(who | grep '('$display')' | awk '{print $1}' | head -n 1)

          local uid=$(id -u $user)

          sudo -u $user DISPLAY=$display DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$uid/bus "$@"
      }

      cleanup() {
          on-display notify-send -i $ICON "Disconnected" "The DSLR Camera has been turned off." --app-name="DSLR Webcam"
          trap - SIGTERM && kill -- -$$
      }

      trap cleanup SIGINT SIGTERM EXIT

      on-display notify-send -i $ICON "Connected" "The DSLR Camera has been turned on and it is ready to use." --app-name="DSLR Webcam"
      on-display yad --window-icon=$ICON --image=$ICON --no-buttons --title="DSLR Webcam" --notification --listen &

      output=$(v4l2-ctl --list-devices)
      line=$(echo "$output" | grep "Virtual Camera")
      vdevice=$(echo "$output" | sed -n "/$line/{n;s/^\t\+//p;}")
      gphoto2 --stdout --capture-movie | ffmpeg -i - -vcodec rawvideo -pix_fmt yuv420p -threads 0 -f v4l2 $vdevice

O objetivo do serviço é ser iniciado por uma regra do udev quando uma câmera específica suportada pelo gphoto2 estiver conectada, portanto, tenho estas regras do udev:

ACTION=="add", ATTR{idVendor}=="04a9", ATTR{idProduct}=="3218", RUN+="systemctl start dslr-webcam.service"
ACTION=="remove", ATTR{idVendor}=="04a9", ATTR{idProduct}=="3218", RUN+="systemctl stop dslr-webcam.service"

Até agora tudo bem, porque li sobre alternativas ao uso RUNde um serviço systemd, mas independentemente... O problema aqui é especificamente a chamada para yad.

yadé um programa que permite exibir caixas de diálogo da CLI, estou aproveitando-o por sua capacidade de criar um ícone do sistema, pois gostaria que aparecesse quando a câmera estiver ativa.

O problema

Ao contrário do notify-send, que provavelmente funciona em algum soquete comum, yadrequer o XAUTHORITYconjunto apropriado para funcionar, caso contrário você obterá o cannot open display: :0. A solução hacky no meu caso é simplesmente definir o Xauthority correto, já que estou usando SDDM (gerenciador de exibição), ele reside no /tmpdiretório, então posso adicionar isto ao script:

XAUTHORITY=$(ls /tmp/xauth*)

E então funciona... Mas isso é terrível, faz muitas suposições, na verdade toda a on-displayfunção também parece uma má ideia. Se eu levasse isso para um sistema diferente, provavelmente não funcionaria, porque o Xauthority adequado poderia estar em vários lugares, e eu nem experimentei o Wayland ainda (deixarei isso para mais tarde).

A respeitoxauth

Achei que poderia de alguma forma usar xauthpara recuperar o Xauthority correto, mas não parece ser o caso... Este script é um serviço do sistema, então meu xauth inforetorno Authority file: /root/.xauthWV7OfU, e executá-lo como o usuário certo sudo -u $user xauth infome dá Authority file: /home/myuser/.Xauthority, nenhum dos quais funciona quando dado a yad. O correto XAUTHORITYé definido pelo gerenciador de exibição, então acho que só consegui obtê-lo a partir de processos filhos dele.

Eu também tentei todas as abordagens fornecidas por esta resposta , mas a primeira não funcionaria, pois XAUTHORITYnão está realmente no ambiente do sistema, e a segunda (além das armadilhas mencionadas), não funciona, diz o O arquivo xauth está em /run/sddm/xauth_KvyuHd, mas tentar usá-lo não funciona, portanto não é o mesmo arquivo xauth que/tmp/xauth_FzoQqz

Pela mesma pergunta anterior, essa abordagem parece funcionar, mas não sei até que ponto ela é portátil. E ainda parece hacky.

Executar como serviço de usuário

Talvez este seja o mais promissor, já que nada nesse script impede que ele seja executado como um usuário (ele também se livra de on-display), eu tentei essa abordagem e, embora se a câmera estivesse conectada e eu executasse, systemctl --user start dslr-webcam.servicefuncionaria como esperado (inclusive yad), agora tenho um problema com a udevregra. Pesquisei em muitos lugares, inclusive aqui , mas não consigo descobrir como executar um serviço de usuário do systemd a partir de uma udevregra, e para mim isso também não faz sentido, como saberia udevqual usuário usar?

Eu tenho um script no qual preciso montar uma sobreposição para fornecer a um contêiner OCI acesso a um diretório somente leitura montado /nix/storecomo se fosse gravável.

Eu gostaria que esse script pudesse ser executado por usuários não-root/não-wheel. Qual seria a maneira mais fácil? Inicialmente, tentei ingenuamente usar SUIDantes de perceber que eles não funcionavam, o que me levou a um monte de respostas e artigos sobre os perigos dos SUIDscripts shell, incluindo um que explicava por que simplesmente envolvê-lo em algum programa C não resolveria o problema. questões de segurança relativas a ambientes não limpos.

Existe um wrapper/utilitário fácil em que eu possa agrupar o script e que cuide de tais vulnerabilidades?

Do ambiente do usuário, eu só preciso de um ENV que é passado apenas para o contêiner docker, porém, o usuário root teria a mesma variável ENV em sua sessão bash, portanto, se uma sugestão funcionar desconsiderando todo o ambiente do usuário e, em vez disso, usar o root one, isso seria bom para o meu caso de uso.

local temp_dir=$(mktemp -d)

mkdir -p {$temp_dir/store,$temp_dir/upper-store,$temp_dir/work-store}

# Create Overlay
sudo mount -t overlay overlay \
  -o lowerdir=/nix/store,upperdir=$temp_dir/upper-store,workdir=$temp_dir/work-store $temp_dir/store

# Do some sutff with the mounted overlay

sudo umount $temp_dir/store
rm -rf $temp_dir

Estou executando um servidor de código na minha máquina Ubuntu remota e agora meu método para iniciá-lo é

1. ssh -t -t user@server "code-server"em um terminal (o -t -tque eu tenho disso )
2. ssh -N -L 8443:127.0.0.1:8443 user@serverem um segundo terminal
3. Abra o aplicativo no navegador

Então, quando eu quiser fechá-lo, basta fechar os dois terminais. Minha dúvida é se seria possível fazer isso usando apenas uma conexão, atualmente tenho que autenticar duas vezes pois isso requer duas sessões ssh, uma para iniciar a aplicação e enviar o KILL quando fechada e outra para o tunelamento.