Description of problem: When I install postgresql-server and start the service for the first time, it fail and it fails to provide any helpful information about remediation of the situation. Version-Release number of selected component (if applicable): postgresql-server-9.1.6-1.fc17.x86_64 How reproducible: Deterministic. Steps to Reproduce: 1. Run service postgresql start. Actual results: # service postgresql start Redirecting to /bin/systemctl start postgresql.service Job failed. See system journal and 'systemctl status' for details. # systemctl status postgresql.service postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled) Active: failed (Result: exit-code) since Tue, 23 Oct 2012 15:36:19 +0200; 4min 21s ago Process: 8109 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA} (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/postgresql.service Only grepping /var/log/messages reveals the reason: Oct 23 15:34:33 ditustat systemd[1]: postgresql.service: control process exited, code=exited status=1 Oct 23 15:34:33 ditustat systemd[1]: Unit postgresql.service entered failed state. Oct 23 15:36:19 ditustat postgresql-check-db-dir[8109]: "/var/lib/pgsql/data" is missing or empty. Oct 23 15:36:19 ditustat postgresql-check-db-dir[8109]: Use "postgresql-setup initdb" to initialize the database cluster. Oct 23 15:36:19 ditustat postgresql-check-db-dir[8109]: See /usr/share/doc/postgresql-9.1.6/README.rpm-dist for more information. Oct 23 15:36:19 ditustat systemd[1]: postgresql.service: control process exited, code=exited status=1 Expected results: In previous versions, the process would be like this: # service postgresql start /var/lib/pgsql/data is missing. Use "service postgresql initdb" to initialize the cluster first. [FAILED] I would expect something similar even under systemd, or for systemctl status to show the hint. Searching for clues in /var/log/messages is not admin friendly. Additional info:
This is really a systemd enhancement request: there is not (to my knowledge) any approved way for a daemon to provide any feedback to a manual service-start operation. I concur that there ought to be, but previous complaints about this haven't borne fruit. Reassigning to systemd to see what they say.
The messages are supposed to be shown in the output of systemctl status. If they aren't, it's due to a known race condition. The proper fix requires a new kernel feature. See the paragraph about SCM_CGROUPS in the Plumbers' wishlist: https://docs.google.com/document/pub?id=1RmJrtIoTnivkmR9KCqfJNBnEll4X9Jtu0xj5w6hFGs8 See also bug 820448 and bug 850556.
(In reply to comment #2) > The messages are supposed to be shown in the output of systemctl status. If > they aren't, it's due to a known race condition. The proper fix requires a > new kernel feature. What is the kernel bugzilla which tracks this? > See also bug 820448 and bug 850556. These are both bugzillas on the systemd component.
So, as a workaround until something is done about that, we could put a "sleep 2" or so in the scripts that emit these messages?
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Behaviour is still the same with systemd-204-9.fc19.x86_64 and postgresql-server-9.2.4-1.fc19.x86_64.
Closing.