Re: [CentOS] Tracking or checking backported kernel patches from upstream

El mié., 2 de sep. de 2020 a la(s) 11:17, Johnny Hughes (joh...@centos.org) escribió: > There is not really a 'procedure' to do that . certianly not in CentOS. > Eh... poor wording from my part. I meant procedure *for me* to check. You CAN do a diff on the exploded tarball from the SRPM and

[CentOS] Tracking or checking backported kernel patches from upstream

Hi! I'm interested in finding out if a couple of upstream kernel patches were backported into CentOS (RHEL), in particular this one and this one

Re: [CentOS] 7.7.1908, interface bonding, and default route

El vie., 20 de sep. de 2019 a la(s) 10:03, Alexander Dalloz ( ad+li...@uni-x.org) escribió: > If you don't want to use NetworkManager, then define NM_CONTROLLED="no" > And *that* was the answer! Everything is working as expected now. Thank you! Carlos.

Re: [CentOS] 7.7.1908, interface bonding, and default route

El vie., 20 de sep. de 2019 a la(s) 06:16, Giles Coochey (gi...@coochey.net) escribió: > I have a similar set up to you, and just did the upgrade to 1908, I > didn't experience the problem you had, I can't see anything out of the > ordinary in your network files. > I have reviewed the

[CentOS] 7.7.1908, interface bonding, and default route

Hi! I just upgraded a machine to 7.7.1908 and the default route is not being set on boot. This particular server has a bonded interface, and the corresponding configuration for the master is ( /etc/sysconfig/network-scripts/ifcfg-bond0): TYPE=Bond BOOTPROTO=none DEFROUTE=yes

Re: [CentOS] BUG: soft lockup - CPU#0 stuck for 36s! [swapper/0:0]

2016-08-18 13:32 GMT-04:00 JJB : > > I'm also seeing those errors in several servers, running under 5.5. >> Currently investigating if this >> > language=en_US=displayKC=1009996> >> has anything to do (the resource

Re: [CentOS] BUG: soft lockup - CPU#0 stuck for 36s! [swapper/0:0]

2016-08-18 12:39 GMT-04:00 correomm : > This bug is reported only on the VM's with CentOS 7 running on on VMware > ESXi 5.1. > The vSphere performance graph shows high CPU consume and disk activity only > on VM's with CentOS 7. Sometimes I can not connect remotely with ssh >

Re: [CentOS] php55w-fpm on CentOS 7: settings location

2016-08-03 13:42 GMT-04:00 Boris Epstein : > Does anybody know where to enter settings for php-fpm? I have tried a > number of things, including starting it with "-c /etc/php.ini" but that > seemed to have any effect. Any idea on how to control it? What am I doing > wrong?

[CentOS] Squid for CentOS 7 and available file descriptors

Hi, I'm installing a Squid instance for a large (ish) group of users. In the past I've had to increase the number of available file descriptors for the Squid process in order to avoid hitting the limits (and disrupting the service). It seems that the packaged Squid for CentOS 7 has a hardcoded

Re: [CentOS] Systemd

El sáb., may. 23, 2015 10:37 PM, Kirk Bocek t...@kbocek.com escribió: ... Ntpd runs just fine. But why isn't it loading at boot... Did you run systemctl enable ntp.service after installing it? HTH, Carlos. ___ CentOS mailing list

Re: [CentOS] Delaying systemd reboot for a while

On Thu, May 14, 2015 at 9:59 AM, Matthew Miller mat...@mattdm.org wrote: Have you tried this? It's a symlink, but systemctl knows to act differently when called as shutdown, and the traditional use still works. No need to hack around anything — just use 'shutdown -r' as always. Oh, yes!

[CentOS] Delaying systemd reboot for a while

Hi, I'm in need of rebooting a server 1 minute after I give the command. I'm used to shutdown -r +1 which works as advertised. Now that shutdown is part of systemd http://www.freedesktop.org/software/systemd/man/shutdown.html and it is actually a link to it in CentOS 7, I've seen in the

Re: [CentOS] Delaying systemd reboot for a while

Hi, On Thu, May 14, 2015 at 1:11 AM, Peter Lawler cen...@bleeter.id.au wrote: On 14/05/15 13:44, Martin Cigorraga wrote: Hello Carlos, You can try the 'at' command to achieve the same result. Regards, -Martín or 'sleep' Well, even though both could work, I fiinally went with the