Artur Meinild's questions

Estou usando o servidor Ubuntu 22.04.3. Eu instalei nalausando o repositório Volian Scar . Recentemente, este repositório incluiu vários pacotes Python 3 atualizados, incluindo python3-anyio.

No entanto, este pacote específico não será atualizado:

$ sudo apt full-upgrade
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  python3-mdurl
The following packages have been kept back:
  python3-anyio
The following packages will be upgraded:
  python3-click python3-httpcore python3-markdown-it python3-pygments python3-rich python3-typer python3-typing-extensions
7 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
...

E se eu tentar forçar install python3-anyio, recebo o motivo exato:

$ sudo apt install --reinstall --dry-run python3-anyio 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3-anyio : Depends: python3-exceptiongroup but it is not installable or
                          python3 (> 3.11) but 3.10.6-1~22.04 is to be installed
E: Unable to correct problems, you have held broken packages.

Agora é evidente que este pacote atualizado requer "Grupos de Exceção" do Python 3, que estão incluídos no Python 3.11 (o Ubuntu 22.04 usa Python 3.10) ou no pacote backportado python3-exceptiongroup.

A pesquisa por este pacote no arquivo de pacotes do Ubuntu revela que este pacote faz parte do repositório Universe, mas apenas para Ubuntu 23.04 (Lunar) ou 23.10 (Mantic).

Quais opções eu tenho para evitar problemas de dependência nesta situação quando ainda quero atualizar meus pacotes?

Para sua informação, isso já foi relatado como um problema com Volian . Presumo que o pacote python3-exceptiongroupdeva ser adicionado ao repositório Volian no futuro.

ALAS, python3-exceptiongroupjá foi adicionado ao repositório Volian Scar, então agora esse erro de dependência não aparece mais. Ainda assim, o método nestas perguntas e respostas poderia ser usado em outras situações semelhantes.

No Ubuntu LTS, os aplicativos são bloqueados para a versão fixada na data de lançamento. Para o Ubuntu 22.04 "Jammy", esses são:

• nano 6.2-1
• htop 3.0.5-7
• tmux 3.2a-4
• lnav 0.9.0-2

Eu gostaria de instalar as versões upstream mais recentes desses aplicativos em meu servidor doméstico.

Como posso fazer isso de maneira fácil e confiável?

Recentemente, houve algumas perguntas perguntando por que o Ubuntu aparentemente está usando mais memória do que o contabilizado por processos/serviços - aqui e aqui .

No entanto, eu tenho a situação exatamente oposta. No meu servidor, a memória usada por todos os processos parece ser maior que a memória total usada. Deixe-me fornecer as evidências.

Saída de free -m:

               total        used        free      shared  buff/cache   available
Mem:           64277       15014       34424          31       14837       48530
Swap:           8191           0        8191

Saída de arcstat:

    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  size     c  avail
09:38:57     0     0      0     0    0     0    0     0    0  9.8G  9.8G    41G

Saída de ps aux | awk '{sum +=$6}END{print sum}':

6351512

Então, o que isso significa para mim é:

free -mrelata um total de 15,0 GB de memória usada (a memória compartilhada é insignificante). Subtraia desses 9,8 GB relatados por arcstatpara ZFS ARC Cache. O resultado restante é de cerca de 5,2 GB de memória usada "real". Mas a soma da coluna 6 em ps aux(RSS - tamanho do conjunto residente) totaliza 6,35 GB. Isso significaria que a memória relatada usada por todos os processos é 1,15 GB maior do que realmente é mostrada por free -m.

Gostaria de saber se existe uma maneira de calcular corretamente a memória usada por todos os processos, de modo que corresponda à memória usada (depois que o cache ZFS e os ramdisks compartilhados são subtraídos)?

Existe uma postagem existente no Unix e Linux sobre a inclusão de caracteres Unicode no prompt do Bash, mas o método fornecido para usar o código UTF-16 (sintaxe \uXXXX) não funciona para mim.

Vamos tomar esta seta como exemplo:

Caractere Unicode 'SETA PRETA PARA A DIREITA' (U+27A4)

Como posso ver, deve haver 3 maneiras de fazer caracteres Unicode no prompt do Bash PS1:

• Valor octal UTF-8 - neste caso:\342\236\244
• Valor UTF-8 HEX - neste caso:\xe2\x9e\xa4
• Valor UTF-16 HEX (combinado) - neste caso:\u27A4

No entanto, apenas a primeira opção funciona no meu prompt do Ubuntu, conforme indicado na imagem abaixo:

