This now very much looks to be the case, with your report. My instance of postgres user’s ‘.bash_profile’ appears to date from June 2018:
-rw-r----- 1 postgres postgres 192 Jun 9 2018 .bash_profile
So I’m guessing it was a post install script of an earlier postgresql-server rpm or the like that generated it. It is not owned by any current package. And once in place was, via policy for such things, left as was. Nice to know anyway.
Lets move to conclude this then.
Given the current case is that we can’t depend on this PGDATA environmental variable being set for us any longer and my prior code looks to have assumed it’s existence we do as you and the error message suggests and explicitly set our db data dir via the -D option to our pg_data python var which previously shadowed the same env var anyway.
Note worthy is that our related CentOS executions are also apparently relying on the same PGDATA env var but have as yet not run into this issue. But for the initialisation we have thus far used the RedHat specific script. But we should concentrate on the openSUSE side really, ie from a CentOS based Rockstor install we have:
cat /var/lib/pgsql/.bash_profile
[ -f /etc/profile ] && source /etc/profile
PGDATA=/var/lib/pgsql/data
export PGDATA
Upon another look your prior correction to:
Looks to have the -D option in the wrong place as it’s an option to be passed to initdb not the login environment su:
where as the ‘su -’ is shorthand for switch user with login environment of that user; see man su:
-, -l, --login
Start the shell as a login shell with an environment similar to a real login:
I did the following to pass the -D option to initdb:
['su', '-', 'postgres', '-c', '/usr/bin/initdb -D {}'.format(pg_data)])
which may not be the most elegant but worked for me and seems to read OK: i.e. we are passing a single command string via the —command (-c) option on su.
Since you diagnosed that -D thingy do you fancy making an issue / pr and we can then link to it from our openSUSE build wiki? I’ve also recently updated the wiki with some of our other more recent findings, ie to install postgresql10 etc.
Yes, but also note the following:
su - postgres
-bash: /usr/share/postgresql/bash_profile: Permission denied
So although it no longer sets up our PGDATA it also doesn’t even get run!
So looks like they may have something a miss there but with the -D explicit fix we can work ‘as is’ which is convenient. Would be nice to report upstream but not sure where currently as still getting to grips with backlog and haven’t put the time into familiarity with the openSUSE bug reporting.
@jcdick1 & @Flox I’ve just re-run the wiki instructions, post changes, and I think we are good; as long as the indicated issues are observed, ie:
- Recent pg_config ‘in path’ fix via alternative step (note posttresql10 pkg variants).
- This recent -D switch thing detailed above.
- The recent Docker json rename detailed in #2032 (though not build related).
Proved today with fresh install of 20190425 Tumbleweed snapshot.
@jcdick1 Would you mind changing this forum’s title to indicate it’s relevance to Tumbleweed as that has become it’s main focus, given our mutual aims here.
Hope that helps.