Upstart melkein söi kovalevyn

[Arello]

Minulla on siis 240 gigan SSD, jossa on vain Ubuntu ja siinä piti olla noin reilu 20 gigaa tilaa ja yhtäkkiä kaikki hävisi. Sitten siirsin ulkoiselle kovalevylle yhden 16 gigan kansion ja taas tila täyttyi yhtäkkiä. Ajattelin, että jokin prosessi ehkä veisi välimuistista jatkuvalla syötöllä jotain ja käynnistin koneen uusiksi, ei auttanut. Tutkin levynkäyttöä ja ehkä todennäköisin havaintoni oli se, että jokin .cache kansiossa sijaitseva "upstart" vie nyt jotain melkein 40 gigaa, mikä käy myös yhteen tuon juuri menetetyn tilan kanssa. Kansiota selatessa moista ei tietenkään tullut vastaan. Mitä asialle olisi tehtävissä? En etsimällä löytänyt netistä mitään relevanttia tietoa tuosta upstartista.

Tällä hetkellä se ei enää näytä syövän enempää. Päivittelen tähän viestiin sitä mukaa, jos jotain tapahtuu. Haluaisin joka tapauksessa nuo 40 gigaa takaisin...

EDIT: Käynnistin vielä kertaalleen uudestaan ja nyt on 43,8 gigaa tilaa. JACK-audioviritelmät piti tosin asettaa uudelleen ja selain unohti lähes kaikki asetukset ja salasanat. Upstart näyttää saman määrän kohteita, mutta on nyt 80,9 Mt, joten olin oikeassa siitä. Olisi silti mielenkiintoista tietää, mitä tapahtui ja miksi. Lähinnä, että voiko sama toistua?

[nm]

Tutkin levynkäyttöä ja ehkä todennäköisin havaintoni oli se, että jokin .cache kansiossa sijaitseva "upstart" vie nyt jotain melkein 40 gigaa, mikä käy myös yhteen tuon juuri menetetyn tilan kanssa. Kansiota selatessa moista ei tietenkään tullut vastaan.

Saat pisteellä alkavat piilotiedostot ja -hakemistot näkyviin tiedostoselaimessa painamalla Ctrl+H
Tuo .cache/upstart sijaitsee siis kotihakemistossasi.

Mitä asialle olisi tehtävissä? En etsimällä löytänyt netistä mitään relevanttia tietoa tuosta upstartista.

~/.cache/upstart-kansioon kirjoitetaan työpöytäjärjestelmän ja siinä toimivien ohjelmien lokeja. Joku palvelu tai ohjelma todennäköisesti kirjoittaa lokiinsa jotain virheilmoitusta hyvin nopeasti ja täyttää levyn. Tässä pari vastaavaa tapausta:

https://bugs.launchpad.net/unity/+bug/1240848
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1284164

Jos ongelma toistuu, näytä tiedostolistaus tuosta hakemistosta, niin tutkitaan, mikä lokitiedosto kasvaa ja mitä se sisältää. Eli komenna päätteessä:

Koodia: [Valitse]

ls -S -s ~/.cache/upstart/
ja kopioi listauksen alkuosa tänne. (-S järjestää tiedostot isoimmasta pienimpään)

[Arello]

Kolusin siis .cachen, mutten sieltä löytänyt mainittua upstarttia. Nyt kyllä löysin sen sieltä. Silmäni saattoivat hyvinkin pettää tässä vireystilassa. Virheilmoituksia alkoi alun perin sadella siinä kohtaa, kun koitin tallennella GIMPillä tekemiä juttuja (ulkoiselle kovalevylle tosin, välimuisti oli toki siihen sitten ihan tukossa).

Jos kyseessä on tosiaan bugi, niin se vähän selventää asiaa, muttei tuossa varmaan ole silloin paljoa itse tehtävissä. Vaikkakin näemmä korjaantuu itsestään. No, pitänee muistaa komentaa tuo listaus, jos toistuu.

[nm]

Jos kyseessä on tosiaan bugi, niin se vähän selventää asiaa, muttei tuossa varmaan ole silloin paljoa itse tehtävissä. Vaikkakin näemmä korjaantuu itsestään. No, pitänee muistaa komentaa tuo listaus, jos toistuu.

Upstartin bugi on, ettei se rajoita lokitiedostojen kokoa. Upstart ei kuitenkaan ole tässä ainoa syyllinen, vaan joku muu ohjelma tai palvelu on jäänyt jumiin ja kirjoittanut pitkäkestoisessa silmukassa virheilmoituksia tai muita lokiviestejä. Jos ongelma toistuu, kannattaa katsoa, minkä niminen tiedosto kasvaa, ja millaista tekstiä se sisältää. Lokin sisällön perusteella on sitten ehkä mahdollista selvittää varsinainen ongelma, joka tilanteen aiheuttaa.

Isoa monen gigan lokitiedostoa ei sitten voi avata suoraan tavalliseen tekstieditoriin. Siitä kannattaa pätkäistä loppuosa tarkasteltavaksi tail-komennolla. Esimerkiksi viimeiset 50 riviä:

Koodia: [Valitse]

tail -50 .cache/upstart/dbus.log > dbus-loppu.txt

[Postimies]

tmpwatch voi auttaa pitämään kansion koon järkevässä koossa. tail komenossa olen aina käyttänyt
tail -n100 tiedosto. Onnistuu näköjään ilman sitäkin - yksi turha n kirjoitettu ties kuinka monesti.

[nm]

tail komenossa olen aina käyttänyt
tail -n100 tiedosto. Onnistuu näköjään ilman sitäkin - yksi turha n kirjoitettu ties kuinka monesti.

Vanha syntaksi oli ilman n:ää. Nykyisin -n100 on oikeampi, POSIX-standardin mukainen parametri. Ei vain jaksa kirjoittaa sitä n:ää.