Explicação:

• Com PS1='[\u@\h \W]\$ \342\236\244 ', o caractere Unicode é aplicado corretamente.
• Com PS1='[\u@\h \W]\$ \xe2\x9e\xa4 ', a string exata é aplicada.
• Com PS1='[\u@\h \W]\$ \u27A4 ', ele aplica meu nome de usuário ( am) e o valor exato 27A4.

Eu entendo que \ué um atalho Bash para nome de usuário, e é por isso que estou confuso, a outra resposta afirma que isso funciona - para mim não.

Existe uma maneira de fazer a sintaxe UTF-16 funcionar para PS1 no Ubuntu (já que é mais curta e fácil de ler)? Estou no servidor Ubuntu 22.04.1.

Se você executar sarsem parâmetros, a saída será colorida, mas com cabeçalhos extras inseridos após cada página. Se você executar sar | catos cabeçalhos extras serão removidos, mas a coloração também.

Se você quiser canalizar menos, executar sar | lesstem o mesmo efeito que usar cat - cabeçalhos extras são removidos, mas as cores também. Se você deseja preservar a cor com less, você pode usar unbuffer(que é instalado como parte de expect) e less -R, mas os cabeçalhos extras aparecem novamente.

Acredito que isso seja melhor mostrado nas fotos abaixo (os cabeçalhos extras estão marcados na imagem 2).

O resultado de sar | less:

O resultado de unbuffer sar | less -R:

Então, é possível preservar as cores com o sarcomando usando lesse, ao mesmo tempo , não ter as linhas de cabeçalho extras para cada página (como marcada na imagem 2)?

Eu acho que pode ser possível fazer isso com alguns elaborados awk/ grep/ sedpipes (e talvez comandos encadeados), mas eu preferiria uma solução mais direta com os próprios comandos, se isso for possível. Isso também se deve ao fato de que eu gostaria de canalizar o resultado para lessusar um único comando.

Estou usando o Ubuntu Server 22.04.

Hoje, notei que o diretório /lib/modulesainda possui todos os diretórios dos kernels instalados anteriormente, assim:

$ ls /lib/modules
5.4.0-29-generic  5.4.0-31-generic  5.4.0-33-generic  5.4.0-37-generic  5.4.0-39-generic
5.4.0-40-generic  5.4.0-42-generic  5.4.0-45-generic  5.4.0-47-generic  5.4.0-48-generic
...  etc.

Em cada um desses diretórios, restam os seguintes arquivos (sistema Intel/AMD):

$ ls -l
-rw-r--r--  1 root 143K 2022-04-28 18:36 modules.alias
-rw-r--r--  1 root 154K 2022-04-28 18:36 modules.alias.bin
-rw-r--r--  1 root 8.0K 2022-04-08 10:44 modules.builtin
-rw-r--r--  1 root  25K 2022-04-28 18:36 modules.builtin.alias.bin
-rw-r--r--  1 root  11K 2022-04-28 18:36 modules.builtin.bin
-rw-r--r--  1 root  63K 2022-04-08 10:44 modules.builtin.modinfo
-rw-r--r--  1 root  85K 2022-04-28 18:36 modules.dep
-rw-r--r--  1 root 123K 2022-04-28 18:36 modules.dep.bin
-rw-r--r--  1 root  268 2022-04-28 18:36 modules.devname
-rw-r--r--  1 root 215K 2022-04-08 10:44 modules.order
-rw-r--r--  1 root  489 2022-04-28 18:36 modules.softdep
-rw-r--r--  1 root 279K 2022-04-28 18:36 modules.symbols
-rw-r--r--  1 root 326K 2022-04-28 18:36 modules.symbols.bin

E para um Raspberry Pi (observe as diferenças de tamanho):

-rw-r--r--  1 root 859K 2022-04-25 17:31 modules.alias
-rw-r--r--  1 root 893K 2022-04-25 17:31 modules.alias.bin
-rw-r--r--  1 root  11K 2022-04-04 13:33 modules.builtin
-rw-r--r--  1 root  27K 2022-04-25 17:31 modules.builtin.alias.bin
-rw-r--r--  1 root  14K 2022-04-25 17:31 modules.builtin.bin
-rw-r--r--  1 root  84K 2022-04-04 13:33 modules.builtin.modinfo
-rw-r--r--  1 root 399K 2022-04-25 17:31 modules.dep
-rw-r--r--  1 root 548K 2022-04-25 17:31 modules.dep.bin
-rw-r--r--  1 root  250 2022-04-25 17:31 modules.devname
-rw-r--r--  1 root 209K 2022-04-04 13:33 modules.order
-rw-r--r--  1 root  950 2022-04-25 17:31 modules.softdep
-rw-r--r--  1 root 354K 2022-04-25 17:31 modules.symbols
-rw-r--r--  1 root 425K 2022-04-25 17:31 modules.symbols.bin

