I managed to get NFS statistics just before server rebooted.
I can reproduce this every time.
Question: Am I saturating the SATA bus on the NFS server so violently
with the SSDs that the server hard reboots?
Perhaps due to the RAID 6 nature of operations?
Server info
AMD EPYC 7281 16CORE
32 GIG R
I think something along these lines appeared before
but I was unable to find them.
I'm on a 7.6 system, been running clamav and amavisd-new
since 6 days with little problem. On a recent reboot,
clamd@amavisd does not start up and fails manual start.
The problem seems to be the missing socket tha
On 8/30/19 8:31 AM, Alexander Dalloz wrote:
Based on that it appears to me very clear that the trust with the
DigiCert chain wasn't given due to a missing trust from the ca-cert bundle
That seems reasonable to me. :)
___
CentOS mailing list
CentOS
On 8/30/19 8:17 AM, Gary Stainburn wrote:
However, when I re-installed ca-certificates it immediately fixed the problem
on both boxes, which implies an internal problem.
That is only true if yum selected the same server, and there is no
evidence that it did. It's possible that reinstalling
Good morning,
in order to post proper documentation, what logs (or log level) do I
need to troubleshoot a Centos 7.6.1810 3.10.0-957.27.2.el7.x86_64 tha
tis running a NFS server on top LVM on top of XFS on top of VDO on top
of MDAM on a 6 SSD disk RAID6 ?
This physical NFS server is servign 2 NFS
On Friday 30 August 2019 16:27:01 Alexander Dalloz wrote:
> In posting
> https://lists.centos.org/pipermail/centos/2019-August/173288.html you
> could see that he has a repo "webtatic" configured, at that time calling
> a different mirror.
>
> Alexander
As far as I know I've never had webtatic
Am 2019-08-30 17:04, schrieb Gordon Messmer:
On 8/30/19 5:52 AM, Gary Stainburn wrote:
Incidentally, the*good* server that I was referencing my broken
server against has decided to start giving the curl certificate errors
in the same way that the broken one did. Very strange. I ran
It's po
Am 2019-08-30 17:17, schrieb Gordon Messmer:
On 8/29/19 8:20 AM, Alexander Dalloz wrote:
yum uses libcurl behind the scenes and thus NSS and not OpenSSL.
Good to know.
In that case: Gary, what do you see when you run:
/usr/lib64/nss/unsupported-tools/vfyserv -p 443
us-east.repo.webtati
On Friday 30 August 2019 16:04:51 Gordon Messmer wrote:
> On 8/30/19 5:52 AM, Gary Stainburn wrote:
> > Incidentally, the*good* server that I was referencing my broken server
> > against has decided to start giving the curl certificate errors in the same
> > way that the broken one did. Very str
On 8/29/19 8:20 AM, Alexander Dalloz wrote:
yum uses libcurl behind the scenes and thus NSS and not OpenSSL.
Good to know.
In that case: Gary, what do you see when you run:
/usr/lib64/nss/unsupported-tools/vfyserv -p 443
us-east.repo.webtatic.com
Do you get something indicative when
On 8/30/19 5:52 AM, Gary Stainburn wrote:
Incidentally, the*good* server that I was referencing my broken server against
has decided to start giving the curl certificate errors in the same way that
the broken one did. Very strange. I ran
It's possible that the error is unrelated to the ca-
You guys may have noticed that the 7.7.1908 packages for the GA release
have been posted to QA for all arches (x86_64, ppc64le, aarch64. ppc64,
armhfp, i386).
These are just the items that will be in the os/ (base) repository and
not the zero day updates. We are working on the updates now.
Annou
On Friday 30 August 2019 12:45:04 Paddy Doyle wrote:
>
> Just to mention that the 'etckeeper' package from EPEL is great for
> tracking changes to /etc. Package installs trigger a commit, as do a daily
> cron job.
>
> If in this case it was a corrupt file in /etc/pki, then a 'git log' or
> simila
On Fri, Aug 30, 2019 at 12:17:47PM +0100, Gary Stainburn wrote:
> On Friday 30 August 2019 12:03:26 Alexander Dalloz wrote:
> >
> > Besides a corrupted certificates bundle I cannot imagine a different
> > root cause actually.
Just to mention that the 'etckeeper' package from EPEL is great for
tr
On Friday 30 August 2019 12:03:26 Alexander Dalloz wrote:
> You are welcome Gary. And I am curious about what the cause of your repo
> troubles is.
I have looked back over what I have done, and cannot see what has caused the
problem to occurr. I do not see anywhere where it could have been from
On Friday 30 August 2019 11:51:35 Tony Mountifield wrote:
> And you could try re-installing ca-certificates on the offending box.
>
> # yum --disablerepo=\* --enablerepo=base --enablerepo=updates reinstall
> ca-certificates
>
> Cheers
> Tony
I have just done this and it appears to have fixed th
Am 2019-08-30 10:52, schrieb Gary Stainburn:
On Thursday 29 August 2019 18:10:19 Alexander Dalloz wrote:
> 2019-08-29 17:23:18,117 exception: [Errno 14] curl#60 - "Peer's
> Certificate issuer is not recognized."
> 2019-08-29 17:23:18,117 retrycode (14) not in list [-1, 2, 4, 5, 6,
> 7], re-raisi
In article <201908300952.37126.gary.stainb...@ringways.co.uk>,
Gary Stainburn wrote:
> On Thursday 29 August 2019 18:10:19 Alexander Dalloz wrote:
> > > 2019-08-29 17:23:18,117 exception: [Errno 14] curl#60 - "Peer's
> > > Certificate issuer is not recognized."
> > > 2019-08-29 17:23:18,117 retryc
On 30/08/19 9:02 PM, Gary Stainburn wrote:
[root@stan2 ~]# yum update
2. Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
On Friday 30 August 2019 04:54:14 Peter wrote:
>
> I would try this:
>
> yum clean all
ran okay.
> yum --disablerepo=epel update
ran okay but said there was nothing to update which I find hard to believe. It
has been a month or so at least since the last successful update. It did
complain ab
On Thursday 29 August 2019 18:10:19 Alexander Dalloz wrote:
> > 2019-08-29 17:23:18,117 exception: [Errno 14] curl#60 - "Peer's
> > Certificate issuer is not recognized."
> > 2019-08-29 17:23:18,117 retrycode (14) not in list [-1, 2, 4, 5, 6,
> > 7], re-raising
>
> [ ... ]
>
> > Cannot retrieve m
21 matches
Mail list logo