Artem S. Tashkinov's questions

De repente, percebi que o wpa_supplicant está enviando spam para meus logs do sistema com estas mensagens:

Sep 02 08:07:17 elite wpa_supplicant[3054]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-64 noise=9999 txrate=648500
Sep 02 08:07:20 elite wpa_supplicant[3054]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-58 noise=9999 txrate=648500
Sep 02 08:07:23 elite wpa_supplicant[3054]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-58 noise=9999 txrate=648500
Sep 02 08:07:26 elite wpa_supplicant[3054]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-64 noise=9999 txrate=648500
Sep 02 08:07:29 elite wpa_supplicant[3054]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-64 noise=9999 txrate=432300
Sep 02 08:07:32 elite wpa_supplicant[3054]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-63 noise=9999 txrate=432300
Sep 02 08:07:35 elite wpa_supplicant[3054]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-63 noise=9999 txrate=576400
Sep 02 08:07:38 elite wpa_supplicant[3054]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-64 noise=9999 txrate=576400
Sep 02 08:07:41 elite wpa_supplicant[3054]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-64 noise=9999 txrate=576400
Sep 02 08:07:44 elite wpa_supplicant[3054]: wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-63 noise=9999 txrate=576400

Quero que isso pare. Meu WiFi funciona perfeitamente, mas essas mensagens aparentemente de depuração me deixam louco e geram mais de 2 GB de gravações em disco diariamente.

Nos últimos três dias:

journalctl | grep CTRL-EVENT-SIGNAL-CHANGE | wc -l
24500

Estou usando o Fedora 40 totalmente atualizado com o NetworkManager.

Este comando:

sudo chown -R root:root directory

removerá o bit SUID e redefinirá todos os recursos dos arquivos . Eu me pergunto por que isso é feito silenciosamente e não é mencionado na página de manual. Estranhamente, o bit GUID não foi removido. E não importa a quem pertencia o arquivo ou diretório antes de executar este comando.

Além disso, os bits SUID/GUID não são removidos dos diretórios (embora sejam inúteis neste caso).

Presumivelmente, isso é feito em nome da segurança, mas para mim não deve ser feito silenciosamente.

Isso fica ainda pior:

$ setcap cap_sys_rawio,cap_sys_nice=+ep test
$ getcap -v test 
test cap_sys_rawio,cap_sys_nice=ep

$ chown -c -v -R 0:0 .
ownership of './test' retained as root:root
ownership of '.' retained as root:root

$  getcap -v test 
test

O bit SUID do testarquivo é removido de forma totalmente silenciosa. É como se o comando estivesse fazendo muito mais do que o solicitado.

Infelizmente, o problema relatado e descrito aqui: Problema pernicioso de travamento do stick USB. Revertendo a solução alternativa? e A "aceleração de write-back" é uma solução para o "problema de travamento do stick USB"? continua sem solução nas distribuições Linux modernas em 2024, apesar da disponibilidade da interface BDI introduzida no Linux 6.2 lançado em fevereiro de 2023.

Isso pode ser resolvido por uma udevregra simples que invoca um script que define valores razoáveis ​​de cache de write-back para dispositivos de armazenamento em massa USB.

Preciso executar um aplicativo C++ proprietário no Linux e preciso entender se ele contém alguma função fora dos recursos anunciados.

Existe uma maneira de listar todas as chamadas de API que o aplicativo faz, desde que não use syscalls do Linux e use apenas funções padrão stdc++?

Uma pergunta semelhante foi feita há quase uma década e a resposta não é nada satisfatória para mim. Preciso de algo totalmente automatizado.

Existe uma maneira fácil de obter os URLs dos pacotes baixados no DNF?

O que estou tentando alcançar: atualmente estou em um plano de Internet muito caro, então preciso obter links, baixar pacotes em uma conexão diferente e alimentá-los no DNF.

Isso funciona lindamente no BASH:

