Stringa repo, raso kad vietos mazai

[tkrilavicius]

ar čia nebus priloginta kalnai visko, ko nereikia? ar ten jau hdd užkišti?

[kestas05]

MArtynas ziuri jau

[marsav]

panašu kad taip ir yra

df

rootfs 118794524 112768472 0 100% /

root@repo:~# du -h / | grep '[0-9.]+G' 77G /var/log/postgresql 77G /var/log 77G /var ...

taigi postgress logai čia, jame prirašyta "connect: Bad file descriptor" eilučių begalės, reiktų troubleshootint toliau kas ten yra, bet laikinai galima juos tiesiog pratrinti

rm /var/log/postgresql/*

nors paskui matosi kad ir duomenų sekcijos užima po kelis Gb, šiuo metu visi jie sumoje užima 83 Gb

... 83G /mnt/data/duomenys ..

On 7 December 2015 at 21:25, tkrilavicius notifications@github.com wrote:

ar čia nebus priloginta kalnai visko, ko nereikia? ar ten jau hdd užkišti?

— Reply to this email directly or view it on GitHub https://github.com/marsav/lii-lindat-dspace/issues/54#issuecomment-162631994 .

[marsav]

pasirodo kažkoks užsilikęs procesas laikė ištrintus postgreso log failus. sutvarkyta, dabar disko užimtumas tik 18%

2015-12-07 21:43 GMT+02:00 Martynas Savickis martynas@ore.lt:

panašu kad taip ir yra

df

rootfs 118794524 112768472 0 100% /

root@repo:~# du -h / | grep '[0-9.]+G' 77G /var/log/postgresql 77G /var/log 77G /var ...

taigi postgress logai čia, jame prirašyta "connect: Bad file descriptor" eilučių begalės, reiktų troubleshootint toliau kas ten yra, bet laikinai galima juos tiesiog pratrinti

rm /var/log/postgresql/*

nors paskui matosi kad ir duomenų sekcijos užima po kelis Gb, šiuo metu visi jie sumoje užima 83 Gb

... 83G /mnt/data/duomenys ..

On 7 December 2015 at 21:25, tkrilavicius notifications@github.com wrote:

ar čia nebus priloginta kalnai visko, ko nereikia? ar ten jau hdd užkišti?

— Reply to this email directly or view it on GitHub https://github.com/marsav/lii-lindat-dspace/issues/54#issuecomment-162631994 .

[marsav]

fixed

[kestas05]

Vel tas pats su vieta. As postgress loga istryniau, man idomu koki tu procesa nukilinai kad vietos atsirado Plius, pabandziau postgresql perkraut, nu sustabde, bet nepaleidzia is naujo. Kazkas ne taip jei vel per diena dingo visas space'as

[marsav]

Ok, patroubleshootinau, panašu kad čia trojanas kuris per postgress portą įlindo, žr. čia: http://unix.stackexchange.com/a/248010

Taip ir buvo, kaip tame aprašyta - /tmp radau trojan kodą, o postgres funkcijose - exec111 funkciją (žr. žemiau). Pašalinau ir tuos ir tuos, bet galimybė kad trojaną vėl įstums jei nebus sustiprintas serverio saugumas, lieka. Pažiūrėsiu postgres konfigūraciją, ką ten galima padaryt. Kol kas turi veikt viskas, du down to 18%.

` postgres-# \df+ exec111 List of functions Schema | Name | Result data type | Argument data types | Type | Volatility | Owner | Language | Source code | Description --------+---------+------------------+---------------------+--------+------------+----------+----------+-------------+------------- public | exec111 | text | | normal | volatile | postgres | c | exec111 | (1 row)

postgres=# drop function exec111(); DROP FUNCTION `

Sustiprinau Postgres konfigūraciją, kad pasiektų tik dspace useris, pagal šitą instrukciją: http://comments.gmane.org/gmane.comp.db.dspace.user/25218

Tikėkimės, kad to pakaks. Jei problema kartosis, ieškosim kaip dar sustiprint.

Restartavau Postgres ir Tomcat, dabar veikia.

[marsav]

@kestas05 pažiūrėti kokie procesai laiko ištrintus failus, galima su šia komanda:

lsof | grep "/var" | grep deleted

Man ten matėsi postgres userio executintos komandos "testproxy" procesas su daug threadų, kurie laikė tą ištrintą logą. Tada nukilinau pagrindinį procesą, ir logas buvo atlaisvintas (kartu ir serverio vieta).

[marsav]

fixed