So what's in the system log and/or postgresql log?

Mar  6 10:58:15 dhcp-24-224 pg_ctl[4766]: postgres cannot access the server configuration file "/var/lib/pgsql/data/postgresql.conf": No such file or directory


How to test:

have a clean rhel7 minimal install
yum install -y postgresql-server
service postgresql initdb
service postgresql {start,status,stop}

This works on rhel6, whereas on rhel7 it doesn't.

"service postgresql initdb" doesn't work anymore under systemd.  That's a systemd shortcoming, not much  I can do about it ... but it'd be nice if they at least told you it wasn't doing anything.

It does:

$ service messagebus frobozz
Redirecting to /bin/systemctl  frobozz messagebus.service
Unknown operation frobozz

This seems to be NOTABUG?

What about initializing the database during the first service run?

(In reply to comment #5)
> What about initializing the database during the first service run?

No.  It's dangerous.  The separate action for initdb is an upstream recommendation that I don't intend to break.

After poking at this some more, I found out that systemd's "service" command will redirect nonstandard commands to an init script without complaint.  I'm just about certain that that did not work six months ago when we decided we needed to invent postgresql-setup.  But it seems to work OK now in F16 and up, which means we can fix this by resurrecting the postgresql rc.d file.  I'm still going to only document the usage of postgresql-setup, but for anybody with "service postgresql initdb" wired into their fingertips, it'll continue to work like it did before.

That sounds like a good message for anybody with "service postgresql initdb" wired into their fingertips and for me too. But I'm not sure if you are allowed to have the rc.d file in a single package along with the systemd unit:

http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files

(In reply to comment #8)
> http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files

I think that guideline applies to non-stub initscripts.  Of course, if you'd rather I closed this NOTABUG, then we don't need it.

(In reply to comment #7)
> I'm still going to only document the usage of postgresql-setup, but for
> anybody with "service postgresql initdb" wired into their fingertips, it'll
> continue to work like it did before.

thinking about it ... is it too late to throw away this postgresql-setup if the old way works?

- why to introduce this ugly hack to workaround (now) non-existant problem?

(In reply to comment #10)
> (In reply to comment #7)
> > I'm still going to only document the usage of postgresql-setup, but for
> > anybody with "service postgresql initdb" wired into their fingertips, it'll
> > continue to work like it did before.
> 
> thinking about it ... is it too late to throw away this postgresql-setup if the
> old way works?

postgresql-setup is the wave of the future.  I don't imagine that we'll keep the stub service file around forever, or for that matter that systemd is going to keep the "service" command around forever.  I see this as just a stopgap measure to provide some temporary backward compatibility until people get used to the new way.  (In view of comment #8, I may get forced to drop the stub script anyway, so I'm certainly not going to make it the only way to do things.)

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #7)
> > > I'm still going to only document the usage of postgresql-setup, but for
> > > anybody with "service postgresql initdb" wired into their fingertips, it'll
> > > continue to work like it did before.
> > 
> > thinking about it ... is it too late to throw away this postgresql-setup if the
> > old way works?
> 
> postgresql-setup is the wave of the future.  I don't imagine that we'll keep
> the stub service file around forever, or for that matter that systemd is going
> to keep the "service" command around forever.  I see this as just a stopgap
> measure to provide some temporary backward compatibility until people get used
> to the new way.  (In view of comment #8, I may get forced to drop the stub
> script anyway, so I'm certainly not going to make it the only way to do
> things.)

well, seems I completely misunderstood the point of comment #7, sorry

so, in the bright future, instead of telling to a service what you want to do with it (possibly asking it which actions does it support), one will have to start (and then what, stop?) a separate service per each action, trying to guess the right name from a list of all available^W known units?

could we at least keep the unit names consistent with the original actions, i.e. postgresql-initdb instead of postgresql-setup, or is there a reason to break every single bit of similarity to previous version?

and btw, as some kind of setup needed before the first run is quite a common thing, wouldn't that be possible to add such command to those chosen to be supported, instead of having zillions of new units created to be run once and then just take up space in the listings? (in that case I wouldn't insist on calling the command "initdb" :-))

(In reply to comment #14)
> so, in the bright future, instead of telling to a service what you want to do
> with it (possibly asking it which actions does it support), one will have to
> start (and then what, stop?) a separate service per each action, trying to
> guess the right name from a list of all available^W known units?

Well, you're complaining to the wrong person.  It was not my decision that systemd should not offer any equivalent to the nonstandard actions that were possible in SysV scripts.  If you want to file a bug about that, systemd is the component to complain to.  (But I think they've heard it before.)

> could we at least keep the unit names consistent with the original actions,
> i.e. postgresql-initdb instead of postgresql-setup, or is there a reason to
> break every single bit of similarity to previous version?

You're about six months too late to be quibbling with the naming choices; that script shipped in F-16 and I'm not going to revisit its API now.  In any case, yes there is a reason not to call it postgresql-initdb: initdb is not the only action it has.

(In reply to comment #15)
> (In reply to comment #14)
> > so, in the bright future, instead of telling to a service what you want to do
> > with it (possibly asking it which actions does it support), one will have to
> > start (and then what, stop?) a separate service per each action, trying to
> > guess the right name from a list of all available^W known units?
> 
> Well, you're complaining to the wrong person.  It was not my decision that
> systemd should not offer any equivalent to the nonstandard actions that were
> possible in SysV scripts.  If you want to file a bug about that, systemd is the
> component to complain to.  (But I think they've heard it before.)

I don't think that such report from an user POV would draw any attention - we will just add another "case version in ..." workaround into our tests; it is our job, if the company wants us to waste our time on updating for new versions incompatibilities then we'll do what we are paid for

if the design wasn't such big obstacle for you, from the developer POV, to try to change it ... then just let the _customers_ to complain

...
> You're about six months too late to be quibbling with the naming choices; that
> script shipped in F-16 and I'm not going to revisit its API now.

if only we had the opportunity to run our testsuite in Beaker on that code those six months ago ...

hm, this sounds familiar ... http://home.comcast.net/~tomhorsley/game/rules-change.html

> In any case, yes there is a reason not to call it postgresql-initdb: initdb is
> not the only action it has.

ok, makes sense

I tried to deal with this complaint by adding a stub initscript in postgresql-9.1.3-2, but in view of the fedora-packaging thread starting at
http://lists.fedoraproject.org/pipermail/packaging/2012-April/008314.html
I am going to have to take it out again.  Sorry.

(In reply to comment #17)
> I tried to deal with this complaint by adding a stub initscript in
> postgresql-9.1.3-2, but in view of the fedora-packaging thread starting at
> http://lists.fedoraproject.org/pipermail/packaging/2012-April/008314.html
> I am going to have to take it out again.  Sorry.

thanks for your efforts

just a note to that thread ... it is not a matter of "users not reading the release notes", rather there is a problem that you have to do a "change for a change", spend a lot of man-hours rewriting the code which was supposed to work "forever" - simply reading the release notes won't fix all the broken things, as demonstrated by this bug, there are zillions of scripts relying on the fact that "service name action" will do the job which is no longer true (for some of the actions)

the "service" command was supposed to act as a wrapper, no matter if the backend init system is SysV, OpenRC, Upstart or whatever ... and it has worked ... until systemd

consider railways - we had horses, steam engines, we have diesel and electric engines now, but still they use the standard Stephenson gauge, you can pull out the steam locomotive out of the museum and do a historic ride ... now someone comes and says "from now on, Scotch gauge is the one and only that fits them all, you can only buy locomotives and cars in 54 inch variant, now go rebuild all your obsolete tracks and scrap all those old vehicles at your expense!" - sounds absurd? - yet the same principle is praised in case of systemd

Well, per the discussion at
http://lists.fedoraproject.org/pipermail/devel/2012-June/169411.html
there is now an approved way to support "legacy" initscript actions after all, so I've pushed support for that into rawhide.