Обсуждение: moving postgresql's data directory
First I would like to thank those in irc that have helped me, but after two days I am going to send this beginners email in the hope that what I am missing can be pointed out. (also after having read many online blog posts and stackoverflow questions on this topic.)
I am just trying to move postgresql's data directory on Fedora 20, PostgreSQL 9.3.(background, the root partition is pretty small, and I just want to move the data directory into my /home partition as noted below)
sudo systemctl stop postgresql.service
sudo mv /var/lib/pgsql/data /home/pgdata
sudo ln -s /home/pgdata/data /var/lib/pgsql/
sudo chown -R postgres:postgres /home/pgdata
sudo systemctl start postgresql.service
I get this error:
Job for postgresql.service failed. See 'systemctl status postgresql.service' and 'journalctl -xn' for details.
so I enter this:
systemctl status postgresql.service
and I get this:
postgresql.service - PostgreSQL database server
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; enabled)
Active: failed (Result: exit-code) since Fri 2014-01-10 09:23:16 EST; 4min 9s ago
Process: 19746 ExecStop=/usr/bin/pg_ctl stop -D ${PGDATA} -s -m fast (code=exited, status=0/SUCCESS)
Process: 20497 ExecStart=/usr/bin/pg_ctl start -D ${PGDATA} -s -o -p ${PGPORT} -w -t 300 (code=exited, status=1/FAILURE)
Process: 20492 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 19576 (code=exited, status=0/SUCCESS)
journalctl -xn
and I get this:
-- Logs begin at Tue 2013-12-17 20:17:51 EST, end at Fri 2014-01-10 09:21:32 EST. -
Jan 10 09:10:36 localhost.localdomain gnome-session[1640]: <Window object at 0xd9b9
Jan 10 09:11:58 localhost.localdomain gnome-session[1640]: (tracker-miner-fs:1914):
Jan 10 09:11:58 localhost.localdomain gnome-session[1640]: (tracker-miner-fs:1914):
Jan 10 09:17:24 localhost.localdomain gnome-session[1640]: Window manager warning:
Jan 10 09:18:24 localhost.localdomain gnome-session[1640]: Warning: python-keybinde
Jan 10 09:18:24 localhost.localdomain gnome-session[1640]: Unable to bind hide_wind
Jan 10 09:21:04 localhost.localdomain gnome-session[1640]: Window manager warning:
Jan 10 09:21:20 localhost.localdomain gnome-session[1640]: <Window object at 0x298f
Jan 10 09:21:32 localhost.localdomain gnome-session[1640]: Warning: python-keybinde
Jan 10 09:21:32 localhost.localdomain gnome-session[1640]: Unable to bind hide_wind
lines 1-11/11 (END)
Henry Drexler <alonup8tb@gmail.com> writes: > I am just trying to move postgresql's data directory on Fedora 20, > PostgreSQL 9.3. > sudo systemctl stop postgresql.service > sudo mv /var/lib/pgsql/data /home/pgdata > sudo ln -s /home/pgdata/data /var/lib/pgsql/ > sudo chown -R postgres:postgres /home/pgdata That symlink doesn't sound like a terribly good idea. You should customize the service file to specify a correct PGDATA path, instead. Another thought is that it might be a good idea to alter the postgres user's home directory setting (in /etc/passwd or wherever they keep it these days) to be /home/pgdata. However, I suspect that the key reason this isn't working is SELinux restrictions. Does it start if you "setenforce 0"? I hasten to say that that's a lousy permanent solution, but it would allow the theory to be confirmed or denied quickly. If that's it, you probably need to be paying attention to the SELinux labeling (cf "ls -Z") of the moved files and directories. Also, the reason you're not finding any relevant log entries is probably that you're not looking in the right place. If memory serves, the Red Hat service file starts the postmaster with log output going to /var/lib/pgsql/postmaster.log or something like that. The postmaster will shortly later redirect its log output into some file under /var/lib/pgsql/pg_log/, but startup-time failure messages might appear in either place. regards, tom lane
On Fri, Jan 10, 2014 at 10:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Tom, I hate to say it - but I just cried out of happiness.
However, I suspect that the key reason this isn't working is SELinux
Thank you for your help. SELinux was causing the issue (I did not suspect it as I usually get pop-ups when there is a violation). setting selinux to permission allowed the database to start up - so that now tells me where my issue lies.
Thank you again - I really do appreciate it.