Hi,
I would like to add a file service in systemd for postgresql :
postgresql.service in /usr/lib/systemd/system
But it seems that systemctl ignores my file… In Fedora, it’s ok to add it and just run :
systemctl daemon-reload ???
Do I have to do something else ? I
Thanks !
We have no idea so far what you did, so how can we tell what else is needed? Show your unit file; explain what you did; explain what does not work.
Hi,
I didn’t think it was any useful to give the file content as it worked as it is on Debian Jessie and on Fedora 22. But here it is :
# This is the service file for systemd, place it in
# /usr/lib/systemd/system/postgresql.service
#
[Unit]
Description=The PostgreSql Server
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=simple
PIDFile=/var/run/$NAME.pid
Environment=NAME=postgresql
Environment=D=-D
Environment=L=-l
Environment=DATADIR=/media/databases/pg_datadir/data
Environment=LOGFILE=logfile
Environment=PIDF=/var/run/$NAME.pid
ExecStart=/usr/lib/postgresql/bin/pg_ctl $D $DATADIR $L $LOGFILE start
ExecStop=/usr/bin/kill $KILLLEVEL $(pidoff $NAME)
# Send SIGWINCH for graceful stop
KillSignal=SIGKILL
KillMode=process
PrivateTmp=true
[Install]
WantedBy=multi-user.target
What did I do ?
Well in those distributions, add the file to the directory mentioned above and run systemctl daemon-reload was sufficient to enable it. Except on Fedora, with SELinux enabled as enforced : this is what I was thinking about when I said ‘something else’.
I wanted to use : ‘aa-notify -p --display $DISPLAY’ to check if apparmor was the issue as I am not familiar with, but it doesn’t say anything either. I went to have a look in
Yast but Apparmor is already checked : so I don’t know if it is enabled by default or it’s just when I press the start button that it asks me if I want
to enabled it…
Anyway, PostgreSql starts from the command line ‘pg_ctl -D /media/databases/pg_datadir/data -l logfile start’ but the systemctl commands start/stop/restart are ignored.
Please feel free to ask any question I didn’t think to answer.
Thank you, 
That cannot work and I do not believe it works anywhere. systemd supports variable expansion in very limited cases and PIDFile is not one of them. It won’t fail, but it also does not do what you probably intended.
ExecStop=/usr/bin/kill $KILLLEVEL $(pidoff $NAME)
That cannot work either. systemd is not shell, it does not implement process substitution. Not is it even necessary as systemd can be configured to send custom signal to the right process without resorting to shell helpers.
and run systemctl daemon-reload was sufficient to enable it
Please; in systemd “enable” has very specific meaning and daemon-reload does not enable any unit. Be careful to use it correctly, otherwise your description will become very misleading.
but the systemctl commands start/stop/restart are ignored.
Please feel free to ask any question I didn’t think to answer.
Start with showing output of “systemctl status -l postgresql”.
And, BTW, do you mean there is not postgres in Leap? I do not believe it 
PIDFile=
Takes an absolute file name pointing to the PID file of this
daemon. Use of this option is recommended for services where Type=
is set to forking. systemd will read the PID of the main process of
the daemon after start-up of the service. systemd will not write to
the file configured here, although it will remove the file after
the service has shut down if it still exists.
I took it from the man page : http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=systemd.service
But I may misunderstood the purpose of that feature… And you’re right to say that if it was ignored, I surely didn’t notice a thing.
That cannot work either. systemd is not shell, it does not implement process substitution. Not is it even necessary as systemd can be configured to send custom signal to the right process without resorting to shell helpers.
ExecStop=
Commands to execute to stop the service started via ExecStart=.
This argument takes multiple command lines, following the same
scheme as described for ExecStart= above.
From the same man page, the command comes from the example in ExecReload. But if I’m wrong, please tell me why… Smell like a song no ?
Please; in systemd “enable” has very specific meaning and daemon-reload does not enable any unit. Be careful to use it correctly, otherwise your description will become very misleading.
My bad. I totally agree.
Start with showing output of “systemctl status -l postgresql”.
postgresql.service - The PostgreSql Server
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled)
Active: failed (Result: exit-code) since lun. 2016-02-01 19:01:57
CET; 13s ago
Process: 24197 ExecStop=/usr/bin/kill $KILLLEVEL $(pidoff $NAME)
(code=exited, status=1/FAILURE)
Process: 24191 ExecStart=/usr/lib/postgresql/bin/pg_ctl $D $DATADIR $L
$LOGFILE start (code=exited, status=1/FAILURE)
Main PID: 24191 (code=exited, status=1/FAILURE)
And, BTW, do you mean there is not postgres in Leap? I do not believe it
You mean that there should be a existing unit file for PostgreSql ? Maybe but I don’t have it on my system, and even if it were I still have to modify it because of my custom old (from previous installation) data directory.
Thanks,
Do you really intend to name file /var/run/$NAME.pid iterally? You understand that $NAME is not expanded, do not you?
From the same man page, the command comes from the example in ExecReload.
No. Example in ExecReload does not use process substitution.
postgresql.service - The PostgreSql Server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled) Active: failed (Result: exit-code) since lun. 2016-02-01 19:01:57 CET; 13s ago Process: 24197 ExecStop=/usr/bin/kill $KILLLEVEL $(pidoff $NAME) (code=exited, status=1/FAILURE) Process: 24191 ExecStart=/usr/lib/postgresql/bin/pg_ctl $D $DATADIR $L $LOGFILE start (code=exited, status=1/FAILURE) Main PID: 24191 (code=exited, status=1/FAILURE)
Are you sure that /usr/lib/postgres/bin/pg_ctl exists?
Actually no : as long as I defined it in the environment, should it not replace it ?
No. Example in ExecReload does not use process substitution.
I thought that accepting variable substitution implied that it would accept process substitution : I guess I was wrong… :shame:
Are you sure that /usr/lib/postgres/bin/pg_ctl exists?
That, I am. This command line run in the shell does start the PostgreSql server.
It’s not the command line you run in the shell - at least not, what you have shown.
Same line in the file :
/usr/lib/postgresql/bin/pg_ctl -D /media/databases/pg_datadir/data -l logfile start
So start with putting same line (without any variables) in unit file, fixing PIDFile name and removing PrivateTmp. If it still fails, show “systemctl status -l …” output and new unit definition again.
I fixed $NAME with ‘postgresql’, commented the PrivateTMP and it did fail again :
postgresql.service - The PostgreSql Server
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled)
Active: failed (Result: exit-code) since mar. 2016-02-02 12:54:48
CET; 11s ago
Process: 9109 ExecStop=/usr/bin/kill $KILLLEVEL $(pidoff $NAME)
(code=exited, status=1/FAILURE)
Process: 9104 ExecStart=/usr/lib/postgresql/bin/pg_ctl -D
/media/databases/pg_datadir/data -l logfile start (code=exited,
status=1/FAILURE)
Main PID: 9104 (code=exited, status=1/FAILURE)
I even tried to add the --user=postgres option too… Maybe systemd does not… It didn’t work either.
I tried to add : User=postgres instead -> no success
PIDFILE=/media/databases/pg_datadir/data/postmaster.pid -> no success
Environment=PGROOT=/media/databases/pg_datadir -> no success
Still searching…
Where does your postgres come from? Leap RPM installs it under /usr/lib/postgresql93/bin/pg_ctl
I have both : postgresql94 and postgresql and both don’t work…
This does not answer where this path comes from … run ExecStart under strace and upload result to susepaste.org (prefix you command line with /usr/bin/strace -f -o /tmp/postgres.log or whatever log name and location suits you).
Yes it does not… sorry. From the official repositories :
zypper in postgresql-server pgadmin3
: … run ExecStart under strace and upload result to susepaste.org (prefix you command line with /usr/bin/strace -f -o /tmp/postgres.log or whatever log name and location suits you).
I ran it first through postgresql.service : postgresql.log didn’t exist in /tmp, so I guess ExecStart is not run at all.
After, I ran this line in the shell :
/usr/bin/strace -f -o /tmp/postgres.log su - postgres -c '/usr/lib/postgresql/bin/pg_ctl -D /media/databases/pg_datadir/data -l logfile start'
You will find the result there : strace - Pastebin.com *
I forgot to add that it refused to authenticate me.
I just get that at each effective start, it says that a server seems to run : that is also false. Maybe the strace log can enlighten on this but I’m not sure what to look…
I’m pretty sure you should already have a postgresql service configured to go if you installed from the OSS.
I’d highly recommend
Undo everything you’ve done. All the Unit files you created.
Re-install any/all postresql you have installed. Maybe for simplicity you should only install one postresql and get it working before you try another. The following re-installs from the OSS(which currently installs postgresql94 by default), note you can also install “postgresql93 or postgresql94” packages.
zypper in -f postresql-server
After installed you can verify the existence of the postgresql unit file.
Note that standard openSUSE behavior is newly installed apps are not started or enabled by default.
systemctl status postgresql
Start the postgresql server
systemctl start postgresql
Enable the service to start automatically on boot
systemctl enable postgresql
Verify it’s running
systemctl status postgresql
Additional notes:
Both in other distros and here on openSUSE, you should never modify (add/remove/edit) a Unit file in /usr/lib/systemd/*
That path is only for default installed Unit files.
If you wish to create your own version of an existing or a new Unit file, you want to an existing Unit file to the following location. Any Unit files in the following location over-rides any in the default location. This allows you to undo anything you create without altering the original by simply deleting the file you created.
/etc/systemd/*
Additionally, the following is run only after modifying an existing Unit file, and will not “enable” to run as a service. All the command does is enable edits which have been made to existing Unit files.
systemctl daemon-reload
TSU
Actually I messed around with the security consolidation and enabled paranoia mode… haha… 
I managed to get back my system modifying /etc…/security and chkstat it but what I got back was a system where I had to give my password with almost any action (reboot, NetworkManager, etc…) : so I reinstalled everything and now… I’m good ! :shame:
Maybe for simplicity you should only install one postresql and get it working before you try another. The following re-installs from the OSS(which currently installs postgresql94 by default), note you can also install “postgresql93 or postgresql94” packages.
In fact, I did. But zypper in posgresql-server offers to install postgresql94-server too. It is only when you **zypper in postgresql94-server **directly then it does not offer postgresql-server at the same time. It’s what I planned to do now. I will come back if…
After installed you can verify the existence of the postgresql unit file.
Note that standard openSUSE behavior is newly installed apps are not started or enabled by default.
…]
TSU
Thanks for all the tips, I’ll keep that in mind !
Ok, everything ran smoothly !
And I learned a few things on the fly : there weren’t any systemd unit file because postgresql installs with an initd script… And anyway, systemd can manage enabling/start/stop without any custom addition.
Thanks again Mr TSU and to Mr Arvidjaar too for the time he lost !