Re: [CentOS] df

[Paul Heinlein]

On Thu, 23 May 2019, Stephen John Smoogen wrote:


On Thu, 23 May 2019 at 16:43, Paul Heinlein  wrote:


On Thu, 23 May 2019, Stephen John Smoogen wrote:


I might actually be able to have a workable answer:

alias drf='/usr/bin/df -x tmpfs'


/usr/bin/df \
   -x autofs -x binfmt_misc -x cgroup -x configfs -x debugfs \
   -x devpts -x devtmpfs -x efivarfs -x hugetlbfs -x mqueue \
   -x nfsd -x proc -x pstore -x rpc_pipefs -x securityfs \
   -x selinuxfs -x sysfs -x tmpfs



I guess the opposite would also work

/usr/bin/df -t ext3 -t ext4 -t xfs ?


At $WORK, we'd have to add -t lustre -t nfs -t nfs4 -t vfat.

--
Paul Heinlein
heinl...@madboa.com
45°38' N, 122°6' W
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] df

[Stephen John Smoogen]

On Thu, 23 May 2019 at 16:43, Paul Heinlein  wrote:

> On Thu, 23 May 2019, Stephen John Smoogen wrote:
>
> > I might actually be able to have a workable answer:
> >
> > alias drf='/usr/bin/df -x tmpfs'
>
> /usr/bin/df \
>-x autofs -x binfmt_misc -x cgroup -x configfs -x debugfs \
>-x devpts -x devtmpfs -x efivarfs -x hugetlbfs -x mqueue \
>-x nfsd -x proc -x pstore -x rpc_pipefs -x securityfs \
>-x selinuxfs -x sysfs -x tmpfs
>
>
I guess the opposite would also work

/usr/bin/df -t ext3 -t ext4 -t xfs ?




> :-)
>
> --
> Paul Heinlein
> heinl...@madboa.com
> 45°38' N, 122°6' W
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] df

[mark]

Stephen John Smoogen wrote:
>
> On Thu, 23 May 2019 at 16:22, mark  wrote:
>
>
>> 
>> I *swear*, I may get aggravated enough to write a drh - d *real* h.
>> Between C7, with all the /tmpfs, and this debian 18.04 that has a dozen
>> /snap all showing up All I want it to display is physical drive
>> partition space 
>>
> I might actually be able to have a workable answer:
>
>
> alias drf='/usr/bin/df -x tmpfs'

Cool! It works on a C 7 box. Unfortunately, on the ubuntu box, it doesn't
exclude /snap or loop or /dev/loopx

Thanks.

  mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] df

[Paul Heinlein]

On Thu, 23 May 2019, Stephen John Smoogen wrote:


I might actually be able to have a workable answer:

alias drf='/usr/bin/df -x tmpfs'


/usr/bin/df \
  -x autofs -x binfmt_misc -x cgroup -x configfs -x debugfs \
  -x devpts -x devtmpfs -x efivarfs -x hugetlbfs -x mqueue \
  -x nfsd -x proc -x pstore -x rpc_pipefs -x securityfs \
  -x selinuxfs -x sysfs -x tmpfs

:-)

--
Paul Heinlein
heinl...@madboa.com
45°38' N, 122°6' W
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] df

[Stephen John Smoogen]

I might actually be able to have a workable answer:

alias drf='/usr/bin/df -x tmpfs'

On Thu, 23 May 2019 at 16:22, mark  wrote:

> 
> I *swear*, I may get aggravated enough to write a drh - d *real* h.
> Between C7, with all the /tmpfs, and this debian 18.04 that has a dozen
> /snap all showing up All I want it to display is physical drive
> partition space
> 
>
>  mark
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>


-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] df

[mark]

I *swear*, I may get aggravated enough to write a drh - d *real* h.
Between C7, with all the /tmpfs, and this debian 18.04 that has a dozen
/snap all showing up All I want it to display is physical drive
partition space


 mark


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] system unresponsive

[mark]

Jon Pruente wrote:
> On Wed, May 22, 2019 at 10:02 AM mark  wrote:
>
>
>> That seems unlikely. Foe one, I've seen that... but I *always* see
>> entries in the log about the oom-killer being invoked. For another, this
>> isn't a compute node, it's *only* a fileserver, serving projects, home
>> directories, and backups (home-grown b/u, uses rsync), and backups
>> don't start until well after midnight, and as we're business-hours only,
>> there was less usage, and it does have 256G RAM
>>
> I have two servers that would lock up like this occasionally, and if I
> let them sit at the console long enough sometimes they would give a login
> prompt. It took a lot of time and frustration (these are prod servers)
> but I tracked it down to a problem in the XFS driver, as it never occurred
> on the systems with EXT4 filesystems. The XFS driver would hang,
> preventing writes to the filesystem. I could identify exactly when that
> happened as all system logging would suddenly stop at the same second.
> Then OOMKiller
> would come in and start killing off processes but that wouldn't be in the
> logs on disk because the file system couldn't write. I rolled the servers
>  back to a 5xx series kernel and the issue didn't resurface. I recently
> let them boot the newer 9xx series kernels and I'm hoping the XFS issue is
>  fixed.

I have no idea if that's it... and the cluster nodes that would have it
happen, a few years ago, were ext4.

Crap - I just went to look on the system that died, and from sar, I see
that it died between 18:10 and 18:20, and we found it unresponsive when I
got in at 09:00. I'd think that was enuogh time to print something.

 mark

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] system unresponsive

[Jon Pruente]

On Wed, May 22, 2019 at 10:02 AM mark  wrote:

