Stringa repo, raso kad vietos mazai

[kestas05]

No description provided.

[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
#54 (comment)
.

[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
#54 (comment)
.

[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