On 02/17/2016 08:10 AM, Michael H wrote:
The easy answer is yes .. glibc requires so many things to be restarted, that is the best bet. Or certainly the easiest.
Note: in CentOS 7, there is also a kernel update which is rated as Important .. so you should boot to that anyway: https://lists.centos.org/pipermail/centos-announce/2016-February/021705.html
Here is a good link to figure out what to restart if you don't want to reboot:
https://rwmj.wordpress.com/2014/07/10/which-services-need-restarting-after-a...
and there is this thread: http://markmail.org/message/dodinyrhwgey35mh
But generalyl, after a glibc update or a kernel update .. rebooting is easiest and it ensures everything is protected.
Wow, so, I updated my server (yum update -y) which applied a new kernel and the new glibc among other things, After the update completed it knocked my master postgresql database offline.
Feb 17 13:46:11 db1 systemd: Starting PostgreSQL database server... Feb 17 13:46:11 db1 pg_ctl: LOG: invalid value for parameter "max_stack_depth": 16384 Feb 17 13:46:11 db1 pg_ctl: DETAIL: "max_stack_depth" must not exceed 7680kB. Feb 17 13:46:11 db1 pg_ctl: HINT: Increase the platform's stack depth limit via "ulimit -s" or local equivalent. Feb 17 13:46:11 db1 pg_ctl: FATAL: configuration file "/var/lib/pgsql/data/postgresql.conf" contains errors Feb 17 13:46:16 db1 pg_ctl: pg_ctl: could not start server Feb 17 13:46:16 db1 pg_ctl: Examine the log output. Feb 17 13:46:16 db1 systemd: postgresql.service: control process exited, code=exited status=1 Feb 17 13:46:16 db1 systemd: Failed to start PostgreSQL database server. Feb 17 13:46:16 db1 systemd: Unit postgresql.service entered failed state. Feb 17 13:46:16 db1 systemd: postgresql.service failed.
I have kernel parameters specified in /etc/sysctl.conf
vm.swappiness=0 vm.overcommit_memory=2 vm.overcommit_ratio=90 kernel.shmmax=35433480192 kernel.shmall=8650752
After the update my postgresql service could not start because these parameters had been reset, I promptly rebooted to server to re-apply them.
Has something changed?!? after a reboot the service still complained that my max_stack_depth was too high because kernel shmmax and shmall were too low with the same error shown above.
[root@db1 ~]# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 514616 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 514616 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
confirms that my entries in /etc/sysctl.conf were ignored.
Why would these not work anymore?
Are the parameters specified elsewhere now?
any information would be very helpful!
Thanks
Michael (slightly more grey now)
Since you are talking about SystemD .. I assume c7.
In c7 .. there is a symlink to /etc/sysctl.d/99-sysctl.conf to /etc/sysctl.conf
Have you verified your sysctl.conf actually contains those settings still.
Your best bet on CentOS-7 is to create a new file in /etc/sysctl.d/ called something like 99-postgres.conf and put youjr mods in there. That way it will never change.
Also .. verify all the files in /etc/sysctl.d/ and /etc/sysctl.conf are set to this label for selinux:
unconfined_u:object_r:etc_t:s0
See this for labeling: red.ht/1ooTpiI
But, /etc/sysctl.conf should still work in centos-7.