Início / user-133286

Golar Ramblar's questions

Martin Hope
Golar Ramblar
Asked: 2022-02-06 07:40:50 +0800 CST
  • 0

Eu tenho um dispositivo USB que o kernel não reconhece automaticamente como um dispositivo serial USB, mas quando eu digo manualmente ao usbserialdriver que ele deve se vincular a ele ( modprobe usbserial vendor=0x0421 product=0x069a), ele fornece interfaces seriais USB onde coisas úteis podem ser feitas sobre ele.

Qual é o lugar certo (endereço de e-mail, rastreador de bugs, …) para reportá-lo aos mantenedores corretos do subsistema Linux para incluir esse dispositivo para vinculação automática?

linux-kernel usb-device
Martin Hope
Golar Ramblar
Asked: 2019-05-05 14:28:39 +0800 CST
  • 1

Eu tenho um programa que de repente começou a não terminar (eu não estava atualizando o programa, mas meu sistema e o kernel, não me lembro o que estava causando o efeito. Recompilar o programa não mudou o comportamento de não terminar). Sob strace, no entanto, ele termina.

Como essas coisas podem ser rastreadas?

Exemplo concreto:

Aqui está o exemplo concreto em que encontrei essa coisa estranha )(para mim):

Trata-se de WWWOFFLE , SVN revisão 2250 (mais recente no momento da investigação/escrita), compilado em Arch/Artix Linux de acordo com o pacote AUR .

Desde algum tempo (sem atualização de WWWOFFLE, mas atualizações de sistema e kernel, e após o aparecimento deste problema recompilação de WWWOFFLE sem uma mudança perceptível) colocar wwwoffle no modo online ou offline trava com bastante frequência indefinidamente. Se eu quiser rastreá-lo com strace, ele não trava. Se eu envolvê-lo em um script de shell, ele trava com strace, mas não com strace -f/ strace -ff.

Detalhes:

  1. iniciar wwwoffledservidor:

    wwwoffled -c /etc/wwwoffle/wwwoffle.conf -f -d 6

  2. coloque WWWOFFLE no modo online (mudar do modo offline para o online geralmente é bem-sucedido):

    wwwoffle -c /etc/wwwoffle/wwwoffle.conf -online

    Saída do terminal:

    WWWOFFLE Now Online

    e retorne ao shell de chamada.

  3. coloque WWWOFFLE no modo offline:

    wwwoffle -c /etc/wwwoffle/wwwoffle.conf -offline

    Saída do terminal:

    WWWOFFLE Now Offline

    e sem rescisão.

    O log de wwwoffledacordo com o número 1 diz corretamente Important: WWWOFFLE Offline. Abortar wwwoffle -c /etc/wwwoffle/wwwoffle.conf -offlinecom <STRG>+<c>e tentar novamente agora é impresso corretamente WWWOFFLE Already Offline, mas também não termina.

  4. mudar para o modo online enquanto WWWOFFLE já está online também não termina:

    wwwoffle -c /etc/wwwoffle/wwwoffle.conf -online

    enquanto o WWWOFFLE já estiver online imprime corretamente

    WWWOFFLE Already Online

    mas não termina.

  5. strace:

    strace wwwoffle -c /etc/wwwoffle/wwwoffle.conf -offline

    e

    strace wwwoffle -c /etc/wwwoffle/wwwoffle.conf -online

    parece sempre terminar quando wwwoffledé iniciado como em 1.

  6. Se eu colocar wwwoffle -c /etc/wwwoffle/wwwoffle.conf -offlinee wwwoffle -c /etc/wwwoffle/wwwoffle.conf -onlineem um script bash:

    #!/bin/bash

wwwoffle -c /etc/wwwoffle/wwwoffle.conf -offline

    e executá-lo, então também com strace ele não termina:

    strace ./wwwoffle-off.sh

    imprime como as últimas linhas

    [...]
access("/usr/bin/wwwoffle", R_OK)       = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f36a75e1e50) = 6426
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x5573f5295be0, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f36a76898b0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f36a76898b0}, 8) = 0
wait4(-1, WWWOFFLE Already Offline

    e esperando lá para sempre. (Observe que WWWOFFLE Already Offlineé a saída de wwwofflee é gravada em stdout, a última saída de strace, gravada em stderr, é wait4(-1,)

  7. Com strace -fou strace -ff(que rastreia também threads filho bifurcados), ele termina novamente.

Eu vejo isso apenas com WWWOFFLE, mas pode não ser um problema WWWOFFLE. Não faço ideia de como rastrear. Como essas coisas podem ser rastreadas, o que pode causar tal comportamento?

strace hang
Martin Hope
Golar Ramblar
Asked: 2018-12-12 05:01:53 +0800 CST
  • 0

Descobri que o comando bsdtardo pacote libarchive(no Arch Linux, pelo menos) joga fora bits executáveis ​​de arquivos em .zip-archives ao ler de stdin, mas não ao trabalhar diretamente no arquivo.

Em .tar-archives, ele preserva o bit executável também ao ler de stdin.

Caso de teste:

Crie os arquivos:

Crie os arquivos:

touch a.txt
chmod 644 a.txt
touch a.out
chmod 755 a.out

As permissões do arquivo:

ls -ln a.out a.txt

mostra

-rwxr-xr-x 1 1001 1001 0 Dec 12 11:01 a.out
-rw-r--r-- 1 1001 1001 0 Dec 12 11:01 a.txt

Empacote os arquivos em arquivos:

bsdtar --format=zip -cf a.zip a.out a.txt
bsdtar -cf a.tar a.out a.txt

(Criar os arquivos com zipe tarem vez de bsdtarproduz o mesmo resultado.)

Extraindo/mostrando o conteúdo do arquivo diretamente:

bsdtar -tvf a.zip

ou

bsdtar -tvf - < a.zip

mostra

-rwxr-xr-x  0 1001   1001        0 Dec 12 11:01 a.out
-rw-r--r--  0 1001   1001        0 Dec 12 11:01 a.txt

O bit executável de a.outestá presente aqui. As permissões de a.outsão 755 e de a.txt644.

Leitura de stdin:

cat a.zip | bsdtar -tvf -

mostra

-rw-rw-r--  0 1001   1001        0 Dec 12 11:01 a.out
-rw-rw-r--  0 1001   1001        0 Dec 12 11:01 a.txt

O bit executável para a.outé jogado fora aqui. Além disso, ambos os arquivos são graváveis ​​em grupo, eles não foram compactados dessa maneira. As permissões de a.oute a.txtsão 664.

.tar-arquivo:

Como comparação, para um .tar-archive, as permissões no arquivo também são respeitadas ao ler de um pipe de stdin:

bsdtar --numeric-owner -tvf a.tar

e

cat a.tar | bsdtar --numeric-owner -tvf -

ambos mostram

-rwxr-xr-x  0 1001   1001        0 Dec 12 11:01 a.out
-rw-r--r--  0 1001   1001        0 Dec 12 11:01 a.txt

(observe que, ao mostrar o conteúdo de um arquivo ZIP, bsdtarmostra o proprietário numérico por padrão; para um arquivo TAR, mostra o nome do proprietário.)

A questão é:

O que é especial stdinem relação a bsdtar? E por que apenas ao ler de um cachimbo, e não na moda bsdtar -tvf - < a.zip? E por que especial para um .zip-archive, mas não para um .tar-archive?

zip executable