$ where=/sys/class/backlight/*
$ echo $where
/sys/class/backlight/intel_backlight

No entanto, quando colocado no script POSIX como /bin/shinterpretador, isso não funciona, wheretorna-se /sys/class/backlight/*.

Eu tentei Google, mas provavelmente não estou usando os termos certos.

Aqui está uma questão simples.

Eu quero uma visão geral, por exemplo, arquivos separados com informações de depuração para cada processo que despejou o núcleo extraído de arquivos journalctl.

Aqui está um exemplo de saída:

Jan 17 12:49:45 localhost systemd-coredump[137987]: [?] Process 3045 (xfce4-panel) of user 1000 dumped core.
                                              
                                              Module linux-vdso.so.1 with build-id edcc6cf50d839ad9201a67e8d2de3d1bec5c03fd
                                              Module librsvg-2.so.2 with build-id a172ce96c3c2d136fc30361d4c28b4ab736833e6
                                              Metadata for module librsvg-2.so.2 owned by FDO found: {
                                                      "type" : "rpm",
                                                      "name" : "librsvg2",
                                                      "version" : "2.54.5-1.fc37",
                                                      "architecture" : "x86_64",
                                                      "osCpe" : "cpe:/o:fedoraproject:fedora:37"
                                              }
                                              
                                              Module libpixbufloader-svg.so with build-id 77cf182593e5e19b8bde9397d50f0f4d5acffe51
                                              Metadata for module libpixbufloader-svg.so owned by FDO found: {
                                                      "type" : "rpm",
                                                      "name" : "librsvg2",
                                                      "version" : "2.54.5-1.fc37",
                                                      "architecture" : "x86_64",
                                                      "osCpe" : "cpe:/o:fedoraproject:fedora:37"
                                              }
... lots more similar messages ...
Jan 17 12:49:45 localhost systemd[1]: systemd-coredump@12-137985-0.service: Deactivated successfully.

Na internet só encontrei isso:

/etc/kernel/postinst.d/51-dracut-rescue-postinst.sh $(uname -r) /boot/vmlinuz-$(uname -r)

mas não funciona no Fedora 36 e em breve será lançada a versão 37, porque este arquivo está faltando, na verdade todo o /etc/kernel/postinst.d/diretório está vazio.

eu também encontrei

dnf reinstall kernel-core

mas só funciona para um kernel atualizado. Estou executando o kernel que não está mais disponível nos repositórios. Além disso, essa não é uma boa opção em si, pois resultará na reinstalação literalmente de muitas centenas de arquivos sem motivo.

grep -r rescue /etcnão encontra nada.

# grep -r rescue /usr/bin
grep: /usr/bin/tdbdump: binary file matches
grep: /usr/bin/ctags: binary file matches
grep: /usr/bin/systemctl: binary file matches
grep: /usr/bin/systemd-analyze: binary file matches
grep: /usr/bin/efisecdb: binary file matches
grep: /usr/bin/dpkg: binary file matches
grep: /usr/bin/grub2-mkrescue: binary file matches

/usr/sharecontém uma tonelada de correspondências, mas não tenho ideia de como trabalhar com isso.

kernel-coree kernel-modulespacotes têm scripts RPM que fazem alguma coisa, mas não há nada específico para "resgatar". Parece que tudo é feito como uma única operação, mas não quero gerar novamente o initrd.

Sim, eu sei que há actkbd que permite atribuir atalhos de teclado globais que funcionarão em todos os lugares, incluindo o console de texto e uma sessão gráfica, mas não quero executar um daemon extra (também sem manutenção) para um único atalho de teclado. Eu quero algo muito mais simples, sem opções de configuração e que tenha a quantidade mínima absoluta de código.

A tarefa é executar um comando quando esta combinação de teclas é pressionada:

Win+ End->systemctl suspend

Provavelmente vale a pena postar no stackoverflow.com, mas não tenho certeza.

journalctl -b | grep Supervising | wc -l
2819

Distro é Fedora 35, vanilla, com PipeWire comandando o show.

Tenho certeza de que todas as distribuições Linux modernas são afetadas, mas as pessoas não se importam.

Não há rsyslogaqui e journald não suporta filtragem.

Isso está ficando ridículo. Eu posso corrigi-lo com certeza, mas a questão é como isso pode ser feito sem aplicar patches e reconstruir. A coisa, /usr/libexec/rtkit-daemon, nem sequer tem uma página de manual e nada nela --helpoferece pistas.

Há uma pergunta relacionada que nunca foi respondida também: rtkit: list threads que está "supervisionando"?

Só consigo pensar em executar rtkit-daemonalgum wrapper que simplesmente desativa todos os recursos relacionados ao /dev/log/system logging. Alguém já viu algo assim?

Eu arquivei um relatório de bug apenas no caso.

Depois de atualizar do PulseAudio para o PipeWire, meus dispositivos de som agora apresentam o perfil "Pro Audio", mas pesquisei no Google e não encontrei nada interessante. Você pode encontrá-lo executando PulseAudio Volume Controle visualizando-o na guia Configuração de seus dispositivos.

Seria bom se alguém pudesse, eu não sei, dar uma olhada nas fontes do PipeWire (não sou um programador C em si e não entendo muito de áudio digital além do básico) e explicar o que é e por que o o usuário pode querer usá-lo em vez de, por exemplo, algo que é oferecido por padrão.

Tenho certeza de que o kernel do Linux tem um recurso que permite rastrear todas as leituras e gravações (IO) de um aplicativo e todos os seus filhos, mas não vi nenhum utilitário que possa calculá-lo e mostrá-lo.

Por exemplo, para o tempo de CPU, você pode simplesmente usar timee obter informações de uso da CPU:

$ time cat --version > /dev/null

real    0m0.001s
user    0m0.001s
sys 0m0.000s

Estou procurando algo semelhante em relação ao IO, por exemplo

$ calc_io task
Bytes read: 123456
Bytes written: 0

Claro, temos /proc/$PID/ioque contém informações de tempo de execução, mas rastreá-lo para aplicativos que geram e destroem filhos dinamicamente, por exemplo, navegadores da web parece uma tarefa assustadora. Eu acho que se você executar strace -fF firefox, monitore todas as crianças que estão sendo geradas e tente rastrear em tempo real /proc/$PID/io- nah, parece muito difícil de implementar e, em seguida, com que frequência você pesquisará esse arquivo para obter informações? As crianças podem existir por uma fração de segundo.

Outra idéia é usar cgroups, mas e se eu não quiser usá-los? Também verifiquei /sys/fs/cgroupe não vejo nenhuma estatística relevante.

Eu gostaria de ver as TCPsolicitações (pacotes syn) iniciadas pelo meu PC/servidor para outros hosts. Mais especificamente, gostaria de ver o arquivo outgoing connection requests. Como posso fazer isso?

Além disso, não quero ver nenhuma tentativa de conexão que esteja chegando ao meu PC/servidor.

O iptablescomando a seguir funciona, mas é desajeitado de usar, pois registra tudo enquanto eu só quero ver tudo na tela:

iptables -I OUTPUT 1 -o eth0 -p tcp -m state --state NEW -j LOG