> That seems unlikely. Foe one, I've seen that... but I *always* see entries
> in the log about the oom-killer being invoked. For another, this isn't a
> compute node, it's *only* a fileserver, serving projects, home
> directories, and backups (home-grown b/u, uses rsync), and backups don't
> start until well after midnight, and as we're business-hours only, there
> was less usage, and it does have 256G RAM
>

I have two servers that would lock up like this occasionally, and if I let
them sit at the console long enough sometimes they would give a login
prompt. It took a lot of time and frustration (these are prod servers) but
I tracked it down to a problem in the XFS driver, as it never occurred on
the systems with EXT4 filesystems. The XFS driver would hang, preventing
writes to the filesystem. I could identify exactly when that happened as
all system logging would suddenly stop at the same second. Then OOMKiller
would come in and start killing off processes but that wouldn't be in the
logs on disk because the file system couldn't write. I rolled the servers
back to a 5xx series kernel and the issue didn't resurface. I recently let
them boot the newer 9xx series kernels and I'm hoping the XFS issue is
fixed.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Bash completion thrown by quoted option args?

[Leroy Tennison]

I am going to take a really wild guess and say "Try replacing the outermost 
quotes with single quotes or escape the double quotes around the numeral 1".  
Your second example has double quotes within double quotes and I'm wondering if 
that's getting rendered as "yum --debuglevel="  1  " install ..." 
(extra space added for emphasis).


From: CentOS  on behalf of isdtor 
Sent: Thursday, May 23, 2019 9:47:20 AM
To: CentOS mailing list
Subject: [EXTERNAL] [CentOS] Bash completion thrown by quoted option args?

There was a thread about C7 bash completion back in August last year, but it 
doesn't have answers for this problem.

Example: "yum install /path/to/local/package" works fine with tab completion to 
fill in the path and package bits.

However, "yum --debuglevel="1" install ..." just gets stuck and doesn't offer 
anything. The only option is to type everything out, or type enough to use a 
wildcard. After more testing, I found that any option argument that is quoted 
breaks completion. Which in turn makes me think this is not even specific to 
yum but bash completion in general.

Bug? Upstream bug?

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Harriscomputer

Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com


[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]


2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com


This message has been sent on behalf of a company that is part of the Harris 
Operating Group of Constellation Software Inc. These companies are listed 
here.

If you prefer not to be contacted by Harris Operating Group please notify 
us.



This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. If you 
are not the named addressee, you are not authorized to read, print, retain, 
copy or disseminate this message or any part of it. If you have received this 
message in error, please notify the sender immediately by e-mail and delete all 
copies of the message.




___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Bypassing 'A stop job is running' when rebooting CentOS 7

[James Szinger]

On Wed, May 22, 2019 at 1:41 PM Jon LaBadie  wrote:
> But we can blame systemd for the cryptic message
>
>   A stop job is running
>
> Surely systemd knows what service it is waiting for,
> why doesn't it tell us?
>
>   The stop job XYZ is running

The message reported by the OP and the message I see is 'A stop job is
running for ...' where the ellipses stand in for the unit that systemd
is waiting for.  It seems pretty clear IMHO.  Actually debugging it is
harder since the system is not available during shutdown, but that's a
generic problem and the systemd docs do provide debugging tips.

Jim
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Bash completion thrown by quoted option args?

[isdtor]

There was a thread about C7 bash completion back in August last year, but it 
doesn't have answers for this problem.

Example: "yum install /path/to/local/package" works fine with tab completion to 
fill in the path and package bits.

However, "yum --debuglevel="1" install ..." just gets stuck and doesn't offer 
anything. The only option is to type everything out, or type enough to use a 
wildcard. After more testing, I found that any option argument that is quoted 
breaks completion. Which in turn makes me think this is not even specific to 
yum but bash completion in general.

Bug? Upstream bug?

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Bypassing 'A stop job is running' when rebooting CentOS 7

[James Pearson]

Scott Robbins wrote:
> ** WARNING: This mail is from an external source **
> 
> 
> On Wed, May 22, 2019 at 03:41:24PM -0400, Jon LaBadie wrote:
>> On Wed, May 22, 2019 at 09:07:32AM -0600, James Szinger wrote:
>>> On Wed, May 22, 2019 at 7:44 AM mark  wrote:

 The joys of systemd
>>>
>>> I'm not sure it's right to blame systemd.  Systemd asked nicely for
>>> the service to shutdown.
>>
>> But we can blame systemd for the cryptic message
>>
>>A stop job is running
> 
> I didn't read this thread all that carefully, but has anyone mentioned
> editing /etc/systemd/system.conf and changing DefaultTimeoutStartSec and
> DefaultTimeoutStopSec to a lower value?

All the entries in /etc/systemd/system.conf are commented out - and as 
the systemd-system.conf man page states:

  By default the configuration file in /etc/systemd/ contains
  commented out entries showing the defaults as a guide to the
  administrator

The DefaultTimeoutStopSec line in /etc/systemd/system.conf is:

  #DefaultTimeoutStartSec=90s

In my case, the 'timeout' on whatever it was trying to do was 90 seconds 
- but it kept being increased by ~90 secs until it finally gave up at 30 
minutes ...

So I don't think changing DefaultTimeoutStartSec will help here ?

There is no mention of 30 minutes in /etc/systemd/system.conf, that is 
why I'm guessing it has something to do with the JobTimeoutSec in 
/usr/lib/systemd/system/reboot.target

A bit of (more) googling seems to suggest that this is the setting that 
needs to be changed. I believe this means something like 'after 30 
minutes from starting the reboot process, force a reboot regardless'

Personally, I think 30 minutes is far too long to wait, especially in 
the case of servers where no console access is available ...

James Pearson
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos