similar to: Systemd debug logging turned on in CentOS 7

Last time I saw it, I had just upgraded my CentOS 7 box with the 3.10.0-514 kernel and it rebooted already configured into debug mode. Not sure if this is a ?feature? of the newer kernels or not but glad to see that i?m not the only one who had noticed this. # awk -F\' '$1=="menuentry " {print i++ " : " $2}' /etc/grub2.cfg 0 : CentOS Linux

On Tue, Feb 28, 2017 at 10:49 AM, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote: > > On Tue, February 28, 2017 9:22 am, Rob DeSanno wrote: > > Last time I saw it, I had just upgraded my CentOS 7 box with the > > 3.10.0-514 kernel and it rebooted already configured into debug mode. > Not > > sure if this is a ???feature?? of the newer kernels or not but glad

On Tue, February 28, 2017 9:22 am, Rob DeSanno wrote: > Last time I saw it, I had just upgraded my CentOS 7 box with the > 3.10.0-514 kernel and it rebooted already configured into debug mode. Not > sure if this is a ???feature??? of the newer kernels or not but glad to > see that i???m not the only one who had noticed this. > > # awk -F\' '$1=="menuentry "

Once upon a time, Thomas Eriksson <thomas.eriksson at slac.stanford.edu> said: > I noticed that some, but not all, of my CentOS 7 machines have these > kernel parameters for turning on systemd debug level logging added to > the grub.cfg file. Yep, for each of the installed kernels, I have two GRUB entries: one with and one without debugging. It seems that when I install a new

I have multiple VMs that are hanging on boot. Sometimes they'll boot fine after 5 mins and other times it'll take over an hour. The problem seems to be related to journald but I'd like to figure out how I can get more information. The VMs are running CentOS 7.1.1503. systemd and journald are both version 208. We are reluctant to upgrade to the newest CentOS because we found that

On 08/03/2016 05:20 PM, Alice Wonder wrote: > On 08/03/2016 05:11 PM, Alice Wonder wrote: >> I'm having a major frustration with curl. >> >> When building curl, if libssl.so.10 is present the curl binary WILL link >> against it. > > *snip* > > Go ahead and ldd on the CentOS curl binary and library - you will see > openssl linked even though the spec

On Aug 15, 2015 13:23, Mark Milhollan <mlm at pixelgate.net> wrote: > > On Fri, 14 Aug 2015, Thomas Eriksson wrote: > > >If it's centos 6 stick 'ulimit -s' in the init script > > I suggest putting it in the sysconfig file instead, if such exists. > > Sure, but how many init scripts provide for adding an extra command via sysconfig files? Most of

In article <1446132814771.22431 at slac.stanford.edu>, Eriksson, Thomas <thomas.eriksson at slac.stanford.edu> wrote: > This should probably be a bug report for the fail2ban EPEL maintainer, the problem was introduced in version 0.9.3 > > >From the file /etc/fail2ban/action.d/iptables-common.conf > ... > # Option: lockingopt > # Notes.: Option was introduced to

On a CentOS 6.7 system that's been running fail2ban for a long time, we recently started seeing this: ct 28 19:00:59 <servername> fail2ban.action[17561]: ERROR iptables -w -D INPUT -p tcp --dport ssh -j f2b-SSH#012iptables -w -F f2b-SSH#012iptables -w -X f2b-SSH -- stderr: "iptables v1.4.7: option `-w' requires an argument\nTry `iptables -h' or 'iptables --help' for

On 02/28/2017 08:55 AM, Brian Mathis wrote: > On Tue, Feb 28, 2017 at 10:49 AM, Valeri Galtsev <galtsev at kicp.uchicago.edu> > wrote: > >> >> On Tue, February 28, 2017 9:22 am, Rob DeSanno wrote: >>> Last time I saw it, I had just upgraded my CentOS 7 box with the >>> 3.10.0-514 kernel and it rebooted already configured into debug mode. >> Not

On 02/27/2015 01:11 PM, Dave Burns wrote: > Apparently CentOS-7 - Base is failing, what does that mean? How do I > contact the upstream for the repo? How do I find a working upstream? > > More info from command execution: > do_ypcall: clnt_call: RPC: Timed out > do_ypcall: clnt_call: RPC: Timed out >

Hey guys, I have this log rotation script setup in my /etc/logrotate.d folder /var/log/elasticsearch/*.log { daily rotate 100 size 50M copytruncate compress delaycompress missingok notifempty create 644 elasticsearch elasticsearch } And I notice that log files are still being generated that are upwards of 7 or 8 GBs. Can anyone point out to me where the

Hi Guys, I'm facing this issue: https://bugs.centos.org/view.php?id=8482 It came after upgrading to 7.1 and only Firefox is affected, Chrome is working. What I've tried so far: - Tried NVIDIA drivers 340.65, 346.59 and 346.72 - Upgraded Firefox to 38 - Tried Safe more / Refresh Firefox - Tried to turn HW accel. off in Firefox None of these has helped to eliminate the issue. Do you

Once upon a time, Chris Murphy <lists at colorremedies.com> said: > On Tue, Apr 26, 2016, 2:09 PM Chris Adams <linux at cmadams.net> wrote: > > I have several recently-installed CentOS 7 servers that keep having > > systemd-journald corruption > > Determined with 'journalctl --verify' or another way? I get messages like this in dmesg: [4756650.489117]

Once upon a time, Chris Murphy <lists at colorremedies.com> said: > Also I wonder if merely restarting the journal daemon solves it: > > systemctl restart systemd-journald > > What should happen is it realizes its own logs are corrupt and ignores > them, and starts working on new copies. And journalctl should still > try to read the old ones but skips the corrupt

https://bugs.freedesktop.org/show_bug.cgi?id=104156 Bug ID: 104156 Summary: NVIDIA Corporation G96 [GeForce 9500 GT] (rev a1) issue finding GPIO Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component:

On an up-to-date CentOS 7 system, I am running named-sdb (pulling domain records from MySQL), which is segfaulting randomly (after 3-8 hours or so it appears) in libmysqlclient (I've opened a bug). Since this is an internal service, until the segfault can be addressed, I wanted systemd to restart it for me. I created a file called /etc/systemd/system/named-sdb-chroot.service.d/service.conf

Once upon a time, Chris Murphy <lists at colorremedies.com> said: > On Tue, Apr 26, 2016 at 3:01 PM, Chris Adams <linux at cmadams.net> wrote: > > Once upon a time, Chris Murphy <lists at colorremedies.com> said: > >> On Tue, Apr 26, 2016, 2:09 PM Chris Adams <linux at cmadams.net> wrote: > >> > I have several recently-installed CentOS 7

The following patch allows OpenSSH 2.2.0-p1 to be started (and managed) from /etc/inittab (by "init") on systems which support that. This is useful when you *really* want SSHD to always run since it will be automatically restarted by "init" if it dies (and if "init" dies the the systems dies :-). I use a line (in /etc/inittab) like this on Solaris systems:

I have several recently-installed CentOS 7 servers that keep having systemd-journald corruption (which stops ALL logging, including syslog). Interestingly, they are all spam-scanning servers running amavisd-new (so could be some particular pattern is triggering it). Is there a "supported" way to just cut systemd-journald out of the picture and have log entries go straight to rsyslogd?