Re: KVM issues with dump
On Fri, Jul 6, 2012 at 7:59 PM, Todd And Margo Chester wrote: > On 07/06/2012 04:03 PM, Nico Kadel-Garcia wrote: >> >> On Fri, Jul 6, 2012 at 4:40 PM, Phong X Nguyen wrote: >> >>> On 6 Jul 2012, at 1516, Todd And Margo Chester wrote: >> >> On my VM, W7 is still half as fast as XP and ten times less stable -- pretty much matches what I see in the field. And Lotus Approach, which I use for my business accounting, runs worse on W7 than it runs on Wine. >>> Can I get more details about your issues? I routinely run Windows 7 in >>> VMs (generally VMWare) and get near-native speed for anything except >>> GPU-bound tasks. It's also rock-solid stable. So I'm curious about your >>> problems you mention you keep having. >>> >>> My general experience (for a fairly broad spectrum of users) is for most >>> relatively-recent hardware (e.g. >2GB RAM, half-decent IGP, etc.) Windows 7 >>> is as-fast, faster and a lot more productive than XP (the last due to >>> general UI improvements). >> >> >> Don't forget that Todd is using "dump" and "restore" for backup. I >> find them grossly inefficient, and rely on separate cheap media >> with "rsync" and "rsnapshot" for much faster, more efficient backups >> and recommend them highly. If you need to preserve SELinux data, >> Amanda or Zmanda with "star" also works well, and again, is much more >> efficient than dump and restore. >> > > > $ df /dev/sda1 > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/sda1 495844134640335604 29% /boot > > I backup the above in 1 hr, 12 min. How are your numbers? This is over what, DSL to a remote server? That's only 31 KBytes per second! The only thing I do that's comparable right now is rsync the SL 6.x repostories to an internal mirror (for use by "mock" package building). Takes a minute or two to verify 20 Gig of local material, then it's bandwidth limited by my local ISP to roughly 200 KBytes/second for files that have changed. tar and star for Amanda based backup to tape is mostly limited by network, or hard drive, bandwidth. I thought you were running into hard drive limites. 31 KBytes/second indicates something else is going on. Is your XP host infected and spewing spam or malware, eating your network bandwidth? Can you put a network monitor in place and look? For rsync based systems,
Re: kernel-2.6.18-308.8.2.el5.x86_64 stalled at stage2 during boot
> The latest kernel-2.6.18-308.8.2.el5.x86_64 would failed to boot, How far is it getting? Is it hanging? Is it resetting/rebooting? Have you tried booting with the quiet and rhgb options removed to see where the problem is occurring? I had a case of reset-during-boot, and resorted to recording a video of the screen to catch just where it was failing. - Bluejay Adametz, CFII, A&P, AA-5B N45210 A man who sets out to carry a cat by it's tail is about to learn something which will always be useful and which will never grow dim or doubtful. -- NOTICE: This message, including any attachments, is only for the use of the intended recipient(s) and may contain confidential and privileged information, or information otherwise protected from disclosure by law. If the reader of this message is not the intended recipient, you are hereby notified that any use, disclosure, copying, dissemination or distribution of this message or any of its attachments is strictly prohibited. If you received this message in error, please contact the sender immediately by reply email and destroy this message, including all attachments, and any copies thereof.
kernel-2.6.18-308.8.2.el5.x86_64 stalled at stage2 during boot
Hi all, I have a Supermicro box (motherboard X7DW3) with 3ware RAID card (9690SA-4I). I have 24 drives attached to this raid card, while the first three drives were exported as SINGLE (JBOD) drives. The /boot and /root are Linux software raid 1 on these first three drives. The latest kernel-2.6.18-308.8.2.el5.x86_64 would failed to boot, but the previous kernel, kernel-2.6.18-308.8.1.el5.x86_64, worked just fine. I also tested with CentOS kernel-2.6.18-308.8.2.el5.x86_64 and ended up with the same fate. Does anyone see this problem at all? I googled around and found only one Russian post with seemingly similar issue. I didn't find anything in RHEL bugzilla. Thank you.
Re: KVM issues with dump
On 07/06/2012 04:59 PM, Todd And Margo Chester wrote: $ df /dev/sda1 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 495844134640335604 29% /boot I backup the above in 1 hr, 12 min. How are your numbers? The above include compression and decryption (sda1 is luks)
Re: KVM issues with dump
On 07/06/2012 04:03 PM, Nico Kadel-Garcia wrote: On Fri, Jul 6, 2012 at 4:40 PM, Phong X Nguyen wrote: On 6 Jul 2012, at 1516, Todd And Margo Chester wrote: On my VM, W7 is still half as fast as XP and ten times less stable -- pretty much matches what I see in the field. And Lotus Approach, which I use for my business accounting, runs worse on W7 than it runs on Wine. Can I get more details about your issues? I routinely run Windows 7 in VMs (generally VMWare) and get near-native speed for anything except GPU-bound tasks. It's also rock-solid stable. So I'm curious about your problems you mention you keep having. My general experience (for a fairly broad spectrum of users) is for most relatively-recent hardware (e.g. >2GB RAM, half-decent IGP, etc.) Windows 7 is as-fast, faster and a lot more productive than XP (the last due to general UI improvements). Don't forget that Todd is using "dump" and "restore" for backup. I find them grossly inefficient, and rely on separate cheap media with "rsync" and "rsnapshot" for much faster, more efficient backups and recommend them highly. If you need to preserve SELinux data, Amanda or Zmanda with "star" also works well, and again, is much more efficient than dump and restore. $ df /dev/sda1 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 495844134640335604 29% /boot I backup the above in 1 hr, 12 min. How are your numbers?
Re: KVM issues with dump
On 07/06/2012 01:40 PM, Phong X Nguyen wrote: Speaking of fake, it took me years to bend my mind around the fact >that the VM CPUs are fake too. They are not actually using >a particular CPU. It was a light bulb moment. > Well, most operating systems don't have affinity for any particular CPU > either, so that's not particularly new? So long as the > instructions are properly being dispatched ... You can have 100 VCPUs if you desire. They are all fake (virtual). Before I understood this, I thought that a core was specifically assigned to each VCPU. > >On my VM, W7 is still half as fast as XP and ten times less >stable -- pretty much matches what I see in the field. >And Lotus Approach, which I use for my business accounting, >runs worse on W7 than it runs on Wine. > Can I get more details about your issues? I routinely run Windows > 7 in VMs (generally VMWare) and get near-native speed for anything > except GPU-bound tasks. It's also rock-solid stable. So I'm curious > about your problems you mention you keep having. I am running KVM under SL 6.2 64 bit: $ rpm -qa \*dump\* dump-0.4-0.6.b42.el6.x86_64 $ rpm -qa \*kvm\* qemu-kvm-0.12.1.2-2.209.el6_2.4.x86_64 $ uname -r 2.6.32-220.23.1.el6.x86_64 $ rpm -qa \*spice\* spice-protocol-0.8.1-2.el6.noarch spice-gtk-python-0.6-2.el6.x86_64 spice-server-0.8.2-5.el6.x86_64 spice-client-0.8.2-7.el6.x86_64 spice-glib-0.6-2.el6.x86_64 spice-gtk-0.6-2.el6.x86_64 spice-vdagent-0.8.1-3.el6.x86_64 This only happens when I run or have run my XP VM. Does not matter if the XP VM is running or not, just that it has run. My "dump" backup go from 1 hr, 12 min to 5 hr, 30 min. Five times slower. Reboot fixes the problem. My main issue with this is: 1) that is it a pain in the butt 2) I am concerned that this will also happen with Windows server 2003, which is based on the XP kernel. As I have stated before, only running the XP VM does this. None of the rest of them do. My general experience (for a fairly broad spectrum of users) is for > most relatively-recent hardware (e.g. >2GB RAM, half-decent IGP, etc.) > Windows 7 is as-fast, faster and a lot more productive than XP (the > last due to general UI improvements). Are you comparing 32 bit XP to 64 bit W7? I also turn off that stupid "Aero" interface, which gives a bump. (Linux 64 bit is the eight wonder of the world!) Had one lady that wanted a custom computer with W7 Pro on it. She mainly does accounting stuff. She ran it for a year. After W7 corrupted her hard drive, she had finally had it with all the crashing, bugs, etc.., So, I upgraded her to XP, she is twice as fast and hardly ever crashes anymore. No more corrupted hard drive either. (It was corrupted so bad that the Windows installer could not read it. Good thing I am handy with linux, or she would have lost everything. Got to love Xfce Live CD.) She really wanted to like W7 too. This is my experience. By the way, I really love (gag) the crash and roll back feature in W7. Especially when it removes all the customization I have added to the customer's machine at their request. (Workaround: make six restore points when you are finished customizing.) I have another customer that can't keep his network shares installed for his life. Crash and roll back. [editorial comment] AHH!!! What a piece of Junk! [/editorial comment] -T
Re: KVM issues with dump
On Fri, Jul 6, 2012 at 4:40 PM, Phong X Nguyen wrote: > On 6 Jul 2012, at 1516, Todd And Margo Chester wrote: >> On my VM, W7 is still half as fast as XP and ten times less >> stable -- pretty much matches what I see in the field. >> And Lotus Approach, which I use for my business accounting, >> runs worse on W7 than it runs on Wine. >> > Can I get more details about your issues? I routinely run Windows 7 in VMs > (generally VMWare) and get near-native speed for anything except GPU-bound > tasks. It's also rock-solid stable. So I'm curious about your problems you > mention you keep having. > > My general experience (for a fairly broad spectrum of users) is for most > relatively-recent hardware (e.g. >2GB RAM, half-decent IGP, etc.) Windows 7 > is as-fast, faster and a lot more productive than XP (the last due to general > UI improvements). Don't forget that Todd is using "dump" and "restore" for backup. I find them grossly inefficient, and rely on separate cheap media with "rsync" and "rsnapshot" for much faster, more efficient backups and recommend them highly. If you need to preserve SELinux data, Amanda or Zmanda with "star" also works well, and again, is much more efficient than dump and restore.
Re: KVM issues with dump
On 6 Jul 2012, at 1516, Todd And Margo Chester wrote: > On 07/05/2012 05:23 PM, Nico Kadel-Garcia wrote: >> u didn't notice any performance issues with virtualized IDE versus SCSI? > > No difference. This is probably because both drivers are fake. > I presume the SCSI driver is there to accommodate folks that > have code that makes SCSI calls. > > Speaking of fake, it took me years to bend my mind around the fact > that the VM CPUs are fake too. They are not actually using > a particular CPU. It was a light bulb moment. > Well, most operating systems don't have affinity for any particular CPU either, so that's not particularly new? So long as the instructions are properly being dispatched ... > > On my VM, W7 is still half as fast as XP and ten times less > stable -- pretty much matches what I see in the field. > And Lotus Approach, which I use for my business accounting, > runs worse on W7 than it runs on Wine. > Can I get more details about your issues? I routinely run Windows 7 in VMs (generally VMWare) and get near-native speed for anything except GPU-bound tasks. It's also rock-solid stable. So I'm curious about your problems you mention you keep having. My general experience (for a fairly broad spectrum of users) is for most relatively-recent hardware (e.g. >2GB RAM, half-decent IGP, etc.) Windows 7 is as-fast, faster and a lot more productive than XP (the last due to general UI improvements).
Re: KVM issues with dump
On 07/05/2012 05:23 PM, Nico Kadel-Garcia wrote: u didn't notice any performance issues with virtualized IDE versus SCSI? No difference. This is probably because both drivers are fake. I presume the SCSI driver is there to accommodate folks that have code that makes SCSI calls. Speaking of fake, it took me years to bend my mind around the fact that the VM CPUs are fake too. They are not actually using a particular CPU. It was a light bulb moment. XP on laptops is now pretty ugly due to chipset upgrades that just aren't XP supported. Netbooks that have more than enough power for XP are nightmares to install. And for high end server components, like 10G Ethernet, it's also difficult to support. Oh ya. The latest batch of notebooks are a nightmare to install XP on. It is made a lot easier if you only do it on models with Intel chipsets. (Did an AMD XP upgrade from Vista on an HP laptop a couple of years ago. Took me 15 hours. Gad zukes! I could only bill for 3 hours. Never again -- nightmare stuff. On the bright side, it is now the customer's fastest, most reliable computer -- it was completely unusable under Vista.) Here is a tip: call Lenovo tech support and find a model that still has a set of XP restore disks. That is the easiest way. On my VM, W7 is still half as fast as XP and ten times less stable -- pretty much matches what I see in the field. And Lotus Approach, which I use for my business accounting, runs worse on W7 than it runs on Wine. > So yeah, virtualizing XP > is a good way to go if you have to support it. Except that it slows the backups down by a factor of five. Ultimately, on a server, it would probably be Windows 2003 server that I would put in a VM. (They make great Terminal Servers; Windows Server 2008 is an absolute nightmare to run Terminal Services through: five times slower, crash all the time, ...) So, I would need to find it WS2003 did the same backup slowdown, but I can not afford the license to find out. Suppose I will solve that when the need arises. -T
Re: Port puzzle
On Fri, Jul 6, 2012 at 11:24 AM, Anne Wilson wrote: > > OK - I had left the defaults, which it does say is random for the > outgoing port. I've restarted nfs, now I have to wait until Saturday > morning, to see whether tomorrow's log is clean :-) > > Thanks for all the help - I'll report back. You're welcome. If it isn't "clean" it should have an nfs port or nfs ports listed.
Re: Port puzzle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/12 15:55, Tom H wrote: > On Fri, Jul 6, 2012 at 10:29 AM, Anne Wilson > wrote: >> On 06/07/12 14:08, Mark Stodola wrote: >>> On 07/06/2012 04:06 AM, Anne Wilson wrote: Logwatch on my >>> laptop tells me >>> >>> Listed by source hosts: Dropped 30 packets on interface eth0 >>> From 192.168.0.40 - 30 packets to tcp(38575) >>> >>> 192.168.0.40 is a mail/file/print server running SL. It may >>> also be relevant that the laptop has fstab mounts to data areas >>> on the server. >>> >>> I feel that there must be some way I can trace what is >>> actually sending those packets, so that I can make an >>> assessment, but I've no idea how/where to look. I see that >>> it's an unallocated address, so I've no pointer at all. >>> >>> Where should I start looking? >>> >>> Anne >>> >>> If the connection is still active, you can use a combination >>> of 'netstat -na' and/or 'lsof -nP -i4' to find the process >>> owning the connection. If it isn't, it will be difficult to >>> track down without fancier logging/capturing tools. You >>> mentioned remote mounts, but not what method (CIFS, NFS, etc). >>> If it is NFS, pseudo-random ports are chosen for the client >>> connections and may be your culprit. >>> >> It is indeed NFS. The logs show ~6 of these high-number >> allocated ports listening, so you could well be right. Is there >> any way to confirm that? I have several nfs mounts in fstab. >> One for each mount probably explains it. > > If it's ifs, you can set the ports to known values through > "/etc/sysconfig/nfs" and then see whether it's one of these ports > that's used. OK - I had left the defaults, which it does say is random for the outgoing port. I've restarted nfs, now I have to wait until Saturday morning, to see whether tomorrow's log is clean :-) Thanks for all the help - I'll report back. Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/3Aw4ACgkQj93fyh4cnBd24QCfcr4cqyR3CLP0X4y/1SWBZMyh yJ8An1qHrywE2rjfTYQ2OOEISGJmh/Xt =QdqM -END PGP SIGNATURE-
Re: Port puzzle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/12 15:44, Gilberto Ficara wrote: > try adding -p to netstat command line, it will show what > pid/process is using the port (root privileges may be required) # netstat -nap | grep 38575 tcp0 0 0.0.0.0:38575 0.0.0.0:* LISTEN Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/3AUYACgkQj93fyh4cnBd+hgCfZPwqCHOW8wwXwQXKfDqOSk5e 56oAniFtIJrbQHOA6SmGQJCr2yUVbDCn =OC/F -END PGP SIGNATURE-
Re: Port puzzle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/12 15:39, Mark Stodola wrote: > Check with lsof on the laptop what process is listening on that > port. A LISTEN means that it is waiting for a connection, but > nothing is actually actively communicating via that port. The > 0.0.0.0 means it is listening on all interfaces/IP ranges. lsof | grep 38575 returns nothing at all. Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/3AMUACgkQj93fyh4cnBeIuwCeOmEaPMTIwOv3ky1W8XTPM19V GYUAn2j9OTE7qyoT0XQRQqMeZ5osPMjT =1xYG -END PGP SIGNATURE-
Re: Port puzzle
On Fri, Jul 6, 2012 at 10:29 AM, Anne Wilson wrote: > On 06/07/12 14:08, Mark Stodola wrote: >> On 07/06/2012 04:06 AM, Anne Wilson wrote: Logwatch on my laptop >> tells me >> >> Listed by source hosts: Dropped 30 packets on interface eth0 From >> 192.168.0.40 - 30 packets to tcp(38575) >> >> 192.168.0.40 is a mail/file/print server running SL. It may also >> be relevant that the laptop has fstab mounts to data areas on the >> server. >> >> I feel that there must be some way I can trace what is actually >> sending those packets, so that I can make an assessment, but I've >> no idea how/where to look. I see that it's an unallocated >> address, so I've no pointer at all. >> >> Where should I start looking? >> >> Anne >> >> If the connection is still active, you can use a combination of >> 'netstat -na' and/or 'lsof -nP -i4' to find the process owning the >> connection. If it isn't, it will be difficult to track down >> without fancier logging/capturing tools. You mentioned remote >> mounts, but not what method (CIFS, NFS, etc). If it is NFS, >> pseudo-random ports are chosen for the client connections and may >> be your culprit. >> > It is indeed NFS. The logs show ~6 of these high-number allocated > ports listening, so you could well be right. Is there any way to > confirm that? I have several nfs mounts in fstab. One for each mount > probably explains it. If it's ifs, you can set the ports to known values through "/etc/sysconfig/nfs" and then see whether it's one of these ports that's used.
Re: Port puzzle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2012 04:29 PM, Anne Wilson wrote: > On 06/07/12 14:08, Mark Stodola wrote: >> On 07/06/2012 04:06 AM, Anne Wilson wrote: Logwatch on my laptop >> tells me > >> Listed by source hosts: Dropped 30 packets on interface eth0 From >> 192.168.0.40 - 30 packets to tcp(38575) [snip] >> If the connection is still active, you can use a combination of >> 'netstat -na' and/or 'lsof -nP -i4' to find the process owning the >> connection. If it isn't, it will be difficult to track down >> without fancier logging/capturing tools. You mentioned remote >> mounts, but not what method (CIFS, NFS, etc). If it is NFS, >> pseudo-random ports are chosen for the client connections and may >> be your culprit. > > It is indeed NFS. The logs show ~6 of these high-number allocated > ports listening, so you could well be right. Is there any way to > confirm that? I have several nfs mounts in fstab. One for each mount > probably explains it. > > netstat -na | grep 38575 tells me that it is listening: > > on the laptop: > tcp0 0 0.0.0.0:38575 0.0.0.0:* > LISTEN > > but doesn't give me any clue as to what it hears :-) try adding -p to netstat command line, it will show what pid/process is using the port (root privileges may be required) Gilberto - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP9vm2AAoJEFs07fyVhi0AWikP/RNIVxFOYk4V9K2YmlbgX21u NAYA8OjXrTzcyrI1lcI+y+ZE2Mt3HnwUgYRR1tW9zAYZcKmPYneWZH/bvuXsKz5K pCLPDjTNQiXYSPW65qMEeRxsSvzDcGPmFL7Q7bgUOpu5AhhzVeTXI0zXTAJjWMlH zmII+Ifk+dcjUaY9q14JW6EmPrPKoFihOZ1VcKLAQAtEYmR70o5+nLpbFksCFi7v pim3xgTU3OIcJ1wAnRXWtsBPV2TAmpXxWIn7jftmQl5xQ082zVPKQN0wyQWCXwNr xtGr5ALnGS4KdeFede4aunJkTF2fw/0qy16JULO5sUTlzYZDTgNr5jt9Muy9nvc5 XIBNldbPRyUQ2BHyVK/OPg8ktf/BDiBvTh/c+e4LCjp7hUTLuMl6gMh/ZMI/rEHy 17oc99y4YpssnEiH1O1qAcaIO4dWrVL61mQl1p0ebVRD7OW5vYJ5PyLAAzxzyeQ+ hgzOzTWiOkFZOX+g4NSiv1lvtfxlyOuWzf2Axl0R/jXoFwUjV+ZECHiCcTj1xQe8 U/nFI/HIOvnRILhstV0LxifZq8vLUPw7EiQxdoEPjaCmzzN7eNmie4ZpaVuoAgju 5J67rrQ5JPOdbd0u6cZJFUlBuVCqDooZid0AXOkzUj/wD43HcNjKMc6NpRbAxZp9 Bsfvx55CjqqtX82UtosH =KSTl -END PGP SIGNATURE-
Re: Port puzzle
On 07/06/2012 09:29 AM, Anne Wilson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/12 14:08, Mark Stodola wrote: On 07/06/2012 04:06 AM, Anne Wilson wrote: Logwatch on my laptop tells me Listed by source hosts: Dropped 30 packets on interface eth0 From 192.168.0.40 - 30 packets to tcp(38575) 192.168.0.40 is a mail/file/print server running SL. It may also be relevant that the laptop has fstab mounts to data areas on the server. I feel that there must be some way I can trace what is actually sending those packets, so that I can make an assessment, but I've no idea how/where to look. I see that it's an unallocated address, so I've no pointer at all. Where should I start looking? Anne If the connection is still active, you can use a combination of 'netstat -na' and/or 'lsof -nP -i4' to find the process owning the connection. If it isn't, it will be difficult to track down without fancier logging/capturing tools. You mentioned remote mounts, but not what method (CIFS, NFS, etc). If it is NFS, pseudo-random ports are chosen for the client connections and may be your culprit. It is indeed NFS. The logs show ~6 of these high-number allocated ports listening, so you could well be right. Is there any way to confirm that? I have several nfs mounts in fstab. One for each mount probably explains it. netstat -na | grep 38575 tells me that it is listening: on the laptop: tcp0 0 0.0.0.0:38575 0.0.0.0:* LISTEN but doesn't give me any clue as to what it hears :-) On the server, lsof -nP -i4 doesn't show anything that I can identify as the culprit. Most of the tcp activity comes from either rpc.statd and related files of dovecot IMAP. Mail is checked every 5 minutes during working hours, so if it is that, I would expect to see more consistent drops. What do you think? Am I making false assumptions? Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/29mUACgkQj93fyh4cnBcqiwCgi5+O73h4f8GDG/geFSrhgNk/ hcUAniqupT8kIhfZ339okypDaVvrR49T =gGsJ -END PGP SIGNATURE- Check with lsof on the laptop what process is listening on that port. A LISTEN means that it is waiting for a connection, but nothing is actually actively communicating via that port. The 0.0.0.0 means it is listening on all interfaces/IP ranges. -- Mr. Mark V. Stodola Senior Control Systems Engineer National Electrostatics Corp. P.O. Box 620310 Middleton, WI 53562-0310 USA Phone: (608) 831-7600 Fax: (608) 831-9591
Re: Port puzzle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/07/12 14:08, Mark Stodola wrote: > On 07/06/2012 04:06 AM, Anne Wilson wrote: Logwatch on my laptop > tells me > > Listed by source hosts: Dropped 30 packets on interface eth0 From > 192.168.0.40 - 30 packets to tcp(38575) > > 192.168.0.40 is a mail/file/print server running SL. It may also > be relevant that the laptop has fstab mounts to data areas on the > server. > > I feel that there must be some way I can trace what is actually > sending those packets, so that I can make an assessment, but I've > no idea how/where to look. I see that it's an unallocated > address, so I've no pointer at all. > > Where should I start looking? > > Anne > > If the connection is still active, you can use a combination of > 'netstat -na' and/or 'lsof -nP -i4' to find the process owning the > connection. If it isn't, it will be difficult to track down > without fancier logging/capturing tools. You mentioned remote > mounts, but not what method (CIFS, NFS, etc). If it is NFS, > pseudo-random ports are chosen for the client connections and may > be your culprit. > It is indeed NFS. The logs show ~6 of these high-number allocated ports listening, so you could well be right. Is there any way to confirm that? I have several nfs mounts in fstab. One for each mount probably explains it. netstat -na | grep 38575 tells me that it is listening: on the laptop: tcp0 0 0.0.0.0:38575 0.0.0.0:* LISTEN but doesn't give me any clue as to what it hears :-) On the server, lsof -nP -i4 doesn't show anything that I can identify as the culprit. Most of the tcp activity comes from either rpc.statd and related files of dovecot IMAP. Mail is checked every 5 minutes during working hours, so if it is that, I would expect to see more consistent drops. What do you think? Am I making false assumptions? Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/29mUACgkQj93fyh4cnBcqiwCgi5+O73h4f8GDG/geFSrhgNk/ hcUAniqupT8kIhfZ339okypDaVvrR49T =gGsJ -END PGP SIGNATURE-
Re: Port puzzle
On 07/06/2012 04:06 AM, Anne Wilson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Logwatch on my laptop tells me Listed by source hosts: Dropped 30 packets on interface eth0 From 192.168.0.40 - 30 packets to tcp(38575) 192.168.0.40 is a mail/file/print server running SL. It may also be relevant that the laptop has fstab mounts to data areas on the server. I feel that there must be some way I can trace what is actually sending those packets, so that I can make an assessment, but I've no idea how/where to look. I see that it's an unallocated address, so I've no pointer at all. Where should I start looking? Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/2qpMACgkQj93fyh4cnBeQlQCggnN/Spo5TubvCrXtCogKVTiJ VWQAnReuFaQpTA9pJOFweO5K40tPBuUM =vRqk -END PGP SIGNATURE- If the connection is still active, you can use a combination of 'netstat -na' and/or 'lsof -nP -i4' to find the process owning the connection. If it isn't, it will be difficult to track down without fancier logging/capturing tools. You mentioned remote mounts, but not what method (CIFS, NFS, etc). If it is NFS, pseudo-random ports are chosen for the client connections and may be your culprit. -Mark -- Mr. Mark V. Stodola Senior Control Systems Engineer National Electrostatics Corp. P.O. Box 620310 Middleton, WI 53562-0310 USA Phone: (608) 831-7600 Fax: (608) 831-9591
Port puzzle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Logwatch on my laptop tells me Listed by source hosts: Dropped 30 packets on interface eth0 From 192.168.0.40 - 30 packets to tcp(38575) 192.168.0.40 is a mail/file/print server running SL. It may also be relevant that the laptop has fstab mounts to data areas on the server. I feel that there must be some way I can trace what is actually sending those packets, so that I can make an assessment, but I've no idea how/where to look. I see that it's an unallocated address, so I've no pointer at all. Where should I start looking? Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/2qpMACgkQj93fyh4cnBeQlQCggnN/Spo5TubvCrXtCogKVTiJ VWQAnReuFaQpTA9pJOFweO5K40tPBuUM =vRqk -END PGP SIGNATURE-