Para um sistema que está em execução há 2 anos com todas as atualizações do kernel, isso equivale a ~50 diretórios antigos. Para um sistema Intel/AMD normal, são cerca de 100 Megabytes e, para um Raspberry Pi, são mais de 300 Megabytes no total - isso equivalerá a algo ao longo do tempo.

Então, eu me pergunto por que esses diretórios e arquivos de módulos antigos para kernels removidos não são removidos como parte do processo de limpeza?

Recentemente, atualizei do Ubuntu 20.04 para 22.04 (e é por isso que estou fazendo algumas coisas de limpeza de qualquer maneira).

Como as coisas estão atualmente, eu me pergunto se devo fazer meu próprio script de limpeza para esses diretórios restantes. Ainda assim, estou curioso por que não é feito automaticamente.

Estou usando o Docker 20.10.14 no Ubuntu 22.04 Server onde estou executando vários contêineres e estou usando o Watchtower para atualizar automaticamente os contêineres.

Desde que atualizei para o Ubuntu 22.04, tenho recebido mensagens de log excessivas de networkd-dispatcherquando os contêineres são atualizados. Estas são as mensagens de log que recebo:

May  3 01:03:06 xb networkd-dispatcher[1327]: ERROR:Unknown state for interface veth44e6185: initialized
May  3 01:03:06 xb networkd-dispatcher[1327]: Traceback (most recent call last):
May  3 01:03:06 xb networkd-dispatcher[1327]:   File "/usr/bin/networkd-dispatcher", line 428, in _receive_signal
May  3 01:03:06 xb networkd-dispatcher[1327]:     self.handle_state(iface_name,
May  3 01:03:06 xb networkd-dispatcher[1327]:   File "/usr/bin/networkd-dispatcher", line 345, in handle_state
May  3 01:03:06 xb networkd-dispatcher[1327]:     raise UnknownState(administrative_state)
May  3 01:03:06 xb networkd-dispatcher[1327]: UnknownState: initialized
May  3 01:03:06 xb networkd-dispatcher[1327]: ERROR:Unknown state for interface veth6d82244: initialized
May  3 01:03:06 xb networkd-dispatcher[1327]: Traceback (most recent call last):
May  3 01:03:06 xb networkd-dispatcher[1327]:   File "/usr/bin/networkd-dispatcher", line 428, in _receive_signal
May  3 01:03:06 xb networkd-dispatcher[1327]:     self.handle_state(iface_name,
May  3 01:03:06 xb networkd-dispatcher[1327]:   File "/usr/bin/networkd-dispatcher", line 345, in handle_state
May  3 01:03:06 xb networkd-dispatcher[1327]:     raise UnknownState(administrative_state)
May  3 01:03:06 xb networkd-dispatcher[1327]: UnknownState: initialized

Neste caso em particular, a interface veth44e6185é aquela que persiste após a atualização do container, enquanto eu suponho que a interface veth6d82244seja do container anterior, já que esta interface não existe mais.

Acredito que isso ocorra porque a interface de rede do Docker é reinicializada/reiniciada para cada contêiner quando é atualizada. As interfaces de rede do Docker são facilmente reconhecíveis, pois possuem o formato vethXXXXXXX, onde Xé um dígito hexadecimal.

Tudo está funcionando bem após a atualização dos contêineres, mas a quantidade de verbosidade nas mensagens de erro aumentou drasticamente com a atualização do Ubuntu 20.04 para 22.04.

Então, existe alguma maneira simples e inteligente de desabilitar as networkd-dispatchermensagens de log apenas para as interfaces do Docker?

O canonical-livepatchsnap não possui preenchimento automático para seus subcomandos. De acordo com a página de ajuda, os subcomandos válidos são:

$ canonical-livepatch help
...
COMMANDS:
   config - configure livepatching on the machine
   disable - disable livepatching on the machine
   enable - enable livepatching on the machine
   help - display help
   kernel-upgrade-required - indicate whether a kernel upgrade is required
   refresh - immediately download and apply any available livepatch
   status - show kernel's livepatch status

Existe uma maneira fácil de adicionar autocompletar para os subcomandos no canonical-livepatchsnap que funciona no Bash, sem precisar modificar o próprio snap?

Um pequeno detalhe é que o preenchimento automático também deve funcionar para o alias de snap livepatchque tenho para o comando.

$ snap aliases
Command              Alias      Notes
canonical-livepatch  livepatch  manual
lxd.lxc              lxc        -

Recentemente, houve conversas no Meta sobre o período de suporte de lançamentos LTS e não LTS neste site. Além disso, vi a menção ao Ubuntu Core em um comentário, e isso me fez pensar qual é o período de suporte do Ubuntu Core e se ele segue o período de suporte do Ubuntu LTS.

A Canonical afirma isso na página do Ubuntu Core :

O Ubuntu Core recebe 10 anos de manutenção canônica. Seus menores dispositivos agora são tão seguros quanto seus servidores. Nenhum outro Linux embutido chega perto.

Além disso, até onde eu entendo, o Ubuntu Core 16 ainda é a versão "núcleo" padrão para snaps. Isso é suportado pelo fato de que o Core 16 (chamado apenas de "core" no snap) tem um ciclo de atualização e controle de versão que segue exatamente a versão do snapd.

Saída de snap info snapd:

<...>
type:         snapd
snap-id:      PMrrV4ml8uWuEUDBT8dSGnKUYbevVhc4
tracking:     latest/stable
refresh-date: 9 days ago, at 23:27 CEST
channels:
  latest/stable:    2.51.4                  2021-08-25 (12883) 33MB -
  latest/candidate: 2.51.7                  2021-08-31 (13170) 33MB -
  latest/beta:      2.51.7                  2021-08-27 (13170) 33MB -
  latest/edge:      2.51.7+git1522.gc980bde 2021-08-31 (13216) 42MB -
installed:          2.51.4                             (12883) 33MB snapd

Saída de snap info core:

<...>
type:         core
snap-id:      99T7MUlRhtI3U0QFgl5mXXESAiSwt776
tracking:     latest/stable
refresh-date: 9 days ago, at 23:27 CEST
channels:
  latest/stable:    16-2.51.4                  2021-08-25 (11606) 104MB -
  latest/candidate: 16-2.51.7                  2021-08-31 (11743) 104MB -
  latest/beta:      16-2.51.7                  2021-08-27 (11743) 104MB -
  latest/edge:      16-2.51.7+git3168.3a0f4248 2021-09-01 (11771) 112MB -
installed:          16-2.51.4                             (11606) 104MB core

Outro elemento na mistura é que o Ubuntu Core não é lançado completamente em paralelo com os lançamentos LTS. Por exemplo, o Ubuntu Core 20 foi lançado em janeiro de 2021 , ou seja, 9 meses após o primeiro lançamento do Ubuntu 20.04.

Então, os lançamentos do Ubuntu Core seguem o mesmo período de suporte de 5 anos que os lançamentos LTS, ou são de fato 10 anos, de acordo com o período de manutenção de segurança da Canonical?

Isso também está relacionado ao tópico recente de Quanto tempo suportamos os sabores do Ubuntu? , bem como minha sugestão de reformular a explicação da Central de Ajuda .

Para que uma resposta seja considerada satisfatória, os seguintes elementos devem ser abordados:

• A relação entre os lançamentos do Ubuntu LTS e Core, incluindo a diferença nos tempos de lançamento
• O status "especial" do Ubuntu Core 16 (nomeado coreno snap) como a base que segue o controle de snapdversão
• Reflexões sobre como isso deve afetar o tempo de suporte no Ask Ubuntu
• Referência a fontes oficiais e/ou membros da equipe Ubuntu (em oposição à especulação)

Digamos que eu queira criar um alias chamado sspara o comando sudo -s. Mas ssjá é um comando existente, então quero criar outro alias chamado sstpara o comando ss.

Se estiver usando apenas os nomes de comando normais, isso não é possível, pois os aliases:

1. Não são definidos de uma forma que respeite a ordem, e
2. Referencie outros aliases, em vez de apenas referenciar comandos

Então se eu tentar o seguinte:

alias sst='ss'
alias ss='sudo -s'

Executar o comando sstresulta em running sudo -s, o que não é minha intenção.

Como isso pode ser feito?

Estou fazendo um script para imprimir as informações do sistema de arquivos ZFS - atualmente em fase de teste, e estou recebendo um erro estranho.

A parte relevante do meu script inicial é esta:

zfs_human="$(zfs list | head -n 2 | tail -n 1)"
dfs_human="$(df -h | grep 'zfs' | head -n 1)"
zfs_usedh="$(echo $zfs_human | cut -d ' ' -f2)"
zfs_totah="$(echo $dfs_human | cut -d ' ' -f2)"
echo "$zfs_human"
echo "$dfs_human"
echo "$zfs_usedh"
echo "$zfs_totah"

Dando a seguinte saída:

zfs                      2.31M  5.27T     34.4K  /mnt/zfs
zfs                      5.3T  128K  5.3T   1% /mnt/zfs
2.31M
5.3T

No entanto, quando executo shellcheck, ele diz que devo colocar aspas duplas nos nomes das variáveis ​​dentro da substituição do comando, esta é a saída de shellcheck:

In zfsspace.sh line 5:zfs_usedh="$(echo $zfs_human | cut -d ' ' -f2)"                  ^--------^
SC2086: Double quote to prevent globbing and word splitting.

Did you mean: 
zfs_usedh="$(echo "$zfs_human" | cut -d ' ' -f2)"

In zfsspace.sh line 6:zfs_totah="$(echo $dfs_human | cut -d ' ' -f2)"                  ^--------^
SC2086: Double quote to prevent globbing and word splitting.

Did you mean: 
zfs_totah="$(echo "$dfs_human" | cut -d ' ' -f2)"

Então, é claro, mudo meu código para a recomendação do shellcheck:

zfs_human="$(zfs list | head -n 2 | tail -n 1)"
dfs_human="$(df -h | grep 'zfs' | head -n 1)"
zfs_usedh="$(echo "$zfs_human" | cut -d ' ' -f2)"
zfs_totah="$(echo "$dfs_human" | cut -d ' ' -f2)"
echo "$zfs_human"
echo "$dfs_human"
echo "$zfs_usedh"
echo "$zfs_totah"

Mas agora a saída é esta:

zfs                      2.31M  5.27T     34.4K  /mnt/zfs
zfs                      5.3T  128K  5.3T   1% /mnt/zfs
 
 

As linhas 3 e 4 estão em branco, o que significa que a substituição do 3º e 4º comando não funciona ao seguir a recomendação do shellcheck, mas funciona quando não estou citando a variável que eu echo.

Estou usando o Bash 5.0.17 no Ubuntu 20.04.1

Alguém pode explicar isso por favor??? Obrigado.

Estou inicializando o servidor Ubuntu 20.04 a partir de um único disco nvme. Desde alguns dias atrás, o multipath está enviando spam para meu syslog com estas mensagens:

Jun 11 20:10:14 xb multipath: nvme0n1: failed to get udev uid: Invalid argument
Jun 11 20:10:14 xb multipath: nvme0n1: uid = eui.0000000001000000e4d25c7f117c5001 (sysfs)
Jun 11 20:10:17 xb multipath: nvme0n1: failed to get udev uid: Invalid argument
Jun 11 20:10:17 xb multipath: nvme0n1: uid = eui.0000000001000000e4d25c7f117c5001 (sysfs)
Jun 11 20:10:20 xb multipath: nvme0n1: failed to get udev uid: Invalid argument
Jun 11 20:10:20 xb multipath: nvme0n1: uid = eui.0000000001000000e4d25c7f117c5001 (sysfs)
Jun 11 20:11:34 xb multipath: nvme0n1: failed to get udev uid: Invalid argument
Jun 11 20:11:34 xb multipath: nvme0n1: uid = eui.0000000001000000e4d25c7f117c5001 (sysfs)
Jun 11 20:11:37 xb multipath: nvme0n1: failed to get udev uid: Invalid argument
Jun 11 20:11:37 xb multipath: nvme0n1: uid = eui.0000000001000000e4d25c7f117c5001 (sysfs)

Posso obter a seguinte lista de dispositivos para confirmar que monitora meu disco nvme:

multipathd> show devices
available block devices:
loop1 devnode blacklisted, unmonitored
nvme0n1 devnode whitelisted, monitored
loop6 devnode blacklisted, unmonitored
loop4 devnode blacklisted, unmonitored
loop2 devnode blacklisted, unmonitored
loop0 devnode blacklisted, unmonitored
loop7 devnode blacklisted, unmonitored
loop5 devnode blacklisted, unmonitored
loop3 devnode blacklisted, unmonitored
multipathd> 

Eu tentei o comando:

remove map nvme0n1

Mas recebi a mensagem: falhe

Então agora a pergunta é: como posso fazer com que ele pare de monitorar meu disco nvme e enviar spam ao syslog?