[CentOS] New glibc for CentOS-6 and CentOS-7 and CVE-2015-7547

[Michael H]

> 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-an-upgrade/
> 
> 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 at 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)