Simplesmente desliguei o pc ontem com 20% da capacidade da partição / e ao ligar ele hoje recebo a seguinte mensagem
Não consigo imaginar nada que possa ter ocasaionado isso
Dê uma olhada nos Snaps antigos. O Snap age automaticamente baixando versões mais novas em segundo plano quando disponível, e quando você se dá por conta a unidade tá lotada.
Lista todos os snaps instalados:
$ snap list --all
1 curtida
Tá com cara de ser log:
Pra verificar:
du -sh "/var/log"
Pra remover:
find "/var/log" -type f -print0 | sudo xargs -0 truncate -s0
4 curtidas
O que são logs? tô sempre dando uma olhada nos tópicos para ver possíveis coisas que aconteçam comigo, por isso gostaria de saber de antemão, desde já agradeço 
1 curtida
É um registro que software faz do que esta acontecendo.
Eles são útil para detectar problemas e mau funcionamento do software.
1 curtida
Se não for os registro de logging, você pode nos dar um quadro geral colocando aqui o resultado de:
sudo du -h --max-depth=1 /
Zerar os arquivos não seria o ideal, além de perdemos dados do que aconteceu, pode se repetir. Seria melhor limitar o crescimento dos arquivos de log configurando o journald e usando alguma ferramenta para rotacionar os logs como logrotate. 20% sumindo assim de um dia para o outro é incomum, se for os logs, alguma coisa spamou o log e só limpar o log pode não evitar que se repita.
1 curtida
É com certeza é algum arquivo de log nessa pasta, pelo que da para ver não é o journald. Vamos olhar um pouco mais fundo com:
sudo ls -hals /var/log
Se ficar muito longo pode ser uma boa ideia usar o pastebin.
2 curtidas
Pelo que me lembro no /var/log/journal ficam os logs em arquivos binários, do jeitão que o systemd gosta, compactados e impossível de visualizar sem as ferramentas do próprio systemd.
Já no /var/log fica uma série de arquivos de log no formato antigo, que o serviço syslogd (ou algum similar) vai gerar a partir do log do systemd (que é o padrão em diversas distribuições).
O correto mesmo é visualizar o log e ver qual processo entrou em loop de erro e entupiu o disco do colega com mensagens de erro. Daí procurar a solução desse problema.
A primeira coisa a fazer é liberar espaço em disco para poder usar o computador. Para isso zere o conteúdo de algum arquivo gigante que esteja no /var/log com touch arquivogigante.log
Daí monitore o log em tempo real para ver o que está acontecendo, pode ser pelo journalctl -f ou no modo antigo com tail -f arquivogigante.log
Com o erro que vai encher sua tela, aperte Ctrl+C e cole aqui pra gente analisar e tentar achar a solução.
1 curtida
Existem outras possibilidades também:
- Você pode usar um pendrive de inicialização para inspecionar a partição lotada a fim de não perder o que já está no arquivo culpado.
- Se tiver acesso a outro tty e a login do root pode se aproveitar do fato que alguns sistemas de arquivos reservam um espaço para o root trabalhar e manipular via root o sistema.
- Inicializar em modo de emergência e remontar a partição em modo leitura/escrita após análise dos arquivos em modo leitura, não sei qual é o método na distro do colega mas adicionando
emergencyaos parâmetros de boot via grub resolve no Fedora.
Galera, seguinte, acho que encheu a pasta de novo e agora meu pc n quer iniciar.
Só tenho um oen drive bootavel de Ubuntu aqui. O que posso fazer?
Isso já aconteceu comigo no passado (sistema não carregar por causa de disco cheio), mas, por motivos diferentes.Sinceramente, eu julgo uma falha do Linux permitir que o disco atinja 100%. Faça o seguinte:
Use um live-CD/live-DVD se possível e transfira arquivos para o pendrive, depois reinicie o sistema, recomendo que na sequência faça uma limpeza geral no sistema, excluindo sobra de arquivos, histórico de internet e até desinstalando alguns programas.
sudo apt-get autoclean
sudo apt-get clean
sudo apt-get autoremove
O que eu faria:
Boot pelo pendrive, monta a partição raiz e apaga algum arquivo la na pasta de logs.
Inicia o computador. Monitora os logs para saber qual é o erro que fica direto no seu computador, que acaba por lotar seu disco.
Resolve o problema.
Se não quiser resolver o problema e simplesmente ignorar os logs, tem jeito de configurar logs logs de forma não persistente.
matheus@matheusr:/var/log$ du -ha
4,0K ./syslog.4.gz
80K ./dmesg
44K ./Xorg.1.log
0 ./bootstrap.log
52K ./Xorg.0.log.old
68K ./syslog.2.gz
4,0K ./kern.log.2.gz
12M ./syslog
20K ./dmesg.2.gz
96K ./auth.log
44K ./Xorg.0.log
4,0K ./openvpn
28K ./dpkg.log.1
0 ./boot.log.5
4,0K ./dist-upgrade
0 ./alternatives.log
0 ./apport.log.5.gz
du: não foi possível ler diretório ‘./private’: Permissão negada
4,0K ./private
0 ./btmp
16K ./unattended-upgrades/unattended-upgrades-dpkg.log
0 ./unattended-upgrades/unattended-upgrades-shutdown.log
4,0K ./unattended-upgrades/unattended-upgrades-shutdown.log.1.gz
0 ./unattended-upgrades/unattended-upgrades-shutdown.log.2.gz
4,0K ./unattended-upgrades/unattended-upgrades.log.1.gz
0 ./unattended-upgrades/unattended-upgrades.log.2.gz
8,0K ./unattended-upgrades/unattended-upgrades.log
0 ./unattended-upgrades/unattended-upgrades-dpkg.log.1.gz
36K ./unattended-upgrades
0 ./syslog.7.gz
2,2M ./kern.log
0 ./auth.log.4.gz
4,0K ./gpu-manager.log
4,0K ./gpu-manager-switch.log
36K ./boot.log.1
3,2M ./syslog.1
8,1M ./journal/13da3002fed0469283aaa613e785092e/system@0005ab9f26fafd8d-d2ff39a8298c15ee.journal~
129M ./journal/13da3002fed0469283aaa613e785092e/system@4a801ec725a440fa957f358746bc387c-0000000000000001-0005ab9f26f8f0ac.journal
17M ./journal/13da3002fed0469283aaa613e785092e/user-1000.journal
33M ./journal/13da3002fed0469283aaa613e785092e/system.journal
49M ./journal/13da3002fed0469283aaa613e785092e/user-1000@6c399bff55184a8db619879be7747a4c-0000000000000abb-0005ab9f285ffe5b.journal
233M ./journal/13da3002fed0469283aaa613e785092e
233M ./journal
0 ./syslog.6.gz
0 ./boot.log.6
24K ./boot.log.3
4,0K ./apport.log.2.gz
0 ./auth.log.3.gz
4,0K ./dpkg.log.2.gz
0 ./ubuntu-advantage.log
0 ./kern.log.3.gz
80K ./dmesg.0
0 ./kern.log.4.gz
20K ./dmesg.3.gz
24K ./dmesg.1.gz
4,0K ./cups/access_log.2.gz
0 ./cups/access_log.6.gz
0 ./cups/error_log.6.gz
8,0K ./cups/error_log
48K ./cups/access_log
0 ./cups/access_log.5.gz
0 ./cups/error_log.3.gz
12K ./cups/access_log.1
0 ./cups/error_log.7.gz
0 ./cups/access_log.7.gz
0 ./cups/error_log.1
0 ./cups/error_log.5.gz
0 ./cups/error_log.4.gz
4,0K ./cups/access_log.3.gz
0 ./cups/error_log.2.gz
4,0K ./cups/access_log.4.gz
84K ./cups
0 ./btmp.1
4,0K ./hp/tmp
8,0K ./hp
24K ./dpkg.log
28K ./wtmp
44K ./Xorg.1.log.old
4,0K ./alternatives.log.2.gz
0 ./apport.log.3.gz
du: não foi possível ler diretório ‘./gdm3’: Permissão negada
4,0K ./gdm3
4,0K ./alternatives.log.1
37G ./uvcdynctrl-udev.log
4,0K ./auth.log.2.gz
4,0K ./apt/history.log
4,0K ./apt/term.log.1.gz
16K ./apt/term.log
80K ./apt/eipp.log.xz
4,0K ./apt/history.log.1.gz
0 ./apt/history.log.2.gz
0 ./apt/term.log.2.gz
112K ./apt
0 ./fontconfig.log
0 ./apport.log.4.gz
76K ./auth.log.1
du: não foi possível ler diretório ‘./speech-dispatcher’: Permissão negada
4,0K ./speech-dispatcher
0 ./boot.log.7
0 ./lastlog
20K ./dmesg.4.gz
0 ./faillog
4,0K ./boot.log.2
4,0K ./apport.log.1
0 ./apport.log.7.gz
0 ./boot.log.4
120K ./boot.log
0 ./apport.log
0 ./installer/media-info
0 ./installer/syslog
0 ./installer/version
0 ./installer/telemetry
0 ./installer/debug
0 ./installer/initial-status.gz
0 ./installer/partman
0 ./installer/casper.log
4,0K ./installer
160K ./syslog.3.gz
1,2M ./kern.log.1
0 ./syslog.5.gz
0 ./apport.log.6.gz
37G .
Por enquanto tenho que estar fazendo isso toda semana, senão lota a partição /
Queria ver o povo que reclama do Windows aqui agora. Segundo eles isso NUNCA acontece no Linux. “Jamais usaria um sistema assim” - dizem eles. “Você quer usar o computador e não pode”… 
Espero que em breve o confrade encontre a solução pertinente.
1 curtida
Então, esse arquivo que está gigante. Verifique qual é a mensagem de erro e e procure uma solução.
-
O erro já deve aparecer no final do arquivo
sudo tail -n100 uvcdynctrl-udev.log -
Daí apague o arquivo e inicie o computador no sistema que já terá espaço livre.
-
Resolva a condição que está gerando o erro.
Segundo esse post do Ask Ubuntu, o escritor produtivo aí é um programa no Ubuntu que serve para gerenciar webcams, mas em muitos modelos ele esperneia e gera logs quilométricos.
Soluções
Aqui tem instruções pra fazer o programa calar a boca. Abrir o arquivo /lib/udev/uvcdynctrl como adminstrador e trocar todos os debug=1 com debug=0 com Procurar e Substituir.
Lá aconselha-se dar a bota no programa logo. No geral as funções dele são pouco úteis (gerenciar LED independente da webcam, por exemplo) pro problema que você tá tendo:
sudo apt remove uvcdynctrl uvcdynctrl-data libwebcam0
Há reportes desse bug desde 2011 e o mantenedor ainda não fez nada a respeito disso.
Porque diabos o time do Ubuntu não removeu o pacote (o time do Linux Mint pelo visto já removeu) está além da minha compreensão.
Calma lá, o Windows entope o sistema “por esporte”, ou seja, mesmo sem nenhum problema em uma ou duas semanas já tá sugando 2-4 GB com lixo (eu sei disso porque comprei um Notebook recentemente e sem contar dados de internet/lixeira tá com 3GB de lixo virtual), o Ubuntu 18.04 após 2 anos tá com 427 MB usando todo dia