changes in /etc/conf.d/postgresql-9.3 are ignored in /usr/lib64/systemd/system/postgresql-9.3.service, because of hardcoded $Environment should use the home-directory of the postgres-user if possible Reproducible: Always Steps to Reproduce: 1. edit /etc/conf.d/postgresql-9.3: DATA_DIR="/home/postgresql/9.3/data" 2. emerge --config =dev-db/postgresql-server-9.3.3 3. try starting the server with systemctl start postgresql-9.3 Actual Results: Job for postgresql-9.3.service failed. See 'systemctl status postgresql-9.3.service' and 'journalctl -xn' for details. Output of systemctl status postgresql: ● postgresql-9.3.service - PostgreSQL database server Loaded: loaded (/usr/lib64/systemd/system/postgresql-9.3.service; disabled) Active: failed (Result: exit-code) since Sa 2014-07-05 18:52:36 CEST; 18s ago Process: 7892 ExecStart=/usr/lib/postgresql-9.3/bin/pg_ctl start -D ${PGDATA} -s -l ${DATA_DIR}/postmaster.log -o -p ${PGPORT} --data-directory=${DATA_DIR} -w -t 300 (code=exited, status=1/FAILURE) Jul 05 18:52:31 nbbhk pg_ctl[7892]: sh: /var/lib/postgresql/9.3/data/postmaster.log: Datei oder Verzeichnis ...funden Jul 05 18:52:36 nbbhk pg_ctl[7892]: pg_ctl: konnte Server nicht starten Jul 05 18:52:36 nbbhk pg_ctl[7892]: Prüfen Sie die Logausgabe. Jul 05 18:52:36 nbbhk systemd[1]: postgresql-9.3.service: control process exited, code=exited status=1 Jul 05 18:52:36 nbbhk systemd[1]: Failed to start PostgreSQL database server. Jul 05 18:52:36 nbbhk systemd[1]: Unit postgresql-9.3.service entered failed state. Hint: Some lines were ellipsized, use -l to show in full. Expected Results: The path of postmaster.log should be /home/postgresql/9.3/data/postmaster.log Copying postgresql-9.3.service to /etc/systemd/system and apropriate editing reaches the goal. If it is possible, to take the value of the home-directory of user postgres instead of the hardcoded entry, this would fix it. If this isn't an option, the patched service-file should be created in /etc/...
$ head -n 13 /usr/lib/systemd/system/postgresql-9.3.service # It's not recommended to modify this file in-place, because it will be # overwritten during package upgrades. If you want to customize, the # best way is to create file # "/etc/systemd/system/postgresql-9.3.service.d/*.conf" # containing your changes # For example, if you want to change the server's port number to 5433, # create a file named # "/etc/systemd/system/postgresql-9.3.service.d/port.conf" # containing: # [Service] # Environment=PGPORT=5433 # This will override the setting appearing below.
Sorry for commenting a closed bug, but I don't know, how to discuss this with you on other channels: I need to edit /etc/conf.d/postgresql-9.3, because there is no other way, to give the new DATA_DIR to the following emerge --config =dev-db/postgresql-server-9.3.3. This creates all initial datafiles of the PostgreSQL-DB and the path cannot be changed later without a lot of problems. There are some possibilities, but those are more dirty tricks than good administration work. All this we can avoid by doing the configuration just before emerge --config ... My idea would be, to put initial parameters into this first config-file (for example: $HOME_DIR and $DATA_PATH) copy them in a first step to /etc/postgresql-9.3/postgresql.conf and use them by reference in all steps later, which means to patch some files like /usr/lib64/systemd/system. Maybe we should use a directory structure more like debian: /etc/postgresql/9.3/ /etc/postgresql/9.4/ In /etc/postgresql/ I would save all parameters which are version independent like $PGUSER and $HOME_DIR, in the subdirectories all version specific parameters like $DATA_DIR, $PORT and so on. I've no experience in creating ebuilds, but I would like to get involved, if you think it's worth to go on. Greetings, Timewulf
I'll consider the directory structure change after I look into the impact it will have on some other packages. Work on a patch if you want. I have no interest in systemd.
systemd environment should not be mixed with OpenRC (/etc/conf.d/) environment. This is a Gentoo policy (although some packages do not honour this policy yet). In systemd, the sane way to set environment is using Environment=... in - /usr/lib/systemd/system/$service_name.service (package defaults) - /etc/systemd/system/$service_name.service.d/*.conf (user override) My advice: Resolution: INVALID
