Bug 730326

Looks like systemd broke it.

Frederic, wasn't it said, that normal start/stop scripts don't need to be touched when transiting to systemd.

Looking into this again, it looks like it wasn't systemd that broke it, but by default it hides the real reason for the failed startup by omiting the init script's stderr output.

Di, please run the init script with an additional argument (content doesn't matter, e.g. "rcpostgresql start x"), so that stderr output gets shown.

I've postgresql 9.1.1 running under factory from month and I can assure you that it work.

Now perhaps the first start is special, which is the initialization phase.

You can bypass systemd by doing to /etc/init.d/
and then 
./postgresql start 

also go and check in /var/lib/pgsql/ + data any logs which can give you a clue about the failed start status

you can also use SYSTEMD_NO_WRAP=1 rcpostgresql start

                       
/root # rcpostgresql start x
Initializing the PostgreSQL database at location /home/postgres/datainstall: cannot create directory `/home/postgres': Permission denied                                                                            

.....ah, we have nfs mounted home dirs ... don't many people have that ? Ok may be not on their dedicated DB servers.   



  7 # In which directory should the PostgreSQL database reside?
  8 #
  9 ##POSTGRES_DATADIR="~postgres/data"
 10 POSTGRES_DATADIR="/var/lib/pgsql/data"
       

may be this is a better default location for the db?

(In reply to comment #5)
> .....ah, we have nfs mounted home dirs ... don't many people have that ?

Yes, for human users, but not for system users like postgres.

>   9 ##POSTGRES_DATADIR="~postgres/data"
>  10 POSTGRES_DATADIR="/var/lib/pgsql/data"
> 
> may be this is a better default location for the db?

Well, that is the default location already, because /var/lib/pgsql is the default home dir of the postgres user.

(In reply to comment #3)

> You can bypass systemd by doing to /etc/init.d/
> and then 
> ./postgresql start 
> 
> also go and check in /var/lib/pgsql/ + data any logs which can give you a clue
> about the failed start status

I am also having problems starting PostgreSQL-Server

The approach mentioned here doesn't work for me:

extensa5230e:/etc/init.d # ./postgresql start
redirecting to systemctl
Starting PostgreSQL 9.1.7 pg_ctl: konnte Server nicht starten
Prüfen Sie die Logausgabe.

(In reply to comment #7)

> Prüfen Sie die Logausgabe.

Did you do that?

This is what /var/log/messages tells me:

Jan 29 13:11:36 extensa5230e su: (to root) mwagner on /dev/pts/1
Jan 29 13:11:36 extensa5230e su: pam_apparmor(su:session): Unknown error occurred changing to root hat: Die Operation ist nicht erlaubt
Jan 29 13:11:37 extensa5230e su: (to postgres) mwagner on /dev/pts/1
Jan 29 13:11:37 extensa5230e su: pam_apparmor(su-l:session): Unknown error occurred changing to postgres hat: Operation not permitted
Jan 29 13:11:37 extensa5230e su: (to postgres) mwagner on /dev/pts/1
Jan 29 13:11:37 extensa5230e su: pam_apparmor(su-l:session): Unknown error occurred changing to postgres hat: Operation not permitted
Jan 29 13:12:51 extensa5230e dhclient[1417]: DHCPREQUEST on wlan0 to 192.168.44.1 port 67
Jan 29 13:12:51 extensa5230e dhclient[1417]: DHCPACK from 192.168.44.1
Jan 29 13:12:51 extensa5230e dhclient[1417]: bound to 192.168.44.163 -- renewal in 274 seconds.
Jan 29 13:15:44 extensa5230e su: (to root) mwagner on /dev/pts/1
Jan 29 13:15:44 extensa5230e su: pam_apparmor(su:session): Unknown error occurred changing to root hat: Die Operation ist nicht erlaubt

Please let me know if you need further information. Thanks.

Are we sure that apparmor has been adapted to the new postgresql layout ?

What I can confirm is postgresql91 & 92 work on 12.1, 12.2 and factory 12.3 without apparmor and keeping sane default like /var/lib/pgsql as home

Be aware also that if you increase memory allowed for postgresql you can be hurt by limits in kernel shm

What I use for example my pg instance with 2Gb of ram
kernel.shmmax = 8589934592
kernel.shmall = 549755813888
kernel.shmmni = 4096

placed in /etc/sysctl.d/sysctl.conf

But normally you get the message in syslog and postmaster.log

Thanks for the quick reply. I checked my postmaster.log and noticed it to be empty:

extensa5230e:/var/lib/pgsql/data # cat postmaster.log

I also had a look at the syslog but I suppose I am not doing it correctly:

extensa5230e:/etc/sysctl.d # cat /run/systemd/journal/syslog
cat: /run/systemd/journal/syslog: Kein passendes Gerät bzw. keine passende Adresse gefunden
extensa5230e:/etc/sysctl.d # less /run/systemd/journal/syslog
/run/systemd/journal/syslog is not a regular file (use -f to see it)
extensa5230e:/etc/sysctl.d # tail -f /run/systemd/journal/syslog 
tail: „/run/systemd/journal/syslog“ kann nicht zum Lesen geöffnet werden: Kein passendes Gerät bzw. keine passende Adresse gefunden

syslog means /var/log/messages .
Besides syslog and postmaster.log where only early startup problems get reported, PostgreSQL runtime log messages can also be found in timestamped files under /var/lib/pgsql/data/pg_log .

But before you do any further tests, please uninstall apparmor.

I just uninstalled apparmor. It doesn't show up in YaST anymore. I had a look into the Runlevel-Editor in Yast and noticed that the service is shown as running?: Yes* - I tried to get rid of the star by deactivating the service in Yast (which worked fine) and starting it up again (which resulted in error code 1).