Izzo's questions

Configurei o rsyslog para encaminhar determinadas mensagens de log para um pipe nomeado /tmp/logger.pipe. Em seguida, tenho um processo separado lendo o pipe nomeado. Seção relevante de/etc/rsyslog.conf

# Remote Logging (silly conditional rule needed for specific logging scenario)
$template RFC5424Format,"<%PRI%>1 %timegenerated:1:10:date-rfc3339%T%timegenerated:12:19:date-rfc3339%.%timegenerated:21:26:date-rfc3339%Z %HOSTNAME% - - -%msg%\n"
if ($msg contains 'remote="true"') then /tmp/logger.pipe;RFC5424Format

Permissões em /tmp/logger.pipe

prwxrwxrwx 1 ftp root 

Estou implantando este aplicativo em duas máquinas diferentes. Uma máquina possui rsyslog v3.xx e a outra v5.xx

O aplicativo está funcionando perfeitamente na máquina com o rsyslog v5.xx. No entanto, estou tendo um comportamento estranho na máquina com o rsyslog v3.xx Especificamente:

1. O rsyslogd às vezes leva uma eternidade para iniciar na inicialização (era muito rápido antes de eu adicionar a nova regra).
2. Quando a leitura do processo logger.pipeé reiniciada, o rsyslogd parece parar de gravar dados no pipe nomeado após a retomada do processo de escuta. A única maneira de corrigir isso é reiniciar manualmente o rsyslogd

Existe algum truque com a configuração do rsyslog que estou perdendo ao trabalhar com pipes nomeados? Algum outro problema de permissão que eu possa estar ignorando? Estou confiante no aplicativo, pois ele tem funcionado de forma muito robusta com a versão v5.xx do rsyslog. Infelizmente não tenho como atualizar a versão v3.xx na máquina com a qual estou tendo problemas.

Alguma ideia?

Atualização: posso ter diagnosticado o problema - parece ser um problema em que o rsyslogd fecha a conexão de gravação com o canal se não houver leitores. No entanto, o aplicativo leitor usa fopen() que bloqueia até que haja um gravador correspondente.

Por alguma razão, isso não é um problema no rsyslog v5.xx:

1. estado inicial onde rsyslogd e logger.out têm o pipe aberto com sucesso

2. problema de reinicialização em _logger.out, rsyslogd ainda tem gravação aberta no pipe

3. _logger.out é retomado e tudo funciona corretamente novamente

Mas esse comportamento é diferente no rsyslog v3.xx:

1. estado inicial onde rsyslogd e logger.out têm o pipe aberto com sucesso

2. problema de reinicialização em _logger.out, rsyslogd por algum motivo fecha a conexão com o pipe

Estou no processo de instalação do iptables em uma máquina armhf Debian 8.7 incorporada que não tem acesso à Internet. Meu método tem sido encontrar manualmente os arquivos do pacote .deb nos arquivos do Debian e, em seguida, enviá-los por FTP para a máquina Debian 8.7 e executar o dpkg.

Depois de um pouco de dificuldade, aparentemente consegui instalar o pacote iptables .deb e todas as suas dependências. No entanto, quando começo a tentar usar o iptables, recebo o seguinte erro:

modprobe: FATAL: Module ip_tables not found.
iptables v1.6.0: can't initialize iptables table `filter': Table does not exist (do you need insmod?)  

Ao executar lsmodposso de fato ver que o módulo ip_tables não está carregado ou mesmo instalado na minha máquina (não consigo encontrar os .ko em nenhum lugar da minha máquina).

Estou curioso - o dpkg do iptables deveria ter instalado os módulos do kernel do iptables? Ou o dpkg lida apenas com a configuração do espaço do usuário? Nota - não acredito que minha versão do kernel já tenha o iptables compilado nela.

Atualmente, estou estudando drivers de dispositivo em um curso de sistemas operacionais e estou ficando confuso em relação à diferença entre as estruturas "inode" e as estruturas "cdev". Alguém poderia esclarecer as diferenças entre essas duas estruturas e o que elas pretendem alcançar?

Estou aprendendo sobre o agendador de processos do Linux e tenho lido a função pthread_setsched: https://man7.org/linux/man-pages/man3/pthread_setschedparam.3.html

Uma coisa que me surpreendeu é que os threads podem modificar sua própria prioridade/classe. Eu posso ver como isso faz sentido para configurar certos aplicativos multi-thread (por exemplo, produtores e consumidores), no entanto, parece um risco de estabilidade do sistema que qualquer processo possa apenas solicitar para definir sua própria prioridade. O que está impedindo meu helloworld.out de solicitar SCHED_FIFO na prioridade mais alta? Isso pode bloquear completamente o sistema.

Então, quais mecanismos estão em vigor para impedir que um processo tenha total domínio do agendador? Parece que um erro do sistema EPERM pode ser definido, no entanto, onde isso está configurado?

Se eu fosse instalar um sistema de arquivos físico em uma máquina Linux, por que deveria montar esse sistema de arquivos em um local personalizado? Por que não ter o sistema de arquivos localizado no caminho do dispositivo? "/dev/...."

Atualmente, estou tentando atualizar as configurações de rede em um dispositivo Linux incorporado. Isso normalmente é feito modificando o conteúdo do arquivo /opt/etc/network/interfaces. O sistema de arquivos montado em /opt/ é por padrão RO, no entanto, alteramos isso temporariamente para RW enquanto atualizamos o conteúdo do arquivo usando o comando

mount -o remount,rw /opt

Confirmo que o sistema de arquivos foi atualizado para RW observando o conteúdo de /proc/mounts

Acredito que o sistema de arquivos agora pode ser lido e gravável, pois vejo as letras RW.

No entanto, quando vou modificar o arquivo, recebo um erro somente leitura.

Isso me confunde. O sistema de arquivos é leitura-gravação por /proc/mounts, no entanto, ainda estou recebendo um erro do sistema de arquivos. Não sou um mestre do sistema de arquivos, mas tenho três teorias sobre o que está acontecendo:

1. O dispositivo de armazenamento tem algum tipo de bloqueio de memória (ou seja, switch) ativado.
2. Este arquivo realmente vive em um sistema de arquivos aninhado, portanto, não está hospedado em /opt
3. Eu sou um manequim e estou perdendo algo óbvio.

Atualmente, estou enfrentando um problema ao me conectar a uma máquina Ubuntu universitária remota usando SSH (estou usando o VS Code como cliente SSH, se for importante). Após a conexão inicial, ele solicita que eu confie no dispositivo, faço isso e consigo me conectar. No entanto, um dia depois tento reconectar e ele gera um erro informando que a identidade do host da máquina foi alterada.

I SSH na máquina usando o nome DNS. Portanto, independentemente da alteração do endereço IP, ele sempre deve me direcionar para a mesma máquina física. Observe que a máquina na qual estou fazendo SSH é uma máquina de desktop física, não uma VM ou cluster.

Então, estou curioso, supondo que estou me conectando à mesma máquina física. Por que o SSH acha que o host remoto mudou? Se o endereço IP da mesma máquina física mudar, isso resultará em uma mudança de identidade?

Estou tentando assistir minhas estatísticas de rede via putty e quero gravar as estatísticas em um arquivo de log a cada segundo. Configurei o putty para registrar a sessão ssh em um arquivo de log. No entanto, estou lutando para emitir um comando putty que emite repetidamente o comando para extrair as estatísticas.

Minha primeira abordagem foi usar o comando "watch". Isso funcionou bem para executar o comando a cada segundo, no entanto, ele substituiria a saída do terminal toda vez que fosse atualizado e o arquivo de log não mostraria o histórico.

Minha pergunta: Como configuro o comando watch para anexar a saída da sessão em vez de apenas substituir repetidamente as linhas?

Estou fazendo alguma programação de soquete usando a interface POSIX. Estou tentando usar a função select() para monitorar quando um soquete sem bloqueio está pronto para ser lido/gravado.

Ao usar a função select(), dou a ela um conjunto de descritores de arquivo de leitura e gravação. Especificamente, tenho um único soquete fd que desejo verificar se é legível e gravável.

A documentação POSIX afirma que o valor de retorno é uma soma de todos os descritores de arquivo apresentados em todos os conjuntos fd.

Meus primeiros testes mostram que recebo um '2' de volta, o que é bom (isso significa que meu soquete é legível e gravável). No entanto, o que acontece se o descritor de arquivo não se tornar simultaneamente legível/gravável? Digamos que se torne legível um microssegundo antes de se tornar gravável? O que acontece? Ele apenas retorna um 1?

Eu tenho um controlador de processo baseado em Linux que ocasionalmente trava até o ponto em que você não pode fazer ping nele (ou seja, eu posso fazer ping nele, então ele não pode mais fazer ping sem nenhuma modificação nas configurações de rede).

Estou curioso, qual processo/sistema é responsável por realmente responder aos pings? Parece que este processo está falhando.