[Fedora] Postgresql database niet meer benaderbaar na reboot - Linux en overige clients

donderdag 26 juli 2007 11:48

Acties:

Topicstarter

Mensen, ik heb hier een groot probleem!

Ik heb hier een postgresql server draaien (versie 8.1 dacht ik) en die heeft altijd goed gedraaid. Tot ik een reboot moest geven! (wel nette reboot, geen stroomuitval).

de postgresql database start goed, maar als ik 1 van de 10 databases die erop draaien wil benaderen krijg ik de volgende foutmelding:

connection to database "sourcebox" failed: FATAL: could not access directory "pg_tblspc/17179/17516": Permission denied

Ik heb de permissions en rechten al nagekeken en dat staat allemaal goed. Ik weet echt niet meer wat er aan de hand is. Andere databases die op dezelfde server draaien zijn wel benaderbaar.

Zou het kunnen zijn dat deze database plots corrupt is geraakt? Ik kan ook geen database dump maken dmv pg_dump, die geeft dezelfde foutmelding terug.

Kan iemand mij helpen? Deze productie server kan niet al te lang down blijven...

donderdag 26 juli 2007 11:54

Acties:

Verwijderd

Mishmash schreef op donderdag 26 juli 2007 @ 11:48:
de postgresql database start goed, maar als ik 1 van de 10 databases die erop draaien wil benaderen krijg ik de volgende foutmelding:
connection to database "sourcebox" failed: FATAL: could not access directory "pg_tblspc/17179/17516": Permission denied

Ik heb de permissions en rechten al nagekeken en dat staat allemaal goed. Ik weet echt niet meer wat er aan de hand is. Andere databases die op dezelfde server draaien zijn wel benaderbaar.

Weet je dat heel zeker? Zijn de bestanden ook van dezelfde user? Als bijv alle bestanden postgres.nobody 750 zijn, en deze root.root 750, dan werkt het natuurlijk niet.
Controleer ook je ACL even met getfacl -R ., wie weet zijn het wel verborgen permissies.

Zou het kunnen zijn dat deze database plots corrupt is geraakt?

Ik geloof er geen bal van, dan zou je deze melding niet krijgen, maar een "data corruption error" of iets wat ongeveer zo klinkt.

En als dit nog niets oplost, probeer de database server dan eens te stracen.
• Login op je database server met psql
• Met netstat -pan (als root!) spoor je op welke fork er verbonden is
• Met strace -f -p [pid] trace je de server
• \c databasename
• Controleer de strace output

donderdag 26 juli 2007 11:54

Acties:

ACM

Software Architect

Werkt hier

Als er iets corrupt is, lijkt het me eerder je filesystem dan de database zelf... Postgresql geeft daar andere foutmeldingen over.
Maar blijkbaar heb je een aparte table space gebruikt voor die ene database, is het onderliggende filesystem wel gemount?

[ Voor 10% gewijzigd door ACM op 26-07-2007 11:55 ]

donderdag 26 juli 2007 11:56

Acties:

Verwijderd

En check even of je database server zelf nog wel met de juiste rechten draait. Als hij vorige keer gestart is als root, en nu als postgres, is het te verklaren.

Je kan natuurlijk ook nu JUIST de db server eens als root draaien, kijken wat ie doet. Maar doe dat niet te lang, als dan je db server gecompromised wordt, dan is je hele server compromised.

donderdag 26 juli 2007 11:59

Acties:

ACM

Software Architect

Werkt hier

Verwijderd schreef op donderdag 26 juli 2007 @ 11:56:
En check even of je database server zelf nog wel met de juiste rechten draait. Als hij vorige keer gestart is als root, en nu als postgres, is het te verklaren.

Je kan natuurlijk ook nu JUIST de db server eens als root draaien, kijken wat ie doet. Maar doe dat niet te lang, als dan je db server gecompromised wordt, dan is je hele server compromised.

postgresql accepteerd het niet om met root te draaien. Dan geeft ie een error en stopt ie ermee, dus dat lijkt me niet zo'n relevant punt

