similar to: Error starting tinc

I get this error starting tincd: tincd -n vpndr -d5 -D tincd 1.0.26 (Jan 22 2016 19:28:17) starting, debug level 5 /dev/net/tun is a Linux tun/tap device (tun mode) Executing script tinc-up System call `getaddrinfo' failed: Name or service not known Terminating Also keepalived return an error when tincd start. Starting as a daemon. Joutnalctl show this: Jan 22 23:14:49 systemd[1]:

I tested a little more... tincd does not create virtual interface device correctly on CentOS 7, I don't know where tincd stop, probably on " System call `getaddrinfo' failed: Name or service not known" I sent you before. Keepalived return that error I shown on every ip command but this is not a problem now, I'll see this as soon as possible. If I execute these commands tun

Hey guys, I'm trying to install keepalived 1.2.19 on a centos 6.5 machine. I did an install from source. And when I start keepalived this is what I'm seeing in the logs. It's reporting that the VRRP_Instance(VI_1) Now in FAULT state. Here's more of that log entry: Sep 29 12:06:58 USECLSNDMNRDBA Keepalived_vrrp[44943]: VRRP Instance = VI_1 Sep 29 12:06:58 USECLSNDMNRDBA

No parameters using DNS. - tinc.conf content Name = sito1 AddressFamily = ipv4 BindToAddress = <IPPUB>:665 BindToInterface = int Device=/dev/net/tun Interface = vpndrif Mode = router PingInterval = 60 PingTimeout = 5 ProcessPriority = normal - host/sito1 content Address = <IPPUB>:665 Subnet = <IPLOCAL>/<NETMASK> Port = 655 -----BEGIN RSA PUBLIC KEY----- ... -----END

Hello, We are using CentOS 6.6 and keepalived 1.2.13 on two servers for failover, no load-balancing. Failover is governed by the NIC being present, and the Apache and Tomcat processes being present. Both servers are configured as 'EQUAL' (not master/backup). An initial priority of 100 is set, and if a process or NIC fails, then this is reduced by 60 - causing a lower priority to be seen

Hi, I found some info messages below in /var/spool/mail/root. To reduce the size of that file, I'm wondering if there's a way to prevent those unimportant messages from entering /var/spool/mail/root. Thanks. 2010-05-10T10:32:27-05:00 <authpriv.info> se1 su: pam_unix(su-l:session): session closed for user root 2010-05-10T10:01:28-05:00 <local1.info> se1 Keepalived_vrrp:

Prior to upgrading to CentOS 7.4 everything was fine, after upgrade I'm seeing /etc/keepalived# keepalived -f /etc/keepalived/keepalived.conf --dont-fork --log-console --log-detail --dump-conf -m -v Starting VRRP child process, pid=17224 Registering Kernel netlink reflector Registering Kernel netlink command channel Registering gratuitous ARP shared channel Opening file

Hi List, I'm tuning up a new database server and I'm finding very mixed information online. Here are the default shmmax and shmall from my new system cat /proc/sys/kernel/shmmax 4294967295 cat /proc/sys/kernel/shmall 268435456 SHMALL is close enough to being SHMMAX / 16. Now, everything I'm finding online tells me that SHMALL = SHMMAX / PAGE_SIZE. default page size is 4096.

On 17/02/16 14:32, Michael H wrote: > Hi, re-posting this with a more appropriate subject for my reply; > >> 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:

Hello, I have the following entries in /boot/loader.conf: kern.ipc.shm_use_phys="1" kern.ipc.semmns="500" kern.ipc.semmni="40" kern.ipc.semmap="500" which are set correctly. Unfortunately, the following two entries kern.ipc.shmmax="512000000" kern.ipc.shmall="65526" do not change the corresponding values according to

Hello again, on CentOS 6 / 64 bit what is please the best way to permanently increase the shared memory? I'd like to give shared_buffers = 4096MB to PostgreSQL 8.4 on my machine with 16 GB RAM, but I currently only have: # sysctl -A|grep shm kernel.shmmax = 33554432 kernel.shmall = 2097152 kernel.shmmni = 4096 and this produces the error in /var/lib/pgsql/pgstartup.log:

On 02/17/2016 07:08 AM, Michael H wrote: > On 17/02/16 13:01, Johnny Hughes wrote: >> I normally just let the daily announce post to this list show what >> is available for updates, but there is a CVE (CVE-2015-7547) that >> needs a bit more attention which will be on today's announce list >> of updates. >> >> We released a new glibc yesterday for

On 2/17/2016 6:39 AM, Michael H wrote: > Some additional information; > > sysctl -a | grep kernel.shm > kernel.shmall = 8650752 > kernel.shmmax = 35433480192 > kernel.shmmni = 4096 > > which corresponds to my /etc/sysctl.conf > kernel.shmmax=35433480192 > kernel.shmall=8650752 > > but contradicts; > ulimit -a > [...] > stack size (kbytes,

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: >>

> 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

Hi, Anybody have success with postgresql 8.1.3 on a new Intel OS X box? All hints welcome, please! I installed postgres 8.1.3 via darwinports, and everything is great until the initdb step. Initdb fails on shmget saying it couldn''t allocate enough memory (see below). So, I edited /etc/rc and increased kern.sysv.shmmax from 4194304 to 41943040 (4MB to 40MB) After reboot and

Hi, re-posting this with a more appropriate subject for my reply; > 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: >

Hi All, I've been tuning a server recently and just today this has started to appear in my top/htop output. [root at db1 ~]# ps -aux | grep kernel root 1011 0.0 0.0 212048 4532 ? Ss 13:34 0:00 /usr/bin/abrt-watch-log -F BUG: WARNING: at WARNING: CPU: INFO: possible recursive locking detected ernel BUG at list_del corruption list_add corruption do_IRQ: stack overflow: ear stack overflow

Greetings, all: OS: CentOS 6.4 x86_64 Kernel: 2.6.32-358.14.1 I could use some assistance with setting up pulse to load balance my dns servers. I've configured tcp and udp port 53 with the piranha gui, set up arptable rules on the real servers and added the virtual ip to the bond0 interface on the real servers, but I'm still having no luck in getting things going. A dig against the

On 02/17/2016 08:39 AM, Johnny Hughes wrote: > 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: