TheMeaningfulEngineer's questions

Um framebuffer é um arquivo de dispositivo que permite uma interface simplificada para a tela. Por exemplo, executando o código abaixo em um RaspberryPi com um monitor HDMI conectado:

cat /dev/urandom > /dev/fb1

Existem comandos ( fbi, fim) que permitem injetar imagens completas no framebuffer.

Existem vários recursos na internet ( ref1 , ref2 , ref3 ) tentando explicar com mais ou menos sucesso como adicionar um serviço systemd que resultará em uma imagem na tela.

Um fio comum nesses recursos é a menção ttyjunto com o framebuffer. (ou seja, ambos fbie fimtem opções para passá-los a tty).

Minha suposição era que a ttyé um conceito separado de a framebuffer. O ttyusa o framebufferpara enviar conteúdo para um usuário, mas o framebuffer não está de forma alguma vinculado a um arquivo tty.

Existe uma relação oculta por trás de a ttye a framebufferque poderia explicar por que os comandos para imprimir imagens em a framebufferparecem depender de a tty?

Ao executar um comando em ttyum terminal, ele retorna /dev/pts/10.

Além disso, existem os arquivos /dev/stdout /dev/stdine /dev/stderr. Interagir com eles diretamente mostra os resultados no terminal.

user@laptop:build$ tty
/dev/pts/10
user@laptop:build$ echo "Test" > /dev/stdout
Test
user@laptop:build$ echo "Test" > /dev/stdin
Test
user@laptop:build$ echo "Test" > /dev/stderr
Test

Além disso, qualquer aplicativo cli, iniciado a partir do shell, terá os descritores de arquivo abertos para stdout/ stderr/ stdin. ou seja, se você executar um script que imprime algo, imprimir é equivalente a escrever em stdout.

Até agora stdout// foram as únicas interfaces com as quais o shell trabalha stderr. stdinIsso também vale para os aplicativos.

Algum componente do sistema operacional está eventualmente movendo os dados gravados stdoutno terminal, caso contrário, eu não veria nada impresso.

Quando e onde uma conexão entre stdout/stdin/stderre o terminal acontece para que a interação com std*realmente resulte em algo no terminal?

Minha suposição aproximada que eu gostaria de ter desafiado é:

/dev/stdout, /dev/stdine /dev/stderrsão criados pelo shell em execução, eles não existem sem um shell.

O shell configura o canal de comunicação com o arquivo de dispositivo real que representa o terminal ( /dev/pts/10) e expõe as funcionalidades do terminal por meio /dev/stdoutde , /dev/stdine /dev/stderr. Dessa forma, o shell fornece aos aplicativos uma interface de arquivo simples, em vez de todos os aplicativos se preocuparem em como trabalhar o arquivo do dispositivo para impressão simples.

Atualizar

Apesar /dev/pts/10de ser um pseudoterminal, darei mais valor às respostas que conseguirem dar a resposta sem introduzir o conceito de pseudoterminal. Estou vindo de uma perspectiva que apenas distrairá a resposta à pergunta:

Quando e onde uma conexão entre stdout/stdin/stderre o terminal acontece para que a interação com /dev/std*realmente resulte em algo no terminal?

A criação de um servidor Bluetooth GATT em uma máquina Linux é feita usando BlueZ. A maneira preferida de usar o BlueZ moderno (5.50) é por meio da API dbus.

A documentação sobre este tópico afirma:

Os serviços GATT locais e remotos compartilham a mesma API D-Bus de alto nível. Local refere-se ao serviço baseado em GATT exportado por um plugin BlueZ ou um aplicativo externo. Remoto refere-se a serviços GATT exportados pelo peer.

Estou interpretando isso como:

Ambos os serviços locais (máquina Linux é o servidor, outros dispositivos se conectam a ele via Bluetooth) e serviços remotos (máquina Linux é o cliente, ela se conecta a outros dispositivos via Bluetooth) são representados no dbus

Isso define a suposição básica para a pergunta.

O código-fonte bluez fornece um example-gatt-server . Um exemplo, você pode executar e simplesmente funcionar e transformar sua máquina Linux em um servidor GATT.

Nesse exemplo, um objeto dbus nomeado arbitrariamente é referenciado. Seu nome é/org/bluez/example/service

A partir da documentação, eu esperaria que, uma vez ./example-gatt-serverexecutado com sucesso, houvesse um /org/bluez/example/serviceem algum lugar.

Esse não é o caso:

~$ busctl tree org.bluez
└─/org
  └─/org/bluez
    └─/org/bluez/hci0

Estou confirmando com um dispositivo externo que a máquina Linux está atuando como servidor GATT, mas /org/bluez/example/servicenão está listada.

Por que não é /org/bluez/example/serviceencontrado como um objeto em org.bluez?

Neste exemplo de um arquivo de unidade systemd:

# systemd-timesyncd.service
...

Before=time-sync.target sysinit.target shutdown.target
Conflicts=shutdown.target
Wants=time-sync.target

systemd-timesyncd.servicedeve começar antes time-sync.target . Isso define uma dependência de ordenação .

Mas ao mesmo systemd-timesyncd.service tempo quer time-sync.target . Assim time-sync.targeté a dependência de requisitos

Qual é o caso de uso para essa relação e por que eles não estão em conflito entre si?

Estou tentando definir um horário falso no Ubuntu 18.04 (systemd 237) para testar a execução de uma tarefa periódica mensal.

Isso está sendo executado em uma máquina virtual (virtualbox com adições de convidados).

A hora é redefinida para a hora correta após alguns segundos, mesmo que a sincronização ntp tenha sido desativada.

Exemplo.

# Disable the sync
timedatectl set-ntp 0
# There aren't any ntp daemons running
systemctl -a | grep ntp    # Returns nothing

# This confirms there is no sync active
timedatectl status         
#                       Local time: Mo 2019-03-11 15:22:13 CET
#                   Universal time: Mo 2019-03-11 14:22:13 UTC
#                         RTC time: Mo 2019-03-11 14:22:13    
#                        Time zone: Europe/Berlin (CET, +0100)
#        System clock synchronized: no                        
# systemd-timesyncd.service active: no                        
#                  RTC in local TZ: no           

# Setting up the fake time       
timedatectl set-time '2015-11-20 16:14:50'

# It worked! Wuhuu!
timedatectl status         
#                       Local time: Fr 2015-11-20 16:14:51 CET
#                   Universal time: Fr 2015-11-20 15:14:51 UTC
#                         RTC time: Fr 2015-11-20 15:14:51    
#                        Time zone: Europe/Berlin (CET, +0100)
#        System clock synchronized: no                        
# systemd-timesyncd.service active: no                        
#                  RTC in local TZ: no

# 5 sec later
timedatectl status         
#                       Local time: Mo 2019-03-11 15:25:35 CET
#                   Universal time: Mo 2019-03-11 14:25:35 UTC
#                         RTC time: Fr 2015-11-20 15:14:51    
#                        Time zone: Europe/Berlin (CET, +0100)
#        System clock synchronized: no                        
# systemd-timesyncd.service active: no                        
#                  RTC in local TZ: no

Se não houver serviço de sincronização, o que o mantém sincronizado?

Ao escrever uma mensagem /dev/kmsgenquanto segue /proc/kmsgas mensagens aparecem muito aleatoriamente, nunca aparece em /var/log/kern.log.

No entanto, dmesgrecebe todas as mensagens corretamente.

Exemplo

# Terminal 1
sudo tail -f /proc/kmsg

# Terminal 2 
tail -f /var/log/kern.log

# Terminal 3
sudo sh -c 'echo "<1> Kernel log message" > /dev/kmsg'
sudo sh -c 'echo "<1> Kernel log message" > /dev/kmsg'
sudo sh -c 'echo "<1> Kernel log message" > /dev/kmsg'
sudo sh -c 'echo "<1> Kernel log message" > /dev/kmsg'

Resultados:

# Terminal 1
# The message is shown at irregular intervals without a clear pattern
sudo tail -f /proc/kmsg
    <9>[37102.185491]  Kernel log message

# Terminal 2 
# No message is ever shown
tail -f /var/log/kern.log

# Terminal 4
# Everything is always here
dmesg
    [37101.556366]  Kernel log message
    [37102.185491]  Kernel log message
    [37103.042422]  Kernel log message

Ao conectar um pendrive, os dados são divididos aleatoriamente entre a saída de /proc/kmsge /var/log/kern.log. dmesgnovamente mostrar todas as mensagens.

• O que está dmesgfazendo diferente de outras abordagens?
• Por que é possível simplesmente quebrar o log do kernel do rsyslog fazendo com que outro processo escute /dev/kmsg. Por que minhas tentativas não são bloqueadas com device or resource busy?
• Por que o rsyslog nunca registra as mensagens enviadas /dev/kmsg, embora elas ocasionalmente alcancem proc/kmsg?

Digamos que um aplicativo de espaço do usuário tenha uma conexão TCP com algum ponto de extremidade não local. Em algum momento, a rede é interrompida abruptamente (ou seja, conexão excluída no gerenciador de rede, desconecte o dongle wifi, corte o cabo Ethernet)

O que está acontecendo conceitualmente dentro do kernel para lidar com a situação e como isso se manifesta no aplicativo de espaço do usuário?

Sub-questões de orientação:

• quais são os tempos limite envolvidos?
• o kernel tentará ocultar do espaço do usuário a conexão é perdida ao tentar se reconectar?
• esperar por uma resposta pode fazer com que o aplicativo userspace não queira sair normalmente?

Eu tenho um dispositivo incorporado que tem systemde rsyslog. journaldé o principal mecanismo para registro local e rsyslogpara registro remoto. O rsyslog nem sempre está em execução e é iniciado apenas quando a depuração é necessária.

Uma vez que o rsyslog é iniciado, ele encaminha apenas os eventos que acontecem a partir desse ponto no tempo. Estou tentando fazer com que ele encaminhe todos os logs que estão disponíveis no journald no momento.

A maneira correta de fazer isso seria habilitar $ModLoad imjournalno /etc/rsyslog.conf. Isso permitiria ao rsyslog ler os arquivos arquivados do journald.

Estou em um sistema embarcado que não possui o módulo imjournal disponível para rsyslog e estou procurando uma solução alternativa.

Uma solução alternativa seria ter journald reenviar todos os logs arquivados de antes para o soquete (agora ativo) que o rsyslog está ouvindo.

Existe uma maneira de fazer isso?

/dev/logé a entrada padrão para log do sistema. No caso de uma implementação do systemd (neste caso), é um link simbólico para qualquer arquivo /run/systemd/journal/dev-log. Costumava ser uma extremidade receptora de um soquete unix manipulado pelo daemon syslog.

~$ echo "hello" > /dev/log 
bash: /dev/log: No such device or address
~$ fuser /dev/log
~$ ls -la /dev/log 
lrwxrwxrwx 1 root root 28 Aug 23 07:13 /dev/log -> /run/systemd/journal/dev-log

Qual é o esclarecimento do erro que aparece quando você tenta gravar nele e por que não há um processo que contém esse arquivo (saída de fuser /dev/logvazio?

O log funciona normalmente no sistema.

~$ logger test
~$ journalctl --since=-1m
-- Logs begin at Thu 2018-05-24 04:23:46 CEST, end at Thu 2018-08-23 13:07:25 CEST. --
Aug 23 13:07:24 alan-N551JM alan[12962]: test

Estendendo com sugestões de comentários

~$ sudo fuser /dev/log 
/run/systemd/journal/dev-log:     1   311
~$ ls -lL /dev/log
srw-rw-rw- 1 root root 0 Aug 23 07:13 /dev/log

Estou tendo uma série de cartões SD com falha / às vezes com falha. Eles fornecem uma das seguintes dmesgsaídas:

Os completamente mortos (não liste em /dev/mmcblk0):

[  +0,000010] mmc0: error -110 whilst initializing SD card 
[  +2,819983] mmc0: card never left busy state

Os com falha (ocasionalmente ainda podem ser montados):

[Jun16 06:28] mmc0: new high speed SDHC card at address 0001
[  +0,000339] mmcblk0: mmc0:0001 00000 3.68 GiB 
[  +0,002835]  mmcblk0: p1 p2 p3 p4
[ +10,256689] mmcblk0: timed out sending r/w cmd command, card status 0x900
[ +11,264358] mmcblk0: timed out sending r/w cmd command, card status 0x900
[  +0,000016] print_req_error: I/O error, dev mmcblk0, sector 7716736
[ +10,239972] mmcblk0: timed out sending r/w cmd command, card status 0x900
[  +0,000018] print_req_error: I/O error, dev mmcblk0, sector 7716736
[  +0,000008] Buffer I/O error on dev mmcblk0, logical block 964592, async page read
[ +10,239931] mmcblk0: timed out sending r/w cmd command, card status 0x900
[  +0,000009] print_req_error: I/O error, dev mmcblk0, sector 81792
[Jun16 06:29] mmcblk0: timed out sending r/w cmd command, card status 0x900
[  +0,000020] print_req_error: I/O error, dev mmcblk0, sector 1066880
[ +10,240219] mmcblk0: timed out sending r/w cmd command, card status 0x900
[  +0,000011] print_req_error: I/O error, dev mmcblk0, sector 2101120

O melhor que tenho error -110é que é uma espécie de tempo limite , mas diz muito pouco sobre o que realmente aconteceu com o SDCard.

Antecedentes de como isso aconteceu

Os cartões SD acabam nesses estados em alguns (aparentemente aleatórios) dispositivos incorporados em que estou trabalhando, e estou tentando entender se é uma questão de cartões SD ruins ou se pode haver algo errado com o driver do controlador que está empurrando as cartas para a corrupção.

Cerca de 5% dos cartões morreram completamente, e estou tentando ver se isso é o que esperar dos outros.

Tentei forçar o SDcard a reproduzir o problema, mas os que estão sendo testados (mesma marca, mesmo tipo de dispositivo com o mesmo software) não mostram nenhum vestígio de desgaste após centenas de GB de dados gravados neles de maneira contínua como parte do teste. Eu uso o stressdisk para isso.

Eu não tenho uma pista de quantas vezes o dispositivo pode ter perdido energia abruptamente, e a fonte de alimentação é um adaptador AC-DC 2A regular que está funcionando bem para todas as outras necessidades do dispositivo.

Atualizar

A questão parece ser sugerida para ser fechada ou respondida de maneira helps me prevent failed SD cards in the futurediferente de using Linux to diagnose what is the current state of the SDcards.

Deixe-me tentar reformular então:

Qual é a maneira mais completa de analisar uma falha de cartão SD no Linux?

• É possível habilitar logs de depuração para o subsistema MMC para obter mais informações?
• O que é um card status 0x900?
• É possível detectar a comunicação SD-bus ou SD-bus do espaço do usuário para obter indicações de que o cartão está começando a falhar?

Eu tenho um modem USB detectado como um arquivo de dispositivo de dispositivo ( /dev/ttyACM0). O redirecionamento de comandos AT para o arquivo do dispositivo parece funcionar à medida que o modem responde.

Estou indo com a seguinte suposição, a parte superior representa um canal de controle. Através dele pode-se discar, configurar o modem, cancelar a conexão... em geral, fazer coisas relacionadas ao controle do modem sem realmente manipular o arquivo data. Com dataisso, quero dizer tudo o que não são controles (por exemplo, pacotes HTTP).

Onde ocorre o fluxo de dados? Se for pelo mesmo arquivo, como isso é multiplexado?

Também idealmente, alguém gostaria que o modem fosse apenas um "serviço" subjacente que fornece uma interface de rede com um IP, para que se possa abstrair isso e usar soquetes TCP/IP. Os soquetes são implementados no kernel.

Como isso se encaixa na imagem uma vez que o modem é exposto como /dev/ttyACM0no espaço do usuário ?

Estou tentando entender como as tabelas de símbolos se relacionam com a seção .data no ELF. Primeiro, algumas suposições que estou usando como base para começar.

Um símbolo é uma representação legível por humanos (ou "como escrito no arquivo de origem") de uma função ou variável que é mapeada para o valor binário real (no qual a CPU opera) disso.

Aqui está um exemplo

//simple.c
int var_global_init = 5;

int main(void)
{
  return 0;
}

Vamos construí-lo e examinar o binário:

$ gcc simple.c -o simple
$ objdump -t simple | grep var_global_init
  0000000000201010 g     O .data  0000000000000004              var_global_init

Ele lista o símbolo na .dataseção do arquivo ELF. A página 20 da documentação ELF define a .dataseção como:

Essas seções contêm dados inicializados que contribuem para a imagem da memória do programa.

Ok, isso meio que se encaixa. Então eu me pergunto Does this mean that the symbol table is embedded in the .data section?. Mas isso parece ser refutado pelo exemplo abaixo:

$ readelf -s simple
  Symbol table '.symtab' contains 66 entries:
  ....
  50: 0000000000201010     4 OBJECT  GLOBAL DEFAULT   23 var_global_init

readelfmostra que há uma .symtabseção dedicada no ELF que contém o símbolo.

A .dataseção precisa da tabela de símbolos real. O primeiro exemplo aponta para a conclusão de que existe um na dataseção, mas não deveria ser capaz de executar apenas os valores binários?

Ao verificar hexdump, consegui detectar apenas uma única entrada, então ou entendi errado os conceitos ou alguns deles estão mentindo. :)

Estou customizando o meu .tmux.confe encontrei muitos outros exemplos de customização de outras pessoas.

Aqui está um exemplo que aparentemente torna a divisão do painel tmux mais vim como:

set-option -g prefix C-w
unbind-key C-w
bind-key C-w send-prefix
set -g base-index 1

bind-key v split-window -h
bind-key s split-window -v
bind-key h select-pane -L
bind-key j select-pane -D
bind-key k select-pane -U
bind-key l select-pane -R

Qual é o significado da sintaxe para bind key, sete set-option?

Eu tenho um controlador que está conectado com btattach como um serviço systemd:

/usr/bin/btattach -B /dev/ttyACM0 -S 1000000

O mesmo comando parece resultar em diferentes enumerações. Às vezes é:

$ busctl tree org.bluez
└─/org
  └─/org/bluez
    └─/org/bluez/hci1

outros tempos:

$ busctl tree org.bluez
└─/org
  └─/org/bluez
    └─/org/bluez/hci0

Existe uma maneira de ter uma enumeração fixa?