Portsnap no updates since 3/31/2021 ?
I have several servers running 11.4 and 12.2 that do nightly portsnap updates and the last time they've seen anything new is 3/31/2021, since then, nothing. This seems highly unusual since seems like there was always SOMETHING updated daily now nothing. -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://pgp.inoc.net/rblayzor/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 13.0-RC5 Now Available
I don't know, ask yourself that, you did the same thing On 4/4/21 6:21 PM, Glen Barber wrote: Is it necessary to quote the*entire* email (including checksums)? Glen Sent from my phone. Please excuse my brevity and/or typos. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS...
On 4/29/19 8:41 PM, Michelle Sullivan wrote: >> 2) Backups are essential with any filesystem, not just ZFS. After >> all, no amount of RAID will protect you from an accidental "rm -rf /". That's what snapshots are for! ;-) -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
igb now em driver in FreeBSD 12.0
Reading the release notes, the igb driver has been merged into the Intel em driver so that should be added to custom kernels. No problem. Question is, when the system reboots, are the NIC devices going to come up with "emX" now or will they remain "igbX" ? Kind of important to know on remote upgrading a server... -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Clock occasionally jumps backwards on 11.1-RELEASE
On Jan 22, 2018, at 12:07 PM, Alan Somers wrote: > > * Sometimes the jumps happen immediately after ntpd adds a new server to > its list, but not always. > > * I'm using the default ntp.conf file. > > * ntpd is running on both, and it should be the only process touching the > clock. I have a script running "ntpq -c peers" once a minute, which shows > the offset for one server suddenly jump to a large negative number. Then > the offsets for other servers jump to the same value, then either ntpd > fixes the clock or exits because the offset is too high. - Lose ntpd running in jails and run it only on the host. Running in the jail is totally unnecessary. - Is this a bare metal server or VM? Lots of clock issues with VM’s… - Stagger your periodic jobs on the host and the jail so they don’t all run at the same time slamming the host. -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CARP master election changed in 11.0 ?
Disregard, this problem has been semi-solved. For reasons unknown now it was due to carp send error penalties being applied to one of the servers, which are added to the advskew. Since a lagg interface is involved: carp: demoted by 10 to 10 (send error 50 on lagg0) carp: demoted by 10 to 20 (send error 50 on lagg0) But what is strange is that the two servers in the VHID have the same exact hardware. Experiencing this send error on one but not the other… Ultimately the work around was adjusting net.inet.carp.senderr_demotion_factor -> 10 From it’s default of 240. Since these errors appear only at startup and not incrementing, it doesn’t really look like a problem. net.inet.carp.ifdown_demotion_factor: 240 net.inet.carp.senderr_demotion_factor: 10 net.inet.carp.demotion: 20 -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu > On Dec 1, 2016, at 3:10 PM, Robert Blayzor wrote: > > Did something change between 10.x and 11.0 with carp MASTER election and > advskew? > > I have several 10.3 servers where the master is elected based on the member > with the LOWEST advskew. > > From a pair of 10.3 servers: > > vlan: 100 parent interface: lagg0 > carp: MASTER vhid 10 advbase 1 advskew 100 > > vlan: 100 parent interface: lagg0 > carp: BACKUP vhid 10 advbase 1 advskew 110 > > > Deploying a new pair of 11.0-RELEASE servers, I see the opposite; seems like > the member with the HIGHEST advskew wins now: > > >carp: BACKUP vhid 20 advbase 1 advskew 0 > groups: lagg > > carp: MASTER vhid 20 advbase 1 advskew 100 > groups: lagg > > > > Preemption doesn’t seem to matter, even with preemption enabled. (which it > is). > > From OpenBSD, man reads: > > advskew > This optional parameter specifies how much to skew the advbase when sending > CARP advertisements. By manipulating advskew, the master CARP host can be > chosen. The higher the number, the less preferred the host will be when > choosing a master. The default is 0. Acceptable values are from 0 to 254. > > > And this seems true in 10.3 but reversed in 11.0 ? > > -- > inoc.net!rblayzor > XMPP: rblayzor.AT.inoc.net > PGP Key: 78BEDCE1 @ pgp.mit.edu > > > > > > > > > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
CARP master election changed in 11.0 ?
Did something change between 10.x and 11.0 with carp MASTER election and advskew? I have several 10.3 servers where the master is elected based on the member with the LOWEST advskew. From a pair of 10.3 servers: vlan: 100 parent interface: lagg0 carp: MASTER vhid 10 advbase 1 advskew 100 vlan: 100 parent interface: lagg0 carp: BACKUP vhid 10 advbase 1 advskew 110 Deploying a new pair of 11.0-RELEASE servers, I see the opposite; seems like the member with the HIGHEST advskew wins now: carp: BACKUP vhid 20 advbase 1 advskew 0 groups: lagg carp: MASTER vhid 20 advbase 1 advskew 100 groups: lagg Preemption doesn’t seem to matter, even with preemption enabled. (which it is). From OpenBSD, man reads: advskew This optional parameter specifies how much to skew the advbase when sending CARP advertisements. By manipulating advskew, the master CARP host can be chosen. The higher the number, the less preferred the host will be when choosing a master. The default is 0. Acceptable values are from 0 to 254. And this seems true in 10.3 but reversed in 11.0 ? -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: LAGG and Jumbo Frames
If your lag interface is up, what’s not working? Does something like this work? ping -D -s 8972 and then this not? ping -D -s 8972 If your firewall is on the LAN side supporting jumbo frames ok, but not WAN side, then the router will have to fragment all of the packets. (unless DF bit is set of course). -- Robert inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu > On Sep 19, 2016, at 3:23 PM, Dean E. Weimer wrote: > > Does anyone see an issue with the Jumbo Frames setup above, or are Jumbo > Frames not supported correctly in a LACP Aggregate configuration. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Failed to write core file (error 14)
On May 19, 2016, at 12:42 PM, Erik wrote: > > This sounds like: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204426 > and > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204764 > > > This problem exists since 10.2. > 10.1 is fine. The bug actually exists in 10.1 as well, at least from what I experienced; it just happened “less”. Something in 10.2 agitated so the problem happened more frequently. I can confirm that it did not exist in 10.0 however. Even with the fix from Bug 204426, I started experiencing some other strange issues reported in: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209471 A process seems to get stuck in state “vmf_de”. (from the patch). I’m just having a hard time consistently recreating the problem. I’m not sure what causes it or when. -- Robert inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD STABLE_10 (10.3) - lots of IPv6 connections in CLOSED state
Started seeing a ton of these in dmesg: sonewconn: pcb 0xf8001570f188: Listen queue overflow: 301 already in queue awaiting acceptance (41 occurrences) sonewconn: pcb 0xf8001570f188: Listen queue overflow: 301 already in queue awaiting acceptance (45 occurrences) sonewconn: pcb 0xf8001570f188: Listen queue overflow: 301 already in queue awaiting acceptance (41 occurrences) sonewconn: pcb 0xf8001570f188: Listen queue overflow: 301 already in queue awaiting acceptance (39 occurrences) sonewconn: pcb 0xf8001570f188: Listen queue overflow: 301 already in queue awaiting acceptance (42 occurrences) sonewconn: pcb 0xf8001570f188: Listen queue overflow: 301 already in queue awaiting acceptance (40 occurrences) sonewconn: pcb 0xf8001570f188: Listen queue overflow: 301 already in queue awaiting acceptance (44 occurrences) sonewconn: pcb 0xf8001570f188: Listen queue overflow: 301 already in queue awaiting acceptance (43 occurrences) sonewconn: pcb 0xf8001570f188: Listen queue overflow: 301 already in queue awaiting acceptance (38 occurrences) The process normally listening, the service stopped working. (manage-sieve, TCP port 4190)… After looking at netstat I see 300+ connections on this service in a “CLOSED” state… All of the connections are via IPv6. Sockstat shows all of these connections not related to a user, command, pid, etc…. If I restart the process, all of the connections are freed and things work as expected for a while. sockstat USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS ?? ? ? tcp6 dead:beef:110:2::1:0:25 dead:beef:110:2::f:0:24162 ?? ? ? tcp6 dead:beef:110:2::1:0:110 dead:beef:110:2::f:0:1566 ?? ? ? tcp6 dead:beef:110:2::1:0:25 dead:beef:110:2::f:1:30064 ?? ? ? tcp6 dead:beef:110:2::1:0:143 dead:beef:110:2::f:0:7199 ?? ? ? tcp6 dead:beef:110:2::1:0:110 dead:beef:110:2::f:1:48062 ?? ? ? tcp6 dead:beef:110:2::1:0:143 dead:beef:110:2::f:1:54271 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:36446 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:57291 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:48429 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:56473 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:61870 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:5971 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:64942 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:46824 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:14230 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:34070 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:24494 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:43982 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:38576 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:13346 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:46491 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:57936 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:3863 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:52049 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:45212 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:43416 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:56373 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:51448 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:51996 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:52523 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:19061 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:41591 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:5 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:47299 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:18115 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:64664 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:0:31583 ?? ? ? tcp6 dead:beef:110:2::1:0:4190 dead:beef:110:2::f:1:24094 ?
Re: ZFS out of swap space
On Mar 25, 2015, at 11:08 AM, armonia wrote: > -- Hello. Please help . I mirror ZFS 9.3 , after an active it by using mysql > read \ write from an external script something broken. The operating system > is not loaded at the time of "Mount local filesystems" > > pool consists of a mirror (raid 1 ) + hot swap, zfs partitions on a separate . > > zpool import -f -R /tmp zroot freezes Where is your swap partition? My guess is you are hitting swap because you need to tune vfs.zfs.arc_max to allow room for the OS and any running applications. If you do not set arc_max then ZFS will basically consume all RAM save for about 1GB for the OS and any apps. Maybe something like the following to /boot/loader.conf may help... (or not) vfs.zfs.arc_max="2G" -- Robert inoc.net!rblayzor http://inoc.net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pxeboot with jumbo frame network
On Jul 23, 2012, at 1:58 PM, Bob Healey wrote: > I know I have this working, however I don't remember what I did. I know I > can pxeboot and install RHEL on a 9K frame network from a FreeBSD tftp > server/NAT gateway. I do know the first thing in my RHEL install script is > to set the MTU to 9K. > If I have a chance later today, I'll dig into one of my install servers and > try to figure out what options I used with DHCP to get it working. The trick is setting the boot time options on the client. The server side (TFTP server) is the easy part as it's already setup and running. But if the client boots and it's not jumbo frame enabled, TFTP will surely hang on getting the PXEboot as the server will be trying to send 9K UDP frames to a client that's probably defaulted to 1500. If there is a DHCP option to set the client MTU, I've not found it anywhere. -- Robert Blayzor INOC, LLC rblay...@inoc.net http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
pxeboot with jumbo frame network
Is it possible to PXEboot a diskless client with an MTU higher than 1500 (Ie: 9k) ? The network we currently boot several diskless machines from has a lot of NFS traffic and we'd like to enable them all for larger MTU's however the one thing stopping us is the issue with initial boot seemingly only supporting an MTU of 1500. I know we can set the MTU later (post boot) on the diskless machines, but it doesn't seem we can run a higher MTU on the TFTP server as we'd have TFTP UDP traffic with mis-matched frame sizes at that point. -- Robert Blayzor INOC, LLC rblay...@inoc.net http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em0 watchdog timeouts
On Oct 2, 2009, at 4:36 PM, Rudy wrote: Today, I set net.inet.ip.fw.enable=0 and I'll see if that helps. I have a feeling that isn't related to the NIC at all, but I'm not sure what else to try. Just curious, have you tried (or are you using) device polling? -- Robert Blayzor, BOFH INOC, LLC rblay...@inoc.net http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD and iSCSI for disks.
On Apr 7, 2009, at 5:43 PM, Garance A Drosihn wrote: Some friends of mine are looking at the new "DroboPro", which makes a lot of disk space available via iSCSI (in addition to firewire 800), and they were wondering how well iSCSI works with FreeBSD. I haven't paid attention to iSCSI support. Is there anyone using it heavily for disk-storage under FreeBSD? Has there been much changed for iSCSI support in the 8.x branch, or is 7.x support working fine? If you're looking for "production ready" iSCSI initiator support in FreeBSD, do yourself a favor, save some time, and look into something else. Seriously, we went down this road just recently testing both FreeBSD 7.0/7.1 amd64 on various Dell servers with Intel (em) Gig-E NIC's and it was very easy to basically get the box to lock up solid and/or panic. Our targets were both Netapp and Equallogic iSCSI SAN's. We didn't have a lot of time to debug it, our setup was pretty simple.. yet when we tried to run various simulated real world load on it the boxes just caved. Even with jumbo frames enabled on the NIC's the performance was mediocre at best. Unfortunately due a time constraint we had to move the clients to CentOS 5.2/5.3 and things have been very good so far. I was hoping that FreeBSD's iSCSI support was a bit more solid, or at least hoping that the (isp) driver had support for the QLogic iSCSI HBA's... no luck. YMMV -- Robert Blayzor, BOFH INOC, LLC rblay...@inoc.net http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD-6.x/7.x 1000BaseTX connection problem
On Jan 27, 2009, at 3:49 AM, Steven Hartland wrote: We have never had a problem with FreeBSD and Cisco using em and bge. They do take a while to come up but that's just Cisco being Cisco. By default all ports participate in spanning-tree, which is probably any delay you're seeing. You can setup host ports by explicitly setting them up as access ports and then turning on "spanning-tree portfast". That makes the ports come up almost immediately. I've never had a problem with Intel (em/fxp) or Broadcom (bge/bce) using auto-neg on any Cisco switch made in the last 8-10 years. -- Robert Blayzor, BOFH INOC, LLC rblay...@inoc.net http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Big problems with 7.1 locking up :-(
On Jan 8, 2009, at 8:58 PM, Pete French wrote: I have a number of HP 1U servers, all of which were running 7.0 perfectly happily. I have been testing 7.1 in it's various incarnations for the last couple of months on our test server and it has performed perfectly. I noticed a problem with 7.0 on a couple of Dell servers. Not sure if this is related but when our system "froze" the box was pingable, and you could switch virtual consoles... however, you could not type anything on the screen or connect to any sockets. Num-lock would still work so the box wasn't solidly frozen. This used to happen a couple of times every week or two. We've since then compiled the kernel under the BSD scheduler to rule that out, and so far so good. (our box was a Dell PE1750, 2GB of RAM, amr RAID controller, bge network driver) The primary application was just ntpd and apache with mpm_worker & threads. Since ULE is now default in 7.1 and not in 7.0, perhaps you can try that? -- Robert Blayzor, BOFH INOC, LLC rblay...@inoc.net http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
BOOTP and no default route
Is there any way to prevent the BOOTP client from injecting a default route? When I originally set things up our DHCP server would not send a default route because there was no gateway, local only. If you leave out the default route, the server will try proxy-arp when ends up putting a default route to itself in the routing table. The problem is that on startup the servers actually setup static networks with default routes out another interface. The problem is, if the BOOTP client puts in a default route, we cannot easily add another default because one already exists. The only way I've found around this behavior was to error the BOOTP client out and send it a default gateway that does not exist on the local net the DHCP server provides. This causes the BOOTP client not to set a default route and all works fine. Obviously this seems like a cobb/hack and was wondering if there was a BOOTP option or kernel tweak that can be done to tell the BOOTP client not to use proxy-arp. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 30, 2008, at 3:17 PM, Doug Barton wrote: I'm not sure why, but I sense hostility on your part. I'm not sure why, since that is an odd reaction to someone who is trying to help you. If I'm wrong about that, never mind. I'm not being hostile, geez. ;) I simply asked "why not"? Plenty of people do it, and with good reason. It's always been effective, if this is some sort of an IPFW load issue, then surely I concede your point to use an external firewall, which I can do with basic external router ACL's. A basic rule of system administration is to have a good reason for everything you do. If you have some kind of need for a firewall on your web server, that's fine. Personally I prefer not to run firewalls on application servers, but TIMTOWTDI. Of course, but every situation is different. In this case, an external firewall is not available and the application doesn't really require it, so simple IPFW rules are sufficient. The real crux of my question (which you did not answer) is, does the problem go away if you take IPFW completely out of the equation? If the answer to that is yes, it greatly narrows the focus of the investigation. No, turning IPFW off does not make the problem go away. I originally thought of this when the issue came up. I've tried with and without both the http accept filter and IPFW. I think that the theories that have been proposed by others that the FIN_WAITs are a symptom of a problem in the clients is not only possible, it's likely. I'm just not sure it's the complete story. I'm thinking it probably is bad client behavior. I'm leaning toward all of the freshclam clients not handling a network error correctly. It's quite possible when something in the connection fouls up the client, it just behaves badly. I don't know much about how freshclam uses sockets, I'm trying to figure that out now. (if they use some native code, http library, etc). It not might even be that at all, but it's a good starting point. The other half of the story however is if it's that easy to hose up TCP sockets on a server, that's a bigger problem IMHO. :-/ -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 30, 2008, at 12:43 PM, Matthew Dillon wrote: I would be very careful with any type of ruleset (IPFW or PF) which relies on keep-state. You can wind up causing legitimate connections to drop if it isn't carefully tuned. Thanks again Matt... I do agree on the firewall and keep-state and scaling issue. It wasn't the magic bullet I thought it may have been. The stuck connections just dropped off due to the load dropping at night. The bandaid I have is the tcpdrop hack that was posted here. That seems to clear all the stuck sessions. While it's probably not the best thing to do, it protects the server at least. I don't know what more to do at this point. While these may be broken client issues, it's breaking the server. I don't know if it makes sense to push something upstream to see if some type of knob can be implemented into the network stack to force close/drop these or to just let it go and deal with it as-is. I have a message into the clamav-devel list to see if this is a problem on the freshclam client and the way it handles closing connections/broken connections. It's quite possible it's something broken in freshclam where it's failing to deal with a network failure properly -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 30, 2008, at 4:41 AM, Ian Smith wrote: Without debating your stateful alternative - either should work fine for TCP applications - this allowed inbound icmp packets for types 0,3,8,11 but no outbound icmp at all (assuming your firewall defaults to deny). Switching the ipfw rules over to be stateful did not help, the server just wasn't busy enough. Overnight the FIN_WAIT_1's continued to pile up to over 600... and I'm sure they'll just keep going up until I have to reboot the box again. However Tod's suggestion to use a small sh script and tcpdrop seems to at least put a band-aid on things, so I don't have to reboot now. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 30, 2008, at 4:18 AM, Tod McQuillin wrote: This relies on tcpdrop, included as /usr/sbin/tcpdrop on FreeBSD 6.x; you may need to install it from a port on FreeBSD 4.x. Thanks, that seems like a reasonable "band aid" for now. Worked perfectly. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 30, 2008, at 4:47 AM, David Malone wrote: There has been some talk about this sort of problem on the IETF TCP Maintainers list. I don't think any good conclusion was reached - whatever the solution was certainly needs to be tunable per-socket because this behaviour is perfectly valid in some situations but a bit of a pain in others. A timeout value would be fine. Obviously if the client keeps sending back packets with a 0 size, there should be some option or work around to tell the stack to drop the connection. There than to have the server lock up resources on a "dead connection". Unfortunately we're talking about the internet here, we can't insure that every one of the clients connecting to our servers behaves correctly! ;-) On a side note, I could easily fix this problem by frontending the server with a Cisco PIX or ASA. I believe they have "half closed" timers just for this purpose... Perhaps a kernel tunable knob would be a nice option/fix/hack also. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 30, 2008, at 4:41 AM, Ian Smith wrote: Without debating your stateful alternative - either should work fine for TCP applications - this allowed inbound icmp packets for types 0,3,8,11 but no outbound icmp at all (assuming your firewall defaults to deny). I didn't post all the rules, just the TCP based ones for the web server. I don't have an outbound send restriction. I believe I have a: permit ip from me to any out In there somewhere! ;-) -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 29, 2008, at 11:07 PM, Doug Barton wrote: Hrrm, are you running ipfw ON the web server box? If so, I'd be curious as to why, and whether or not the problem goes away if you take IPFW out of the equation. If IPFW is running on another machine, never mind. Yes, IPFW is running on the box. Why not? -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 29, 2008, at 8:55 PM, Matthew Dillon wrote: It's got to a be a bug on the client(s) in question. I can't think of anything else. You may have to resort to injecting a TCP RST packet (e.g. via a TUN device) to clear the connections. That would be most unpleasant... and also seems like some sort of exploit if a client and run a server out of socket buffers so easily. On a side note, I may be onto something... The server traffic right now is calming down, but it picks up... I made a change to the IPFW rules which basically went from something like: 100 permit tcp from any to any established 200 permit tcp from any to me 80 setup 300 deny log ip from any to me to: 100 check-state 150 deny tcp from any to any established 200 permit tcp from any to me 80 setup keep-state 300 deny log ip from any to me While the traffic is lower now, I don't see the FIN_WAIT_1's going up like I did before. At least I'm not going to count my chickens before they hatch. I'm going to watch this over the next 24 hours and see what comes up. Unfortunately if it doesn't end up being part of the solution I may have to resort to running some flavor of Linux 2.6 (*sob*). -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 29, 2008, at 5:32 PM, Matthew Dillon wrote: Now, the connection is also in a half-closed state, which means that one direction is closed. I can't tell which direction that is but my guess is that 1.1.1.1 (the apache server) closed the 1.1.1.1- >2.2.2.2 direction and the 2.2.2.2 box has a broken TCP implementation and can't deal with it. This is exactly what we're seeing, it's VERY strange. I did kill off Apache, and all the FIN_WAIT_1's stuck around, so the kernel is in fact sending these probe packets, every 60 seconds, which the client responds to... (most of the time). I can suggest two things. First, the TCP connection is good but you still may be able to tell Apache, in the apache configuration file, to timeout after a certain period of time and clear the connection. I don't think this helps since Apache sees the connection as long gone. As far as Apache is concerned (as far as I can tell), this connection doesn't exist. This may be proved by killing off Apache, the connection still lives and while Apache is running, I have the max clients connected most of the time... so I don't think the linger around and jam up sockets to Apache. If they did, I think Apache would spiral down quite quickly. Secondly, it may be beneficial to identify exactly what the client and server were talking about which caused the client to hang with a live tcp connection. The only way to do that is to tcpdump EVERYTHING going on related to the apache srever, save it to a big-ass disk partition (like 500G), and then when you see a stuck connection go back through the tcpdump log file and locate it, grep it out, and review what exactly it was talking about. You'd have to tcpdump with options to tell it to dump the TCP data payloads. Unfortunately it's not possible for me, not nearly enough space. This is a VERY busy server, a spikey 20Mbps+ (8-12Mbps on average) of web traffic almost constantly. The traffic is VERY static, just small data files and occasional large ones (12Mb+), but the majority are 2-5k files. (it's a clamav mirror server) It seems likely that the client is running an applet or javascript that receives a stream over the connection, and that applet or javascript program has locked up, causing the data sent from the server to build up and for the client's buffer space to run out, and start advertising the 0 window. 98% of the clients are clamav (freshclam) clients on various platforms. Using p0f most of them are various flavors of Linux, but I can't say what OS the clients are connecting to for sure since I'd have to look at the OS finger print of the SYN packets... Don't get me wrong, the server keeps up well, low CPU, lots of RAM free, lots of network available, and 99% of all HTTP connections are completed just fine. I just see these FIN_WAIT_1 connections build up over time until the server runs out of socket space and then things just stop working. Only way to correct it seems to reboot the server... even under RELENG_7_0 so the upgrade from 4_11 did not fix the problem. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 29, 2008, at 3:30 PM, Matthew Dillon wrote: It is quite possible that the other ends of the connection are still live and that the issue could very well be a timeout setting in the server config file instead of something in the TCP stack. I think we're onto something here, but for some reason it doesn't make any sense. I have keepalives turned OFF in Apache: In the OS I have: net.inet.tcp.keepidle: 90 net.inet.tcp.keepintvl: 3 net.inet.tcp.keepinit: 75000 net.inet.tcp.always_keepalive: 1 I see FIN_WAIT_1 connections collecting like crazy again. I managed to investigate one that's been hung around for several minutes. 1.1.1.1 = our server ip 2.2.2.2 = remote client ip [mirror0:/usr/local/etc/apache22] netstat -an | grep 2.2.2.2 tcp4 0 25861 1.1.1.1.80 2.2.2.2.33379 FIN_WAIT_1 When I tcpdump this, I see something sending ack's back and forth every 60 seconds, but what? Apache? I'm not sure why. I don't see any timeouts in Apache for ~60 seconds. As you can see, sometimes we send an ack, but never see a reply. I'm gathering the OS level keepalives don't come into play because this session is not considered idle? 0:13:07.640426 IP 1.1.1.1.80 > 2.2.2.2.33379: . 4208136508:4208136509(1) ack 1471446041 win 520 3019088951 5004131> 20:13:07.736505 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:14:07.702647 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:15:07.764920 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:15:07.860988 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:16:07.827262 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:16:07.923341 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:17:07.889690 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:17:07.984770 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:18:07.952167 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:18:08.048249 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:19:08.014715 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:19:08.110803 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:20:08.077321 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:21:08.139995 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:21:08.236063 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:22:08.202435 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:22:08.297499 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 20:23:08.264631 IP 1.1.1.1.80 > 2.2.2.2.33379: . 0:1(1) ack 1 win 520 20:23:08.360700 IP 2.2.2.2.33379 > 1.1.1.1.80: . ack 0 win 0 I'm finding several of these sessions doing the same exact thing -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 29, 2008, at 3:30 PM, Matthew Dillon wrote: It is quite possible that the other ends of the connection are still live and that the issue could very well be a timeout setting in the server config file instead of something in the TCP stack. Good point, I didn't think about this, but once i started getting over 1000 of these and it just kept growing, I started to rule it out, but I won't this time. I've moved the server over to 7.0 now which is taking load. I'm already thinking this problem is NOT fixed and is the same behavior as in 4.x because I'm seeing quite a few FIN_WAIT_1's collect now. [mirror0:~] netstat -an | grep FIN_WAIT_1 | wc -l I set the keepalive lower as I've mentioned, 15 mins and 30 sec intervals... I'll see if I have any specifically that stick around for a while and I'll try dumping one of those sessions and see -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 29, 2008, at 3:12 PM, Matthew Dillon wrote: I guess nobody mentioned the obvious thing to check: Make sure TCP keepalive is turned on. sysctl net.inet.tcp.always_keepalive=1 Thanks Matt. I also thought that a keepalives were not running and sessions just stuck around forever, however I do have: net.inet.tcp.keepidle=90 net.inet.tcp.keepintvl=3 net.inet.tcp.msl=5000 net.inet.tcp.always_keepalive=1 (default) I believe keep idle was defaulted to 2hrs, I changed it to 15 minutes with a 30 second tick... I still found FIN_WAIT_1 sessions stuck for several hours, if not infinite. Nonet he less, I have a new server up running 7.0-p1, I'll be pumping a lot of traffic to that box soon and I'll see how that makes out. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 29, 2008, at 8:44 AM, Stephen Clark wrote: You know it really pains me when people blithely say just upgrade to X.X where X is the latest release. It is generally just not that simple to upgrade - there are all sorts of dependencies with other software that have to be considered. I don't mind upgrading this box, it does need it, and it's just a web server. But I see your point. What bothers me is that suggesting an upgrade "may" fix the problem. I really want to know that upgrading WILL fix the problem. I know it might not hurt, but if it doesn't address the primary issue at hand, I can spend time and resources trying to figure out why. Regardless since this is just a mirror web server, I'm going to run it on box using 7.0 and see what I get. I realize a lot of network code has changed from 4.x to 6.x (and maybe 7.x) so I'm going to give that a go. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 28, 2008, at 6:55 PM, Doug Barton wrote: That's a known problem with FreeBSD 4, which is now well past EOL. I would suggest moving to FreeBSD 7 ASAP. Is it? I searched and searched and never found any hits or PR's regarding this. When was it first fixed? 5.x? 6.x? or not until 7? -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sockets stuck in FIN_WAIT_1
On May 28, 2008, at 6:43 PM, Chuck Swiger wrote: You didn't mention which version of FreeBSD you are running-- that's rather important info. Actually, I just checked, this is a 4.11 server, I thought it was running at least 6.2. 00200 allow tcp from any to me 80 setup 00200 allow icmp from any to me icmptype 0,3,8,11 00200 deny log ip from any to me Also, surely these can't be the only IPFW rules you are using? If you want to use stateful rules, you need a keep-state argument, and you shouldn't be combining allow rules and deny rules into the same ruleset number... Right, I have a : 00100 allow tcp from any to any established in there as well, but noted on the later part. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Sockets stuck in FIN_WAIT_1
I have a rather busy Apache 2.2 server; tons of small & some large requests. It's a standard Dell 2650 server using the bge (broadcom) network driver. I seem to have a rather strange problem where after just a day or so Apache just stops processing new connections. You can connect to port 80, but trying to get Apache to process any data just hangs. There is nothing strange in dmesg or in /var/log/messages. The server has plenty free available physical RAM, swap is untouched, CPU load is low, etc. Apache is setup to handle a max of 100 clients using prefork model. If I stop and restart Apache, it does not help. What I do notice is 1000's of sockets stuck in "FIN_WAIT_1" in netstat: [web0:~] netstat -an | grep FIN_WAIT | wc -l 1827 These stick around forever. Some eventually trickle away after hours, but the only thing that appears to fix it is to reboot the server. Then all is fine for another day or so. I've tried just about every tuning trick out there but to no eval. I can mitigate the problem by increasing available socket buffs and decreasing the tcp.sendspace. I've tried different versions of Apache and I've tried with and without the accf_http kernel filter. Here is what I have on the server now: sysctl.conf: kern.maxfiles=65535 kern.maxfilesperproc=16384 kern.ipc.maxsockbuf=4194304 kern.ipc.somaxconn=1024 net.inet.tcp.sendspace=8192 net.inet.tcp.recvspace=8192 net.inet.tcp.keepidle=90 net.inet.tcp.keepintvl=3 net.inet.tcp.msl=5000 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.tcp.inflight_enable=1 and loader.conf accf_http_load="YES" kern.ipc.nmbclusters=32768 net.inet.tcp.tcbhashsize=4096 kern.ipc.maxsockets=131072 ipfw: 00200 allow tcp from any to me 80 setup 00200 allow icmp from any to me icmptype 0,3,8,11 00200 deny log ip from any to me ifconfig: bge0: flags=8843 mtu 1500 options=3 inet 1.2.3.4 netmask 0xfff8 broadcast 5.6.7.8 ether 00:06:5b:f7:c8:7b media: Ethernet autoselect (1000baseTX ) Any ideas would be greatly appreciated. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS and /etc/exports
On Apr 14, 2008, at 7:28 PM, Alfred Perlstein wrote: Are -r and -w really needed/useful for TCP mounts? yes. Really? Please explain then, because the mount_nfs man page contradicts this... "Set the read data size to the specified value. It should nor- mally be a power of 2 greater than or equal to 1024. This should be used for UDP mounts when the ``fragments dropped due to timeout'' value is getting large while actively using a mountpoint." and "Set the write data size to the specified value. Ditto the comments w.r.t. the -r option, but using the ``fragments dropped due to timeout'' value on the server instead of the client. Note that both the -r and -w options should only be used as a last ditch effort at improving performance when mounting servers that do not support TCP mounts." -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ Mac OS X. Because making Unix user-friendly is easier than debugging Windows. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS and /etc/exports
On Apr 14, 2008, at 7:02 AM, Nawfal bin Mohmad Rouyan wrote: I'm using TCP and the entry in /etc/fstab on all clients is as below: build:/usr/ports/usr/ports nfs tcp,intr,nfsv3,-w=32768,-r=32768,rw,noauto 0 0 build:/usr/src /usr/srcnfs tcp,intr,nfsv3,-w=32768,-r=32768,rw,noauto 0 0 build:/usr/obj /usr/objnfs tcp,intr,nfsv3,-w=32768,-r=32768,rw,noauto 0 0 Are -r and -w really needed/useful for TCP mounts? -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ Mac OS X. Because making Unix user-friendly is easier than debugging Windows. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 6.2 and booting from iSCSI
The Presence wrote: > 1) I can do a bare-metal restore very simply. > 2) I can easily change base system by just changing the TOE parameters in > BIOS. > 3) I can have multiple systems have access to the same data without having to > have multiple copies of the data, but do this in block mode instead of file > mode. man diskless As for #3 you can do this with a software initiator once the system boots. -- Robert Blayzor INOC [EMAIL PROTECTED] http://www.inoc.net/~rblayzor/ telnet: Unable to connect to remote host: Connection refused ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Strange NFS Client issue
I ran into rather strange NFS client issue today. I had a directory on an NFS mount (client side) appear to have two empty directories in it, but in fact they were not empty. The directories on the NetApp and other NFS clients showed those same directories populated with files. These files are cloned from other locations using rsync if that makes any difference. On the client that showed the strangeness, if I tried to delete the empty directories "rm -r" returned an error stating "directory not empty", still to the client I could not see any files in the directory. Doing a "du -ks" on the top level dir showed other directories full, but these two empty. The only way I could fix the problem was the umount the mount point and remount it. After that, the directories looked normal again. The the directory was mounted using: filer0:/vol/opt /mnt/optnfs -T,-L,-b,-i,rw 0 0 Not sure if it's a NFS client side bug, but it sure seems so -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: 0x66F90BFC @ http://pgp.mit.edu Key fingerprint = 6296 F715 038B 44C1 2720 292A 8580 500E 66F9 0BFC YOUR PC's broken and I'VE got a problem? -- The BOFH Slogan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.x from i386 to amd64
Greg Black wrote: > Fair enough. In my defence, I'm fully committed at present and > I have only one amd64 machine which I need for my real work. I > can't afford to run it in amd64 mode, because so much of what I > need is currently broken in a 64-bit world. That much of that > broken software is interpreters and compilers for languages I > use is a pretty sad reflection on people who should know a bit > more about writing correct software, but that's got nothing to > do with FreeBSD, except as a platform for running it on. I've checked all of the ports we really need and all of them don't seem to have a problem being installed under amd64. I'm mostly interested in running amd64 on higher end hardware that doesn't have an issue of addressing 4GB or more of RAM. The PAE capability on i386 still seems to be a bit experimental? -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: 0x66F90BFC @ http://pgp.mit.edu Key fingerprint = 6296 F715 038B 44C1 2720 292A 8580 500E 66F9 0BFC telnet: Unable to connect to remote host: Connection refused ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
6.x from i386 to amd64
Is there a way to upgrade/move an already installed i386 installed 6.1 machine to amd64 without completely reinstalling? Is there a procedure to do so? -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: 0x66F90BFC @ http://pgp.mit.edu Key fingerprint = 6296 F715 038B 44C1 2720 292A 8580 500E 66F9 0BFC A list is only as strong as its weakest link. - Don Knuth ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: iSCSI HBAs
Danny Braniss wrote: > we have been running diskless clients for a few hundred work stations, so > i think i have some experience :-) > 1- setting a diskless freebsd is far easier than linux > 2- it's by far much easier to manage. > btw, the majority of ws are running linux. > being involved with the iSCSI initiator for FreeBSD, I can't see where > this can help for a diskless host, or in other words, what's > wrong with NFS? > also, the TOE cards are not that cheep either :-) TOE cards are no more expensive than putting a RAID card and two drives in a box. Is it more expensive than native FreeBSD diskless? Sure. I'm not saying that NFS is bad, we use it all over the place. What's nice about iSCSI is you can setup servers for anything and not care what runs on the box. Thus making almost any server diskless so long as it supports the HBA. This works great when you deploy things like Plesk, etc, which don't support NFS or diskless environements. Does it run? Sure, but not without a lot of messing around. Also, if you have the one or two Windows servers you may be forced to have, you can run them diskless as well using the same iSCSI system. I agree that diskless is a nice system to consider, and it's one of our alternate choices, but we do have some applications, virtual servers, etc, which do not support running in native FreeBSD diskless fashion. -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: 0x66F90BFC @ http://pgp.mit.edu Key fingerprint = 6296 F715 038B 44C1 2720 292A 8580 500E 66F9 0BFC Esc key to reboot Universe, or any other key to continue... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: iSCSI HBAs
Matthew Jacob wrote: > Why do you think an iSCSI HBA would be of any benefit to anything > other than the target mode side as a server? Mostly for deploying servers that are diskless, quickly. No need to depend on another server (other than the iSCSI target) to get servers up without a lot of fusing around. Diskless + the software initiator seems like a lot of fusing around to get one server up. I mean I could be wrong, I'm not really sure how the FreeBSD software initiator works or if it's actual optimized and stable. If it's as easy as setting up a DHCP and TFTP server just to boot the kernel, then mount the iSCSI volume, that might be an option. But right now, if an iSCSI HBA driver was available it might be the more reliable way to go. Again, I could be way off base. We use FreeBSD in all of our server clusters now, most via RAID1 mirrors on every server, I'd like to stay with FreeBSD, but sometimes it's lack of support for new server beneficial drivers make that choice hard to make. -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: 0x66F90BFC @ http://pgp.mit.edu Key fingerprint = 6296 F715 038B 44C1 2720 292A 8580 500E 66F9 0BFC One picture is worth 128K words. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
iSCSI HBAs
Anyone know if there is a working driver for either the QLogic QLA4050C or Adaptec 7211C iSCSI HBAs? I know there is a software based initiator in the works, but having a driver for the iSCSI HBA's would provide a great alternative to running diskless or FC SAN. -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: 0x66F90BFC @ http://pgp.mit.edu Key fingerprint = 6296 F715 038B 44C1 2720 292A 8580 500E 66F9 0BFC Press Ctrl-Alt-Del now for IQ test. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Sun X86 servers
I'd like to know if anyone is using the Sun X86 servers with 6.x. If so, how is it preforming? I'm looking at possibly using them in a diskless environment (and a couple possibly with disks) I've read in the past that the disk controllers were not supported yet, I'm not sure if that's changed (or changing). What about network controllers? Please contact me off-list (unless others are interested as well). TIA! -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: 0x66F90BFC @ http://pgp.mit.edu Key fingerprint = 6296 F715 038B 44C1 2720 292A 8580 500E 66F9 0BFC To define recursion, we must first define recursion. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Dell PowerEdge 1855
I'd like to know if anyone has experience with the Dell PowerEdge 1855 blade servers running on either FreeBSD_4 or FreeBSD_5. I'm looking to deploy several servers and I know that the 1850's will run just fine. I have concerns over the PERC4/im and the ethernet controllers on the 1855's. I assume since the 1855's have Intel Gig-E controllers they use the em driver, which I've had good luck with in the past. Apparently the 1855's integrated RAID uses the LSI (mpt) driver. I've heard mixed results on this with earlier versions of 4.x and 5.x, but nothing in the latest releases, 4.10+ and 5.3. Can anyone share their experiences with performance and stability on these machines? TIA -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: http://www.inoc.net/~dev/ Key fingerprint = 1E02 DABE F989 BC03 3DF5 0E93 8D02 9D0B CB1A A7B0 If at first you don't succeed, call it version 1.0 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: perl 5.8.5 on freebsd 4.10
Ken Menzel wrote: I need perl 5.8 to use xerces xml parser (xml.apache.org) on Freebsd5.3 perl5.8 the t/op/crypt test passes fine but not on 4.10 is this OK or normal? Any ideas or comments? t/op/cproto...ok t/op/crypt# Failed at op/crypt.t line 45 # got '$2a$04$cXSIoNruOcY4zQvBHgLd4OwIn/hpnHpszYR0VrbT0MGHtj8UgV4jS' # expected '$2a$04$cQSEYKwMGkhlyuPmbY2YY.5Fo0iMDAVDOlSr8SElFfCwc8SPUJW7.' FAILED at test 4 t/op/defins...ok freebsd4# uname -a FreeBSD freebsd4.icarz.com 4.10-RELEASE-p2 FreeBSD 4.10-RELEASE-p2 #15: Mon Aug 2 16:14:59 EDT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ICARZ i386 cd /usr/ports/lang/perl5.8 make install clean or portupgrade perl5* Both of those work fine for me. -- Robert Blayzor, BOFH INOC, LLC rblayzor\@(inoc.net|gmail.com) PGP: http://www.inoc.net/~dev/ Key fingerprint = 1E02 DABE F989 BC03 3DF5 0E93 8D02 9D0B CB1A A7B0 My Other machine is your Linux Box ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: RE: Swap_pager error
I looked through all the periodic daily stuff. It doesn't seem that any of the scripts will trash NFS mounted partitions, almost everything I saw would only look at UFS mounted partitions. One thing I did notice is the security check was quite brutal. While any server should survive it I believe this is what is causing the system to crash. The security check seems to run a find on the NFS servers local UFS mounts. We have some very, very large volumes with hundreds of thousands of small files... (maildirs, boxes, webmail, web, etc). On this box, it seemed that the security check would take almost 3-4 minutes to complete with that find, and it just totally saturates the box in activity when it runs. So, I think there may be a loading issue with all these files/inodes in relation to the find process... Perhaps the SCSI or driver stuff in FreeBSD. If I can be of any help on this, I surely will led a hand. I would like to see FreeBSD be able to survive this without a hitch. Perhaps a suggestion to change the priority of the "find" tasks in those scripts with nice or something. I mean the box was really bogged down when we ran "periodic daily" by manually. As a work around, we moved periodic daily to run at 9:01am instead of 3:01am, and only on Monday - Friday. We don't need any more weekend surprise pages and then call-ins. :-) Since this box is an internal server only with no accounts on it, and it has no route to the outside + behind a firewall, we're going to go ahead and disable the security check all together. I'm hoping that this will provide a work around for this "loading" issue. If I can be any help to the core team to debug this problem, I'll do my best to do what I can. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] One picture is worth 128K words. > -Original Message- > From: Matthew Dillon [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 04, 2002 1:49 PM > To: Robert Blayzor; [EMAIL PROTECTED] > Subject: Re: RE: Swap_pager error > > > I have one more idea... daily cron jobs tend to really > load down the > system for a short period of time, especially the disks. > In your case > the local daily cron is combinging with the daily cron > running on the > NFS clients. There could be a hardware problem with the > system that > is most likely to show up under heavy loads. > > It is also possible that this is revealing a driver bug somewhere. > For example, the extreme disk load could be revealing a bug in the > driver's tag handling or in the RAID card's tag handling. > The lack > of driver-based error messages is rather odd. I don't > see how that > can happen unless the RAID card itself is locking up. > > -Matt > > :: > ::Both times the box has crashed crashed at ~3:02am. I'm > thinking that > ::something in periodic daily is causing the crashes. > :: > ::Keep in mind, that this server serves several NFS clients > which mount > ::things such as FreeBSD ports and /usr/src. Those are soft > linked to on > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: Swap_pager error
I would totally agree with this, and will try the read, thanks for the
suggestions. My feeling is that it is NOT physical disk or a problem
with the disk drives. My experience in the past is that if the RAID
controller cannot successfully read or write blocks from either drive in
the array, the array alarm will sound. The array controller shows no
problems at all with the disk, and I have no red lights indicating a bad
drive.
Just seems rather strnage. I'll try doing the dd later at a slower time
and let you know how I make out.
Thanks again!
--
Robert Blayzor, BOFH
INOC, LLC
[EMAIL PROTECTED]
A successful tool is used to do something undreamed of by its author. -
Johnson
> If you see it suddenly drop down in the middle of the dd
> operation and
> then pick up again the hard drive may have soft errors
> internally but
> is still able to finally retrieve the block. If the
> kernel ('dmesg'
> program and '/var/log/messages' log file) reports disk
> errors during
> your dd then you may have a problem with one or more drives.
>
> -Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