donderdag 26 juli 2007 12:01

Acties:

Mishmash

Topicstarter

Alles is netjes gemount, ik kwam er wel net achter dat meerdere databases niet benaderbaar zijn (3 van de 10 niet).

Hieronder de output van strace:

code:

[root@tk51 ~]# strace -f -p 4432
Process 4432 attached - interrupt to quit
read(0, "\\", 1)                        = 1
write(1, "\\", 1)                       = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, "c", 1)                         = 1
write(1, "c", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, " ", 1)                         = 1
write(1, " ", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, "s", 1)                         = 1
write(1, "s", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, "o", 1)                         = 1
write(1, "o", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, "u", 1)                         = 1
write(1, "u", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, "r", 1)                         = 1
write(1, "r", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, "e", 1)                         = 1
write(1, "e", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, "\177", 1)                      = 1
write(1, "\10\33[K", 4)                 = 4
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, "c", 1)                         = 1
write(1, "c", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, "e", 1)                         = 1
write(1, "e", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, "b", 1)                         = 1
write(1, "b", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, "o", 1)                         = 1
write(1, "o", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, "x", 1)                         = 1
write(1, "x", 1)                        = 1
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0, "\r", 1)                        = 1
write(1, "\n", 1)                       = 1
rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGINT, {0x804e130, [], SA_RESTART}, {0x4e44ca30, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {SIG_DFL}, {0x4e44ca30, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, {0x4e44ca30, [], 0}, 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, {0x4e44ca30, [], 0}, 8) = 0
rt_sigaction(SIGTSTP, {SIG_DFL}, {0x4e44ca30, [], 0}, 8) = 0
rt_sigaction(SIGTTOU, {SIG_DFL}, {0x4e44ca30, [], 0}, 8) = 0
rt_sigaction(SIGTTIN, {SIG_DFL}, {0x4e44ca30, [], 0}, 8) = 0
rt_sigaction(SIGWINCH, {SIG_DFL}, {0x4e44c9e0, [], SA_RESTART}, 8) = 0
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
stat64("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=657, ...}) = 0
open("/etc/krb5.conf", O_RDONLY|O_LARGEFILE) = 4
access("/etc/krb5.conf", W_OK)          = -1 EACCES (Permission denied)
brk(0x8284000)                          = 0x8284000
fstat64(4, {st_mode=S_IFREG|0644, st_size=657, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7cb8000
read(4, "[logging]\n default = FILE:/var/l"..., 4096) = 657
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0xb7cb8000, 4096)                = 0
access("/etc/krb5.conf", R_OK)          = 0
time(NULL)                              = 1185443984
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFCHR|0444, st_rdev=makedev(1, 9), ...}) = 0
read(4, "\3119\312^>h\327\373\314\v\2229Q\333R\360G6{U", 20) = 20
close(4)                                = 0
gettimeofday({1185443984, 323343}, NULL) = 0
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
time(NULL)                              = 1185443984
getuid32()                              = 1007
open("/tmp/krb5cc_1007", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
geteuid32()                             = 1007
geteuid32()                             = 1007
stat64("/usr/local/pgsql/data/.pgpass", 0xbf9a2798) = -1 ENOENT (No such file or directory)
socket(PF_FILE, SOCK_STREAM, 0)         = 4
fcntl64(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC)         = 0
connect(4, {sa_family=AF_FILE, path="/tmp/.s.PGSQL.5432"}, 110) = 0
getsockopt(4, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
getsockname(4, {sa_family=AF_FILE, path=@}, [2]) = 0
poll([{fd=4, events=POLLOUT|POLLERR, revents=POLLOUT}], 1, -1) = 1
rt_sigprocmask(SIG_BLOCK, [PIPE], [], 8) = 0
send(4, "\0\0\0*\0\3\0\0user\0postgres\0database\0s"..., 42, 0) = 42
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
poll([{fd=4, events=POLLIN|POLLERR, revents=POLLIN}], 1, -1) = 1
recv(4, "R\0\0\0\10\0\0\0\0E\0\0\0ySFATAL\0C42501\0Mcou"..., 16384, 0) = 131
write(2, "FATAL:  could not access directo"..., 78) = 78
close(4)                                = 0
write(2, "Previous connection kept\n", 25) = 25
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGINT, {0x804e130, [], SA_RESTART}, {0x804e130, [], SA_RESTART}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
ioctl(0, TIOCGWINSZ, {ws_row=54, ws_col=157, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(0, TIOCSWINSZ, {ws_row=54, ws_col=157, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGINT, {0x4e44ca30, [], 0}, {0x804e130, [], SA_RESTART}, 8) = 0
rt_sigaction(SIGTERM, {0x4e44ca30, [], 0}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {0x4e44ca30, [], 0}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGALRM, {0x4e44ca30, [], 0}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTSTP, {0x4e44ca30, [], 0}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTTOU, {0x4e44ca30, [], 0}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTTIN, {0x4e44ca30, [], 0}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGWINCH, {0x4e44c9e0, [], SA_RESTART}, {SIG_DFL}, 8) = 0
write(1, "postgres=# ", 11)             = 11
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
read(0,

Ik word hier geen wijs uit, iemand anders wel?

PS: Postgresql server draait netjes onder de user postgres, en die user is ook de eigenaar van alle database directories.

donderdag 26 juli 2007 12:05

Acties:

Verwijderd

ACM schreef op donderdag 26 juli 2007 @ 11:59:
[...]

postgresql accepteerd het niet om met root te draaien. Dan geeft ie een error en stopt ie ermee, dus dat lijkt me niet zo'n relevant punt

errr.... ohwja.
met mysql had ik die truuk een keer gehad. mysqlserver init als root gedaan, daarna kreeg /etc/rc.d/rc.mysql (slack) 'm niet meer gestart. Maar hier idd niet van toepassing.

donderdag 26 juli 2007 12:18

Acties:

Mishmash

Topicstarter

Is het mogelijk om de complete inhoud van de directory waar de database in staat te kopieeren naar een andere locatie, vervolgens de database te verwijderen en opnieuw aanmaken en vervolgens alles weer terug plaatsen? Gaat dat werken of niet?

donderdag 26 juli 2007 12:23

Acties:

Verwijderd

Mishmash schreef op donderdag 26 juli 2007 @ 12:18:
Is het mogelijk om de complete inhoud van de directory waar de database in staat te kopieeren naar een andere locatie, vervolgens de database te verwijderen en opnieuw aanmaken en vervolgens alles weer terug plaatsen? Gaat dat werken of niet?

zou ik niet doen
wat je wel kan doen:

code:

1
2
3

cd datadir
mkdir /nieuwedatadir
tar -cf - . | tar -C /nieuwedatadir -xf -

en vervolgens de postgres server starten met
sudo -u postgres pg_ctl start -D nieuwedatadir

bedenk wel dat je eventuele acls en user_xattr's kwijtraakt. normaal heb je die niet, maar ik weet niet wat je hebt zitten vogelen met je server.

Werkt het dan wel, dan zit het niet in de data, maar in het filesystem/het os/het onderliggende systeem. Maar dan nog zou ik wel terug gaan naar de originele data dir.

Wil je toch perse kopieren en de nieuwe dir in productie zetten, zorg dan dat tijdens het kopieren je postmaster server UIT STAAT!

donderdag 26 juli 2007 12:26

Acties:

ACM

Software Architect

Werkt hier

Had je trouwens al in je postgresql.log gekeken om te zien wat voor meldingen daar staan? En is die directory niet een symlink in die pg_tblspc-dir, zoja, is de target van de symlink er nog?

[ Voor 36% gewijzigd door ACM op 26-07-2007 12:27 ]

donderdag 26 juli 2007 12:34

Acties:

Verwijderd

doe eens ls -aslR in de data dir
en dan de output hier graag :-)

[ Voor 13% gewijzigd door Verwijderd op 26-07-2007 12:34 ]

donderdag 26 juli 2007 12:37

Acties:

Mishmash

Topicstarter

Ok, ik heb het werkend! welliswaar anders dan voorheen, maar voor nu werkt het iig.

Wat ik heb gedaan:
/var/lib/pgsql/data/pg_tblspc/17179 (de database waar het om ging) stond gesymlinkt naar /projects/pgsql/sourcebox

Blijkbaar waren daar wat rechten fouten, ik heb nu namelijk die symlink verwijderd, de data uit /projects/pgsql/sourcebox gecopieerd naar de map 17179, rechten opnieuw ingesteld en postgresql weer gestart. Nu kan ik er dus wel bij!

Nu alleen nog kijken hoe het zit met de andere databases...

donderdag 26 juli 2007 14:33

Acties:

Mishmash

Topicstarter

Ik kom er net achter dat user postgres niet eens in de /etc/passwd lijst staat... Hier horen toch alle gebruikers in te staan?

als ik een ls -aslR in de map /projects/pgsql doe (waar alle databases staan) zie ik dat elk bestand van de user postgres is en group ook postgres. Alleen de user postgres mag hier niet meer bij! (access denied). Een chown postgres:postgres -R /projects/pgsql werkt niet... Is er een andere manier waardoor ik de user postgres weer toegang kan geven tot de pgsql directory?

Goed, ik heb eindelijk weer alles werkend... Ik heb er nu voor gezorgt dat alle databases gewoon in /var/lib/pgsql/data/pg_tblspc staan en symbolic links gemaakt naar /projects/pgsql/naamvddatabase. Rechten opnieuw toegekent en draaien maar! Nu staat het iig zoals het hoort te staan.

Bedankt voor ieder z'n hulp!

[ Voor 83% gewijzigd door Mishmash op 26-07-2007 15:13 ]

donderdag 26 juli 2007 16:04

Acties:

ACM

Software Architect

Werkt hier

Mishmash schreef op donderdag 26 juli 2007 @ 12:37:
Blijkbaar waren daar wat rechten fouten, ik heb nu namelijk die symlink verwijderd, de data uit /projects/pgsql/sourcebox gecopieerd naar de map 17179, rechten opnieuw ingesteld en postgresql weer gestart. Nu kan ik er dus wel bij!

En nu heeft het geen voordeel meer om een losse tablespace te hebben voor die database... had dat uberhaupt een reden??

Mishmash schreef op donderdag 26 juli 2007 @ 14:33:
Ik kom er net achter dat user postgres niet eens in de /etc/passwd lijst staat... Hier horen toch alle gebruikers in te staan?

Dat is wel gebruikelijk ja...

als ik een ls -aslR in de map /projects/pgsql doe (waar alle databases staan) zie ik dat elk bestand van de user postgres is en group ook postgres. Alleen de user postgres mag hier niet meer bij! (access denied). Een chown postgres:postgres -R /projects/pgsql werkt niet... Is er een andere manier waardoor ik de user postgres weer toegang kan geven tot de pgsql directory?

Dat hoort ie te hebben, mits de access rights goed staan (lees en execute rechten enzo)

Rechten opnieuw toegekent en draaien maar! Nu staat het iig zoals het hoort te staan.

Nee, nu heb je losse tablespaces per database oid en vervolgens die tablespaces op dezelfde plek... Dan had je beter gewoon helemaal geen losse tablespaces kunnen nemen

donderdag 26 juli 2007 17:11

Acties:

Mishmash

Topicstarter

ok even een stapje terug, wat zijn tablespaces?

Ik kreeg ook net van mijn baas te horen waarom de vorige systeembeheerder het zo gedaan had. Het is namelijk de bedoeling dat de databases in /projects komen te staan, dit is namelijk een andere partitie! (nooit op gelet...) Kan ik binnenkort alles weer terug gaan zetten!

Pagina: 1

Reageer