Mark Post wrote:
On Mon, May 12, 2008 at 2:51 PM, in message
<[EMAIL PROTECTED]>,
James Melin <[EMAIL PROTECTED]> wrote:
-snip-
Back in the day at the recommendation of the 'Lpar to virtual server'
redbook, I did the bastille hardening which appended this to syslog.conf
Mike et. al. recommen
Mark Post wrote:
On Mon, May 12, 2008 at 2:20 PM, in message
<[EMAIL PROTECTED]>,
James Melin <[EMAIL PROTECTED]> wrote:
-snip-
I am seeing a file by syslogd on /dev/tty7 in the lsof output
syslogd 13827root3u FIFO 94,1 28707
/dev/xconsole
syslogd 1382
Mark Post wrote:
On Mon, May 12, 2008 at 1:51 PM, in message
<[EMAIL PROTECTED]>,
James Melin <[EMAIL PROTECTED]> wrote:
I mounted /dev/dasda1 on /mnt so that du wouldn't traverse all of the mounted
file systems
Running du -B 4k /mnt/ | sort +0nr | less - reveals this:
54846 /mnt/
311
James Melin wrote:
Linux on 390 Port wrote on 05/12/2008 01:01:03 PM:
On May 12, 2008, at 12:51 PM, James Melin wrote:
If anyone has an idea as to either what is going on or what smack me
in the head obvious clue I'm missing, would love to hear from you.
I currently have this file system str
James Melin wrote:
I mounted /dev/dasda1 on /mnt so that du wouldn't traverse all of the mounted
file systems
Running du -B 4k /mnt/ | sort +0nr | less - reveals this:
54846 /mnt/
31154 /mnt/dev
9267/mnt/lib
7204/mnt/lib/modules
7200/mnt/lib/modules/2.6.5-7.283-s390x
6978
Oh, just looked at your email address. Logon to CMS, issue "VMLINK ESAMON
198", then
"ESAMON SMART".
Fargusson.Alan wrote:
I think someone posted a CP command to show what the CPU usage is of various
virtual machines, however I can't seem to find it.
I was told that the LPAR is using 100%
Barton Robinson wrote on 05/12/2008 04:00:11 PM:
> So you use the z/OS performance monitor for monitoring the LPAR, it
> will say your IFL is
> running at 100%. This would be useless information, and less than
accurate.
True, if your IFL is dedicated. If not dedicated, the number is accurate
but
>>> On Mon, May 12, 2008 at 4:07 PM, in message
<[EMAIL PROTECTED]>,
"Fargusson.Alan" <[EMAIL PROTECTED]> wrote:
> I don't know how they determine that the LPAR is running at 100% CPU. It may
> be completely inaccurate, so I want to check from VM.
Just "#CP IND" will tell you what CP thinks of
I don't know how they determine that the LPAR is running at 100% CPU. It may
be completely inaccurate, so I want to check from VM.
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Barton Robinson
Sent: Monday, May 12, 2008 2:00 PM
To: LINUX-390@VM.MARIST.EDU
Here is an exec we used to use to generate alerts via sendfile. While it is
no full-blown monitor, it is easy to update if you want to track something
specific over time. I'm sure a plumber will see lots of possible
improvements.
Bob.
/**
So you use the z/OS performance monitor for monitoring the LPAR, it will say
your IFL is
running at 100%. This would be useless information, and less than accurate.
Fargusson.Alan wrote:
I think someone posted a CP command to show what the CPU usage is of various
virtual machines, however
>>> On Mon, May 12, 2008 at 3:20 PM, in message
<[EMAIL PROTECTED]>,
James Melin <[EMAIL PROTECTED]> wrote:
> Linux on 390 Port wrote on 05/12/2008 02:02:51 PM:
-snip-
> Curiously, on a mouldy old test system I have that was never built from that
> clone, tty7, tty8, tty12 (or 1-6 and 9 &10) do
Linux on 390 Port wrote on 05/12/2008 02:02:51 PM:
> >THe question is.. how do I re-create these device entries so that the
> are not regular files anymore?
>
> I can tell you that they are created out of the script
> /usr/share/doc/packages/devs/makedevs
Curiously, on a mouldy old test system I
>THe question is.. how do I re-create these device entries so that the
are not regular files anymore?
I can tell you that they are created out of the script
/usr/share/doc/packages/devs/makedevs
You could probably delete them and rerun makedevs, but I'd back things
up first to make sure.
Marcy
>>> On Mon, May 12, 2008 at 2:51 PM, in message
<[EMAIL PROTECTED]>,
James Melin <[EMAIL PROTECTED]> wrote:
-snip-
> Back in the day at the recommendation of the 'Lpar to virtual server'
> redbook, I did the bastille hardening which appended this to syslog.conf
Mike et. al. recommended Bastille
James Melin wrote:
# Log additional data to the Alt-F7 and Alt-F8 screens (Pseudo TTY 7 and 8)
That's not going to work on s390x.. that's obviously intended for intel
boxes (or at least boxes with an integrated graphics display).
I would suggest removing (or at least commenting out) the lines
>>> On Mon, May 12, 2008 at 2:37 PM, in message <[EMAIL PROTECTED]>, Ivan
Warren <[EMAIL PROTECTED]> wrote:
-snip-
> 1st output field of 'lsof' isn't a userid.. it's rather looks like the
> basename of the exec()'d image for the process..
Correct. It's the name of the program that has the file
Linux on 390 Port wrote on 05/12/2008 01:27:22 PM:
> >>> On Mon, May 12, 2008 at 2:20 PM, in message
> <[EMAIL PROTECTED]>,
> James Melin <[EMAIL PROTECTED]> wrote:
> -snip-
> > I am seeing a file by syslogd on /dev/tty7 in the lsof output
> >
> > syslogd 13827root3u FIFO
Mark Post wrote:
syslogd 13827root 23w REG 94,1 91442612 29065
/dev/tty7
That looks like your problem. The "REG" says that it is a "regular file" when it should
be "CHR." What distribution is this? I know that syslogd isn't a userid shipped with SLES9 or
SLES1
>>> On Mon, May 12, 2008 at 2:20 PM, in message
<[EMAIL PROTECTED]>,
James Melin <[EMAIL PROTECTED]> wrote:
-snip-
> I am seeing a file by syslogd on /dev/tty7 in the lsof output
>
> syslogd 13827root3u FIFO 94,1 28707
> /dev/xconsole
> syslogd 13827
Linux on 390 Port wrote on 05/12/2008 01:07:35 PM:
> >>> On Mon, May 12, 2008 at 1:51 PM, in message
> <[EMAIL PROTECTED]>,
> James Melin <[EMAIL PROTECTED]> wrote:
> > I mounted /dev/dasda1 on /mnt so that du wouldn't traverse all of
> the mounted
> > file systems
> >
> > Running du -B 4k
Linux on 390 Port wrote on 05/12/2008 01:01:03 PM:
> On May 12, 2008, at 12:51 PM, James Melin wrote:
>
> >
> > If anyone has an idea as to either what is going on or what smack me
> > in the head obvious clue I'm missing, would love to hear from you.
> > I currently have this file system structu
>>> On Mon, May 12, 2008 at 1:51 PM, in message
<[EMAIL PROTECTED]>,
James Melin <[EMAIL PROTECTED]> wrote:
> I mounted /dev/dasda1 on /mnt so that du wouldn't traverse all of the mounted
> file systems
>
> Running du -B 4k /mnt/ | sort +0nr | less - reveals this:
>
> 54846 /mnt/
> 3115
On May 12, 2008, at 12:51 PM, James Melin wrote:
If anyone has an idea as to either what is going on or what smack me
in the head obvious clue I'm missing, would love to hear from you.
I currently have this file system structure mounted:
It looks like there's a very large file in /mnt/dev.
D
The -x option stops du from moving to other filesystems. Usually I use
something like:
du -ckx --max-depth=1
to drill down to the unexpected space usage. I haven't come up against a
situation where this doesn't work yet.
Best regards,
Pieter Harder
[EMAIL PROTECTED]
tel +31-73-6837133 / +3
I mounted /dev/dasda1 on /mnt so that du wouldn't traverse all of the mounted
file systems
Running du -B 4k /mnt/ | sort +0nr | less - reveals this:
54846 /mnt/
31154 /mnt/dev
9267/mnt/lib
7204/mnt/lib/modules
7200/mnt/lib/modules/2.6.5-7.283-s390x
6978/mnt/lib/modules/2
Can I suggest you learn how to use your monitoring tool? :)
Which tool do you have? Maybe someone can tell you a quick way to use it to
find which Linux guest
is causing your problem and why. Your problem may not be caused by a Linux
guest - it may be
something else.
Fargusson.Alan wrote:
Yo
I think someone posted a CP command to show what the CPU usage is of various
virtual machines, however I can't seem to find it.
I was told that the LPAR is using 100% of the CPU. Fortunately the LPAR has an
IFL that is not shared with any other LPAR. All of my Linux instances are
mostly idle,
In the Red Hat rescue environment, the kernel is the same as a running
system. There are differences in user space binaries/libraries (LVM
commands are run through an LVM shell instead of separate commands for
example), but the kernel is the same.
-Brad
On Sun, 2008-05-11 at 18:48 -0600, Lee Ste
> I have always avoided the rescue kernel approach. With Linux on z/VM
> we have indeed better ways to do it.
The whole idea of using a different kernel is that the problem will be in the
kernel. If it is not (which in my zSeries world it has never been) using a
different kernel will not help.
On Mon, May 12, 2008 at 2:48 AM, Lee Stewart
<[EMAIL PROTECTED]> wrote:
> Is there anything in the rescue kernel that is NOT in the regular
> kernel? (Any reason to use the rescue kernel as opposed to just
> linking to the penguin with a problem from on that is happy?)
I have always avoided th
31 matches
Mail list logo
