Automatic postgesql start fails
Hello, since yesterday a new problem on my Crux Linux machine has occured: The automatic start of postgresql during boot fails. The following line can be found in the log: Feb 19 11:50:17 Darksun postgresql: su: Cannot drop the controlling terminal When I start posgresql manually after boot it works fine. All ports are up to date. Has anyone an idea of how to fix this? Regards Markus
On Sun, Feb 19, 2012 at 12:05:31PM +0100, Markus Heinz wrote:
Hello,
Hello Markus,
since yesterday a new problem on my Crux Linux machine has occured: The automatic start of postgresql during boot fails. The following line can be found in the log:
Feb 19 11:50:17 Darksun postgresql: su: Cannot drop the controlling terminal
When I start posgresql manually after boot it works fine.
All ports are up to date. Has anyone an idea of how to fix this?
thanks for your report, it's a regression in "su" introduced by shadow 4.1.5. I saw the same issue with the start-script of opt/php-fcgi. Sorry, no fix for it right now, but I've reported the bug upstream. For now I'd suggest to use su from coreutils, which is build but not installed with core/coreutils. You can get the binary after a 'pkgmk -f -kw' of coreutils in your $PKGMK_WORK_DIR. HTH and best regards Juergen
Hello, On Sun, 19 Feb 2012 13:02:16 +0100 Juergen Daubert <jue@jue.li> wrote:
On Sun, Feb 19, 2012 at 12:05:31PM +0100, Markus Heinz wrote:
Hello,
Hello Markus,
since yesterday a new problem on my Crux Linux machine has occured: The automatic start of postgresql during boot fails. The following line can be found in the log:
Feb 19 11:50:17 Darksun postgresql: su: Cannot drop the controlling terminal
When I start posgresql manually after boot it works fine.
All ports are up to date. Has anyone an idea of how to fix this?
thanks for your report, it's a regression in "su" introduced by shadow 4.1.5. I saw the same issue with the start-script of opt/php-fcgi.
Sorry, no fix for it right now, but I've reported the bug upstream. For now I'd suggest to use su from coreutils, which is build but not installed with core/coreutils. You can get the binary after a 'pkgmk -f -kw' of coreutils in your $PKGMK_WORK_DIR.
The described workaround works for me. Thanks a lot.
HTH and best regards Juergen
Best regards Markus
participants (2)
-
Juergen Daubert -
Markus Heinz