Thread: System Logs filling up with gunk
Rick Saunders (ozzzy@yknet.yk.ca) reports a bug with a severity of 3 The lower the number the more severe it is. Short Description System Logs filling up with gunk Long Description I'm running PG 6.5.3 on RedHat 6.0 with a 2.2.17 kernel: My /var/log/messages is filling up with the following..... Jun 3 04:06:23 ozzzy PAM_pwdb[5766]: (su) session opened for user postgres by (uid=0) Jun 3 04:06:23 ozzzy PAM_pwdb[5766]: (su) session closed for user postgres Jun 3 04:06:23 ozzzy init: Id "pg" respawning too fast: disabled for 5 minutes The database system appears to run perfectly... but the logfiles are REALLY hard to dig through... any ideas? fixes? consolation? Rgds, Rick Sample Code No file was uploaded with this report
> I'm running PG 6.5.3 on RedHat 6.0 with a 2.2.17 kernel: > My /var/log/messages is filling up with the following..... > > Jun 3 04:06:23 ozzzy PAM_pwdb[5766]: (su) session opened for user postgres by (uid=0) > Jun 3 04:06:23 ozzzy PAM_pwdb[5766]: (su) session closed for user postgres > Jun 3 04:06:23 ozzzy init: Id "pg" respawning too fast: disabled for 5 minutes It's not a good idea to launch the postmaster through init(tab). Instead you could add it to /etc/rc.d/rc.local, or wire it into the runlevel startups. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut <peter_e@gmx.net> writes: >> I'm running PG 6.5.3 on RedHat 6.0 with a 2.2.17 kernel: >> My /var/log/messages is filling up with the following..... >> >> Jun 3 04:06:23 ozzzy PAM_pwdb[5766]: (su) session opened for user postgres by (uid=0) >> Jun 3 04:06:23 ozzzy PAM_pwdb[5766]: (su) session closed for user postgres >> Jun 3 04:06:23 ozzzy init: Id "pg" respawning too fast: disabled for 5 minutes > It's not a good idea to launch the postmaster through init(tab). But it should *work*, though. All we can guess from the above is that inittab is trying to start postgres via "su postgres ...", and that that script is failing. No info here as to why ... but it'd likely still fail if invoked from someplace else. regards, tom lane