Em bash, quando digito cd ~sysem qualquer lugar, acabo em /dev. Nele zshfica como ~sysno prompt mas contém/dev
Eu verifiquei Kubuntu 22.04, Ubuntu 20.04, Raspbian 9.13.
Googling não produz nenhum resultado.
No bash, quando digito screen -xe pressiono tab duas vezes, obtenho uma lista de todas as sessões em execução.
No zsh, quando digito screen -lse pressiono tab duas vezes, obtenho uma lista de todas as sessões em execução e posso percorrê-las, eventualmente selecionar uma ao pressionar enter, mas isso é executado screen -ls session-nameao pressionar enter novamente.
O que eu quero em zsh é obter um comportamento -xsemelhante a -ls, para que eu não precise digitar o nome da sessão ou selecionar a sessão e voltar e mudar lspara x.
Não consigo encontrar o código que implementa o screen -lncomportamento da guia para também implementá-lo para -x, tenho pesquisado/pesquisado na lista de .oh-my-zshplug-ins, mas não estou chegando a lugar nenhum.
Qualquer ajuda é apreciada, ou talvez algumas dicas de fluxo de trabalho. Eu uso muito a tela e a maior parte é via screen -x.
Eu tenho um problema com curlem duas das minhas caixas. Em cerca de duas dúzias de instalações do Linux, não estou tendo problemas em usar segundos fracionários em arquivos curl --connect-timeout.
O comando de exemplo curl --connect-timeout 3.14 https://example.comestá falhando em apenas duas das minhas máquinas, que são meus únicos desktops, minhas únicas instalações do Kubuntu . O resto é principalmente Ubuntu Server e algumas instalações Debian, todas sem cabeça.
Esses dois desktops Kubuntu diferem em versões, um é um 22.04 LTS atualizado e o outro uma versão 20.04 LTS.
O Kubuntu 22.04 tem um curl --versionde
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.13
Release-Date: 2022-01-05
O Kubuntu 20.04 tem um curl --versionde
curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Release-Date: 2020-01-08
Para comparação, um Ubuntu Server 20.04 funcional tem um curl --versionde
curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Release-Date: 2020-01-08
que é idêntico à saída do Kubuntu 20.04 do curl --version.
Portanto, os servidores também possuem essas versões instaladas, mas há frações de segundos funcionando corretamente.
Ambos curl --manualproduzem o seguinte resultado grep:
~ curl --manual | grep -e "--connect-timeout"
--connect-timeout <fractional seconds>
curl --connect-timeout 20 https://example.com
curl --connect-timeout 3.14 https://example.com
See also --connect-timeout. Added in 7.47.0.
See also -m, --max-time and --connect-timeout. Added in 7.59.0.
See also --connect-timeout.
(no 20.04 é um pouco menos detalhado), então ambos estão dentro das versões necessárias para lidar com fracionários.
O que poderia estar causando isso?
Outra observação: fiz um md5sumno Kubuntu 20.04 e em uma caixa do Ubuntu 20.04 e ambos retornam o mesmo hash:
c337f891e41007612076a3bc43284aa7 /usr/bin/curl
portanto, os executáveis devem ser idênticos.
which curlestá retornando /usr/bin/curlem ambas as máquinas.
(O mesmo vale para as versões 22.04 com 4b7b5099e836abd910f580808adc0874 /usr/bin/curl)
O ambiente pode estar causando isso? Como?
Em todos os casos, verifiquei isso com bashe zsh.
Eu tenho uma máquina que possui o Windows e o Ubuntu 20.04. A partição ativa (primeiro item de inicialização no BIOS) é aquela em que o Ubuntu está instalado, e eu inseri manualmente as entradas no GRUB para ter o Windows como uma seleção para inicializar, que é definida como padrão.
Eu gostaria de poder usar um pendrive (ou talvez melhor um SD-Card) para alterar a seleção padrão. Se estiver inserido, deve inicializar no Ubuntu (a primeira entrada), caso contrário, deve usar a seleção padrão (a terceira entrada, Windows).
Eu precisaria (de alguma forma, eu não saberia como) instalar/copiar/dd GRUB no USB-Stick/SD-Card e selecioná-lo para ser o primeiro item na ordem de inicialização do BIOS, com um fallback para a partição do Ubuntu, qual é atualmente o primeiro na ordem de inicialização?
Ou existe (espero) uma ferramenta onde eu possa simplesmente colocar um arquivo no Stick/Card que é lido pelo GRUB?
Atualização: estive verificando os arquivos de configuração do GRUB e notei que existe um arquivo chamado /boot/grub/grubenvque possui uma entrada chamada next_entry=. Esta linha existe porque às vezes eu usei sudo grub-reboot 0para reiniciar no Ubuntu. Se eu executar sudo grub-reboot 0, essa linha muda para next_entry=0.
Agora estou pensando em modificar /etc/default/grub/00_headerpara verificar se um determinado dispositivo USB está conectado e, se estiver, que ele grava next_entry=0no grubenvarquivo ou que eu adicione algum código que apenas defina as variáveis necessárias semelhantes a como next_entry=0está sendo feito.
Então agora meu problema é que não sei quais ações podem ser executadas em 00_header, eventualmente usar curlpara buscar a variável seria perfeito, mas acho que nesse ponto nenhuma rede está presente e esse curl não é um comando reconhecido.
Como posso depurar/aprender o GRUB para ver o que é possível neste arquivo sem correr o risco de danificar o sistema?
No momento, estou pensando em usar uma VM limpa com um instantâneo no qual posso reverter se algo der errado, a fim de obter alguns insights. Mas talvez uma dica ou duas de especialistas aqui tenham muito valor para mim.
Hoje estourou um fusível que desligou um pequeno servidor.
Este servidor tem um USB-HDD conectado a ele, mas desde que o conectei cerca de 3-4 meses atrás, nunca desliguei o servidor totalmente (sem eletricidade), mas apenas emiti um arquivo sudo reboot.
Este USB-HDD estava listado em /dev/sdc, então eu tinha uma partição montada via sudo mount /dev/sdc1 /media/hdd5-usb-1.
Há também um SSD montado em , para que a aparência /dev/sdbcorreta seja a seguintefdisk -l
Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000ece66
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 499711 497664 243M 83 Linux
/dev/sda2 501758 500117503 499615746 238.2G 5 Extended
/dev/sda5 501760 500117503 499615744 238.2G 8e Linux LVM
Disk /dev/sdb: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CD3F3DA1-2901-45A0-B6E9-2BEEA36F3E78
Device Start End Sectors Size Type
/dev/sdb1 2048 1000214527 1000212480 477G Linux filesystem
Disk /dev/mapper/n3150--vg-root: 222.4 GiB, 238769143808 bytes, 466345984 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/n3150--vg-swap_1: 15.9 GiB, 17028874240 bytes, 33259520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/sdc: 4.6 TiB, 5000981077504 bytes, 9767541167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 0B9E1A83-476F-47AE-8234-2D29497F55CA
Device Start End Sectors Size Type
/dev/sdc1 2048 9767541133 9767539086 4.6T Linux filesystem
Após a queda de energia e a seguinte inicialização automática do servidor as entradas ficaram assim:
Disk /dev/sda: 4.6 TiB, 5000981077504 bytes, 9767541167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 0B9E1A83-476F-47AE-8234-2D29497F55CA
Device Start End Sectors Size Type
/dev/sda1 2048 9767541133 9767539086 4.6T Linux filesystem
Disk /dev/sdb: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000ece66
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 2048 499711 497664 243M 83 Linux
/dev/sdb2 501758 500117503 499615746 238.2G 5 Extended
/dev/sdb5 501760 500117503 499615744 238.2G 8e Linux LVM
Disk /dev/sdc: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CD3F3DA1-2901-45A0-B6E9-2BEEA36F3E78
Device Start End Sectors Size Type
/dev/sdc1 2048 1000214527 1000212480 477G Linux filesystem
Disk /dev/mapper/n3150--vg-root: 222.4 GiB, 238769143808 bytes, 466345984 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/n3150--vg-swap_1: 15.9 GiB, 17028874240 bytes, 33259520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Obviamente, isso teve alguns problemas bastante desagradáveis, já que o banco de dados no SSD no esperado /dev/sdb1~ de /media/ssd1repente foi apresentado a partição de inicialização, e o que se acreditava ser o HDD USB era na verdade o SSD montado.
Como posso evitar que algo assim aconteça novamente? Como posso "fixar" um hardware em uma /dev/sd*entrada específica?
Eu uso molly-guardem todas as minhas máquinas, mas às vezes quero ssh em uma máquina e executar um script que, como etapa final, deve reinicializar essa máquina, mas há o problema que aparece molly-guarde solicita o nome do host.
Estou procurando algo como o --molly-guard-do-nothingsinalizador, mas ao invés de não fazer nada seria chamado --molly-guard-do-not-aske não pediria confirmação.
A página de manual não tem informações sobre isso, então gostaria de saber se há uma solução alternativa.
Eu só preciso que isso funcione quando eu tiver ssh'd na máquina; isto é, nunca seria necessário no contexto de um cronjob ou algo assim, mas eu não me importaria se funcionasse também.
Para ser mais específico, este é o script em questão:
sudo apt-get update && apt list --upgradable
echo ""
echo "---- ok. what next? ----"
echo ""
read -n 1 -p "exit or upgrade? (E/u) " ans;
case $ans in
u|U) printf "\n\nok, invoking 'sudo apt-get upgrade'\n\n"; sudo apt-get upgrade;;
*) printf "\nok, exited\n\n"; exit;;
esac
echo ""
echo "---- ok. what next? ----"
echo ""
read -n 1 -p "exit, autoremove or reboot? (E/a/r) " ans;
case $ans in
a|A) printf "\n\nok, invoking 'sudo apt-get autoremove'\n\n"; sudo apt-get autoremove;;
r|R) printf "\n\nok, invoking 'sudo reboot'\n\n"; sudo reboot;;
*) printf "\nok, exited\n\n"; exit;;
esac
echo ""
echo "---- ok. what next? ----"
echo ""
read -n 1 -p "exit or reboot? (E/r) " ans;
case $ans in
r|R) printf "\n\nok, invoking 'sudo reboot'\n\n"; sudo reboot;;
*) printf "\nok, exited\n\n"; exit;;
esac
Estou tendo um problema aqui em que tento automatizar uma configuração com o Ansible.
Algumas das etapas exigem interação com apt, mas ocasionalmente recebo um erro porque a atualização autônoma foi iniciada e bloqueada no apt. Isso fará com que a cartilha pare.
Eu tentei muitas maneiras de contornar isso, sendo a mais bem-sucedida a repetição de um comando apt com falha.
Mas isso não escala, também não é 100% confiável e parece ruim.
Optei por emitir um apt -y purge unattended-upgradesdireito no início do manual. Eu também tentei apt -y remove unattended-upgrades, mas esse parece retornar enquanto ainda está no trabalho. A limpeza parece encerrar as atualizações autônomas antes de sair, que é o que eu quero.
Mas acontece que mesmo essa chamada para apt -y purge unattended-upgradespode falhar devido ao bloqueio. Então eu mudei para while [[ $(dpkg -l | grep -P "unattended-upgrades" | wc -c) -ne 0 ]]; do apt -y purge unattended-upgrades; done, mas também isso falha ocasionalmente (não consigo descobrir o porquê)
Eu preciso de um comando que, quando executado, encerrará e enterrará atualizações autônomas imediatamente, independentemente de estar em execução ou não, e garantirá que não será mais iniciado assim que o comando retornar, até que eu apt installo explicitamente novamente. Tudo bem se esse comando demorar um minuto para terminar seu trabalho.
Além disso, o sistema não tem o Python instalado, então o Ansible está apenas emitindo rawcomandos, até eu conseguir instalar o Python, que deve ser após uma chamada bem-sucedida paraapt -y update
Estou em um estado em que posso acionar atualizações autônomas facilmente, pois esta é uma VM, e assim que eu emitir um date -scomando para corrigir a data obsoleta, a atualização autônoma é iniciada. Depois de iniciar a VM, tenho alguns minutos até dateque se corrija automaticamente, o que inicia atualizações autônomas.
Isto é o que estou fazendo agora:
- name: Disable autoupdate (part 1 of 2)
raw: sed -i /Update/s/"1"/"0"/ /etc/apt/apt.conf.d/10periodic && sync
- name: Disable autoupdate (part 2 of 2)
raw: echo 'APT::Periodic::Unattended-Upgrade "0";' >> /etc/apt/apt.conf.d/10periodic && sync
- name: Terminate any active autoupdate
raw: ps -A | grep unattended-upgrades | awk '{print $1}' | xargs -r kill -15 $1
- name: Terminate any active dpkg
raw: ps -A | grep dpkg | awk '{print $1}' | xargs -r kill -15 $1
- name: Allow dpkg to recover
raw: dpkg --configure -a
- name: Purge autoupdate
raw: apt -y purge unattended-upgrades
- name: Update apt cache
raw: apt -y update
- name: If needed, install Python
raw: test -e /usr/bin/python || apt -y install python
Terminar o dpkg é o que me assusta. Tudo o que é executado em uma nova instalação do Ubuntu Server 18.04.1
Aqui está a solução criada usando a resposta aceita:
Eu tenho uma pequena máquina Celeron que executa o Ubuntu 16.04.3 LTS e toda vez que preciso reiniciá-la (cerca de uma vez por mês), tenho que desligá-la, puxar o plugue e ligá-la novamente.
O problema é que ele não reinicia automaticamente, porque para com uma mensagem Reached target Shutdown. Então parei de usar sudo reboot, mas sudo poweroffem vez disso faço um e logo em seguida aparece essa mensagem.
Quando espero alguns minutos, uma mensagem adicional é exibida 3102533.654120 unregister_netdevice: waiting for lo to become free. Usage count=1. O segundo contador (como na medição de tempo) é alto, cerca de 3102533, o que equivale a cerca de 36 dias, provavelmente a hora da última reinicialização. Portanto, ainda há algo sendo executado em segundo plano emitindo essa mensagem.
Como isso já aconteceu antes e a maioria dos acessos do Google está relacionada ao Docker, certifiquei-me de interromper todos os contêineres docker stop $(docker ps -a -q)e desligar o serviço docker sudo systemctl stop dockerantes de emitir o arquivo sudo poweroff.
Nesse estranho estado de desligamento, também não é possível desligar a máquina com um pressionamento normal do botão liga / desliga (um pressionamento muito longo desliga, iirc) e um pressionamento do botão de reinicialização também não reinicia a máquina, o que eu acho ser muito estranho. É um http://www.asrock.com/mb/Intel/N3150DC-ITX/
O que mais me preocupa é o fato de que a luz do "hdd" (é um ssd) fica piscando esporadicamente, como se estivesse interagindo com o disco, o que me dá medo de corromper alguma coisa ao puxar o plugue da tomada. https://www.youtube.com/watch?v=T3ojE1un7WE
É seguro puxar o plugue? Como posso rastrear a causa desse problema? Não posso fazer muita reinicialização com a máquina, pois ela hospeda alguns bancos de dados que são constantemente acessados.
Acima foi em 12 de fevereiro, o que segue é em 16 de março
Acabei de "reiniciar" a máquina novamente. Mesmo procedimento acima, pois não desliga.
Desta vez não fiz apt upgrade/dist-upgradeantes de reiniciar, fiz isso depois, para ter certeza de que algo que está sendo atualizado não é a causa desse problema.
Pressionei ctrl-alt-del algumas vezes enquanto esperava desligar, não surtiu efeito, até que apareceu uma mensagem:
Ctrl-Alt-Del foi pressionado mais de 7 vezes em 2s, reiniciando imediatamente
(não acho que os pressionei tão rapidamente, acredito que eles foram armazenados em cache de alguma forma ou pressionei por muito tempo) seguido por um
2697473.41.. systemd-shutdown[1]: Falha ao finalizar os dispositivos DM, ignorando (o espaço extra antes do DM faz parte dessa mensagem)
e então um
2697473.63.. reboot: Reiniciando o sistema
Mas não reiniciará, a luz do HDD ainda piscará ocasionalmente, a tela não limpará as mensagens.
Pressionar o botão de reinicialização não reinicializa a máquina. O botão não está com defeito.
Um pressionamento longo do botão liga/desliga desliga a máquina. Outra pressão o reinicia, então o botão de reset funciona conforme o esperado, posso pressioná-lo a qualquer momento e fará com que o sistema reinicie imediatamente.
Depois de ligado, fiz o apt update/upgrade/dist-upgrade e sudo poweroff'ed novamente. Ele desligou muito bem.
Há algo realmente estranho acontecendo quando a máquina fica ligada por dias, o que deve estar causando esse problema.
Estou usando molly-guard, não tenho certeza se isso pode causar alguns problemas. Quando eu emito o sudo shutdownfaço localmente no teclado anexo, então molly-guardnão tem efeito. Mas duvido que essa molly-guardseja a fonte do problema.
Eu fiz um top -b > test-pre-reboot-no-upgrade.txtantes de emitir o sudo shutdown, aqui está a saída https://pastebin.com/nZnJzRKu
Enquanto desejava atualizar o MongoDB de 3.4 para 3.6, entrei no /etc/apt/sources.list.ddiretório. De lá, eu queria mover os arquivos mongodb-org-3.4.liste para meu diretório pessoal.mongodb-org-3.4.list.save
Eu primeiro executei um arquivo mv mongodb-org-3.4 ~/*. Por algum motivo, consegui mover o curinga para o final do comando. Depois de ver a notificação mv: cannot stat 'mongodb-org-3.4': No such file or directory, "corrigi" isso digitando mv mongodb-org-3.4* ~/*, novamente com o curinga no final. Não usei sudo, não era root.
Como resposta para mv mongodb-org-3.4* ~/*eu tenho
mv: cannot remove 'mongodb-org-3.4.list': Permission denied
mv: cannot remove 'mongodb-org-3.4.list.save': Permission denied
mv: inter-device move failed: '/home/user/atlassian' to '/home/user/windows-storage/atlassian'; unable to remove target: Directory not empty
mv: inter-device move failed: '/home/user/data' to '/home/user/windows-storage/data'; unable to remove target: Directory not empty
mv: cannot create symbolic link '/home/user/windows-storage/dockervolumes/sharemanager': Read-only file system
Em seguida, entrei no /home/user/windows-storagediretório e o localizei, apenas para descobrir que provavelmente todo o meu diretório inicial foi copiado (???) para este diretório montado.
Danifiquei alguma coisa? Ou eu "apenas" copiei o diretório inicial para este diretório montado?
Por que esse mvcomando de alguma forma se comportou cp?
Ok, acontece que os arquivos foram movidos, mas não todos, desde que eu Ctrl+ \porque estava demorando muito para terminar