kernel ignores default route?
One of my machines is doing something I can not understand and may have uncovered some form of bug. The kernel appears to be ignoring the default route. Had several people look this over, we can't determine where the route is being hidden. This is 7.4-RELEASE-p2. I suspect that rebooting the box will clear the problem but I would REALLY like to figure out why the routing table is not being followed. I have two routers, on the same ethernet at: 148.59.4.1 (default) 148.59.4.3 139.171.192.26 148.59.4.2 (FreeBSD box) This is correct (see routing table below): traceroute -n 148.59.48.1 traceroute to 148.59.48.1 (148.59.48.1), 64 hops max, 40 byte packets 1 139.171.192.26 7.366 ms 4.748 ms 6.879 ms 2 148.59.48.1 3.357 ms 5.130 ms 3.006 ms And route agrees: route -n get 148.59.48.1 route to: 148.59.48.1 destination: 148.59.48.0 mask: 255.255.255.192 gateway: 148.59.4.3 interface: fxp0 flags: UP,GATEWAY,DONE,PROTO1 recvpipe sendpipe ssthresh rtt,msecrttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 This is not, it should go out 148.59.4.1: traceroute -n 148.59.80.1 traceroute to 148.59.80.1 (148.59.80.1), 64 hops max, 40 byte packets 1 139.171.192.26 6.874 ms 6.496 ms 4.288 ms 2 139.171.198.139 5.907 ms 8.251 ms 4.156 ms 3 198.22.65.217 5.246 ms 4.961 ms 4.719 ms 4 198.22.65.222 14.096 ms 4.760 ms 6.545 ms 5 148.59.80.1 5.753 ms 5.813 ms 5.952 ms route says it should: route -n get 148.59.80.1 route to: 148.59.80.1 destination: default mask: default gateway: 148.59.4.1 interface: fxp0 flags: UP,GATEWAY,DONE,STATIC recvpipe sendpipe ssthresh rtt,msecrttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 netstat -rn (minus a few 148.59.4.x machines that can be ignored) Internet: DestinationGatewayFlagsRefs Use Netif Expire default148.59.4.1 UGS 0 667619000 fxp0 10.151.89.0/24 link#1 UC 00em0 10.151.89.49 00:c0:9f:21:b2:31 UHLW1 14lo0 127.0.0.1 127.0.0.1 UH 223811lo0 148.59.4.0/27 link#2 UC 00 fxp0 148.59.4.1 00:a0:c8:2c:5f:38 UHLW2 602 fxp0 47 148.59.4.3 00:a0:c8:2c:5f:38 UHLW50 fxp0 23 148.59.4.64ff:ff:ff:ff:ff:ff UHLWb 114991em0 = 148.59.4.64/26 link#1 UC 00em0 148.59.4.6600:02:b3:e9:0e:c0 UHLW1 8098em0903 148.59.4.130 148.59.4.129 UH 0 2073 tun0 148.59.48.0/26 148.59.4.3 UG1 0 1158 fxp0 148.59.50.0/24 148.59.4.3 UG1 0 194507 fxp0 148.59.80.39 148.59.4.3 UGH100 fxp0 198.11.50.21 148.59.4.3 UGH100 fxp0 224.0.0.5 127.0.0.1 UGH100lo0 224.0.0.6 127.0.0.1 UGH100lo0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
fdisk very confused on 3ware system
I am unable to create a new partition on a machine running 6.1-RELEASE-p3 and am beginning to suspect something is wrong in fdisk. If I run sysinstall and go to the partition editor, I get the following, which seems correct: Disk name: twed0 FDISK Partition Editor DISK Geometry: 9729 cyls/255 heads/63 sectors = 156296385 sectors (76316MB) Offset Size(ST)End Name PType Desc SubtypeFlags 0 63 62- 12 unused0 63 31455207 31455269 twed0s1 8freebsd 165 31455270 58717575 90172844 twed0s2 8freebsd 165 90172845 66126595 156299439- 12 unused0 But, I am unable to create a new partition. Every time I do that, I get: ERROR: Unable to write data to disk twed0! This machine is not running secure: kern.securelevel: -1 So, I decided to go in with fdisk and see what was up. It looks like something is very confused on partition two, which is likely why I can not create a partition 3: fdisk /dev/twed0 *** Working on device /dev/twed0 *** parameters extracted from in-core disklabel are: cylinders=9729 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=9729 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 31455207 (15358 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 31455270, size 58717575 (28670 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 !! The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED At this point, I'm suspecting that fdisk is computing something incorrectly and am not sure how to proceeed as I'd prefer not to corrupt my disk label. Before I consider filing a PR, is this a known problem? /\/\ \/\/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Jail Quotas - quota.user hard link
On Wed, Apr 26, 2006 at 06:23:59PM -0400, Charles Sprickman wrote: I have a question about using quotas in a jail with FreeBSD 6.x. So far I have had no problems on a test box with setting quotas from the host using a numeric UID (ie: edquota -u 2 where UID 2 is a user that only exists in a jail). That seems to just work. Just a heads up: quotas in jails on FreeBSD 6 are pretty broken. I'll include some workarounds. Basic operation can be done by specifying a filename, available in the jail, which contains the quotas. So, on the base system, /etc/fstab contains: /dev/twed0s2f /usr/jails/foo.bar.com ufs rw,userquota=/usr/jails/foo.bar.com/usr/quotas/shell.root 2 2 and on the foo.bar.com jail, /etc/fstab contains: /dev/twed0s2f / ufs rw,userquota=/usr/quotas/shell.root,noauto 2 2 Now the problems begin. You either do chmod a+r /usr/quotas/shell.root which permits everyone on the machine to read all quotas (both quota and repquota) or chmod o-r /usr/quotas/shell.root which permits ONLY root to read any quotas. Normal users can not see their own quotas (I filed a PR on this quite some time back, nobody seems interested). This seems to be new breakage since 4.x Also, if you edquota from within the jail, it does not really take effect. You can stick an hourly cron script on the base system containing quotaoff -a quotacheck -a quotaon -a which will fixup the mess. Alternately, you can only use edquota from the base system which seems to mostly work. ISTR that there was something else that was odd but I'm sure somebody else will jump in and mention it. /\/\ \/\/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Infrequent disk system hang on 5.4-RELEASE-p8
We have an older server, running 5.4-RELEASE-p8 and used primarily for email, which hangs every couple of weeks. The hang seems to be in the disk I/O system. Based on the times of the hangs, the triggering event seems to be running dump. We have a serial console set up, I broke to the debugger and got the following. Since the hang is in the disk I/O system, a dump is not possible. The many versions of inetd are likely due to users attempting to POP their email. Any suggestions or tips on how to track this down and get it resolved would be appreciated. Relevant dmesg info: ahc0: Adaptec aic7896/97 Ultra2 SCSI adapter port 0xe400-0xe4ff mem 0xffafe000-0xffafefff irq 16 at device 11.0 on pci0 aic7896/97: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: Adaptec aic7896/97 Ultra2 SCSI adapter port 0xe800-0xe8ff mem 0xffaff000-0xffaf irq 16 at device 11.1 on pci0 aic7896/97: Ultra2 Wide Channel B, SCSI Id=7, 32/253 SCBs da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST318436LW 0010 Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 17522MB (35885168 512 byte sectors: 255H 63S/T 2233C) da1 at ahc1 bus 0 target 0 lun 0 da1: SEAGATE ST336938LW 0003 Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 35242MB (72176567 512 byte sectors: 255H 63S/T 4492C) da2 at ahc1 bus 0 target 1 lun 0 da2: SEAGATE ST318436LW 0010 Fixed Direct Access SCSI-3 device da2: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da2: 17522MB (35885168 512 byte sectors: 255H 63S/T 2233C) GEOM_MIRROR: Device gm0s1 created (id=520792649). GEOM_MIRROR: Device gm0s1: provider da0s1 detected. GEOM_MIRROR: Device gm0s2 created (id=3744871543). GEOM_MIRROR: Device gm0s2: provider da0s2 detected. GEOM_MIRROR: Device gm0s1: provider da2s1 detected. GEOM_MIRROR: Device gm0s1: provider da2s1 activated. GEOM_MIRROR: Device gm0s1: provider da0s1 activated. GEOM_MIRROR: Device gm0s1: provider mirror/gm0s1 launched. GEOM_MIRROR: Device gm0s2: provider da2s2 detected. GEOM_MIRROR: Device gm0s2: provider da2s2 activated. GEOM_MIRROR: Device gm0s2: provider da0s2 activated. GEOM_MIRROR: Device gm0s2: provider mirror/gm0s2 launched. db ps pid proc uid ppid pgrp flag stat wmesgwchan cmd 67487 c5ea98d40 551 551 100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67486 c3b8a1c40 551 551 100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67485 c634c7100 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67484 c62931c40 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67483 c58a93880 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67482 c62937100 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67481 c58ab8d40 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67480 c6292c5c0 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67479 c62938d40 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67478 c634f0000 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67477 c62941c40 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67476 c5e55c5c0 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67475 c5f1fe200 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67474 c5da854c0 551 551 100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67473 c5f9ee200 551 551 100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67472 c58a9e200 551 551 100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67471 c602d8d40 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67470 c61191c40 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67469 c58ab1c40 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67468 c5f19a980 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67467 c58c33880 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67466 c5f1f3880 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67465 c5f190000 442 67465 100 [SLPQ ufs 0xc3851c04][SLP] sshd 67464 c5fa68d40 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67463 c5eab54c0 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67462 c62940000 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67461 c5fa67100 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67460 c61190000 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67459 c634c3880 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67458 c5da87100 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67457 c3b8e3880 551 551 100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67456 c62948d40 551 551 100 [SLPQ ufs 0xc3851c04][SLP] sendmail 67455 c62921c40 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67454 c5f1954c0 574 574 000 [SLPQ ufs 0xc3851c04][SLP] inetd 67453 c5eab3880 574 574
Debugging a hanging 5.4 system
We've got a system running 5.4-RELEASE-p8 that occasionally hangs while dump is running. I suspect it's something to do with the SCSI controller hanging: ahc0: Adaptec aic7896/97 Ultra2 SCSI adapter because the machine remains pingable and I can hit CR on the serial console and keep getting login prompts until I enter a username at which point the machine ceases to respond. I've compiled a kernel with include GENERIC options ALT_BREAK_TO_DEBUGGER options KDB options DDB in preparation for the last crash. There is a portmaster hooked to the serial port so that I can telnet to it and break to the debugger. Obviously, I will not be able to create a crash dump. My question is what specific DDB commands I should use when the system is hung so that I can generate sufficient information to create a useful PR. Any other hints/tips would also be appreciated. /\/\ \/\/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Reducing dummynet pipe size hangs system
Summary:
On an old (4.8p10) machine, substantially reducing the pipe size
on a loaded connection causes the system to freeze.
Is this a supported feature?
Did it usd to be broken?
Detail:
There's a 4.8p10 machine acting as a firewall (runs only ssh and
ipfw rules, hence the lack of updates). While trying to copy a
huge file from a local machine to a remote, the following ipfw
rules are in place:
ipfw add 10990 pipe 1 tcp from ${local_host} to ${remote_host}
ipfw pipe 1 config bw 256kbit/s queue 40KB
ipfw add 10991 pipe 2 tcp from ${remote_host} to ${local_host}
ipfw pipe 2 config bw 256Kbit/s queue 40KB
Since the flie is large enough to require several days to transfer, I
decided to tweak the pipe sizes off hours to permit it to go faster.
Crontab:
0 18 * * * rootipfw pipe 1 config bw
512kbit/s queue 40KB
1 18 * * * rootipfw pipe 2 config bw
512kbit/s queue 40KB
30 0 * * * rootipfw pipe 1 config bw
1024kbit/s queue 40KB
31 0 * * * rootipfw pipe 2 config bw
1024kbit/s queue 40KB
30 3 * * * rootipfw pipe 1 config bw
1200kbit/s queue 40KB
31 3 * * * rootipfw pipe 2 config bw
1200kbit/s queue 40KB
30 6 * * * rootipfw pipe 1 config bw
256kbit/s queue 40KB
31 6 * * * rootipfw pipe 2 config bw
256kbit/s queue 40KB
Two days in a row now, just after 6:30, the box freezes, refusing
keyboard input and requiring a reboot.
Queries:
Is this considered an unsupported use of dummynet?
If it should work, was it broken back in 4.8 and, if so, when
was it corrected? I'd rather not take the time up upgrade the
box to 4.11 if I'll then be forced to move to 5.4.
/\/\ \/\/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: query cdrw tray
On Fri, Dec 17, 2004 at 12:11:52PM -0700, Ed Stover wrote: How to I ask the CD burner if it's tray is open or closed? I am creating a automagical shell script to do semi-unattended backups and need to figure out how to make sure there is a cd in the tray before I start burning. Any help would be greatly appreciated. Having solved this once before, here's the code I used: #!/bin/sh # Spin wait for a CD into the drive while /usr/X11R6/bin/cda status | /usr/bin/grep -q '^No_Disc' do sleep 1; done ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Mergemaster+RCS
Although Doug Barton has written a wonderful tool, it has always
seemed to have a major deficiency: it completely ignores the
existance of RCS files. I've exchanged some email with Doug and
he has no interest in adding RCS support to mergemaster. So I did.
Doug has mentioned that some people solve this problem by using
the precompare script or by checking out all RCS files before
running mergemaster then checking them in afterwards. These
solutions are highly unattractive to me since they require sysadmins
to remember far too much, especially given that systems are often
upgraded at off hours to minimize user impact.
The attached patch to the mergemaster in 4.9-RELEASE-p1 addresses
this issue. Specifically, it does the following, automatically:
For every file that mergemaster replaces, check for the existance
of an associated RCS log file in the RCS subdirectory. (I do
NOT check for the logfile in the current directory).
If such a logfile exists
If the file is currently checked out, check it in with an automated comment.
Check the file out.
Apply the upgrade.
Check the file in with an automated comment.
If the file was originally checked out, check it back out again.
If no associated RCS log file exists, there is no change in the
operation of mergemaster.
I take care to leave the log file in the original checked in/out
state: People have tools that know the state of logfiles and
these tools should not be broken.
This seems to work for us. Comments/suggestions welcome.
/\/\ \/\/
*** /usr/sbin/mergemaster Thu Jan 8 17:03:30 2004
--- mergemaster+rcs Fri Jan 9 08:45:19 2004
***
*** 8,20
# Copyright 1998-2003 Douglas Barton
# [EMAIL PROTECTED]
# $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.6.2.18 2003/08/25 08:27:41
dougb Exp $
PATH=/bin:/usr/bin:/usr/sbin
display_usage () {
VERSION_NUMBER=`grep [$]FreeBSD: $0 | cut -d ' ' -f 4`
! echo mergemaster version ${VERSION_NUMBER}
echo 'Usage: mergemaster [-scrvahipCP] [-m /path]'
echo ' [-t /path] [-d] [-u N] [-w N] [-D /path]'
echo Options:
--- 8,22
# Copyright 1998-2003 Douglas Barton
# [EMAIL PROTECTED]
+ # Automated support for RCS log files added 2004 by [EMAIL PROTECTED]
+
# $FreeBSD: src/usr.sbin/mergemaster/mergemaster.sh,v 1.6.2.18 2003/08/25 08:27:41
dougb Exp $
PATH=/bin:/usr/bin:/usr/sbin
display_usage () {
VERSION_NUMBER=`grep [$]FreeBSD: $0 | cut -d ' ' -f 4`
! echo mergemaster version ${VERSION_NUMBER} with RCS support
echo 'Usage: mergemaster [-scrvahipCP] [-m /path]'
echo ' [-t /path] [-d] [-u N] [-w N] [-D /path]'
echo Options:
***
*** 646,653
--- 648,695
;;
esac
+ # Begin part 1 of 2 support for RCS added by [EMAIL PROTECTED]
+ # Deals with RCS log files in the RCS subdirectory, first checking
+ # in previous changes (if any), checks in the changes made by
+ # mergemaster and leaves the file in the original checked in/out state.
+ #
+ # Assume we will not need to check this file in.
+ local MM_RCS
+ MM_RCS=0
+ if [ -d ${3}/RCS ]; then
+ # The RCS directory exists, check it for this logfile
+ if [ -e ${3}/RCS/${2##*/},v ]; then
+ # The RCS logfile exists, now we need to know it's existing state
+ if [ -z `rlog -L -R ${3}/${2##*/}` ]; then
+ # Target file is unlocked, check it out
+ co -l ${3}/${2##*/}
+ # Remember to leave file unlocked after install
+ MM_RCS=1
+ else
+ # File is already locked, check it in before we mess with it
+ ci -l -mMergemaster auto checkin of locked file. ${3}/${2##*/}
+ # Remember to leave file locked after install
+ MM_RCS=2
+ fi
+ fi
+ fi
+ # End part 1 of 2 support for RCS added by [EMAIL PROTECTED]
+
install -m ${1} ${2} ${3}
rm -f ${2}
+
+ # Begin part 2 of 2 support for RCS added by [EMAIL PROTECTED]
+ if [ $MM_RCS -eq 1 ]; then
+ # Checkin the file, leaving it unlocked
+ ci -u -mMergemaster auto checkin after updates ${3}/${2##*/}
+ elif [ $MM_RCS -eq 2 ]; then
+ # Checkin the file, leaving it locked
+ ci -l -mMergemaster auto checkin after updates ${3}/${2##*/}
+ else
+ # Do nothing, no RCS log file exists
+ fi
+ # End part 2 of 2 support for RCS added by [EMAIL PROTECTED]
+
}
find_mode () {
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Excessive swap usage w/ 4.6
After having moved servers from 4.3 and 4.5 to 4.6, we are noticing that swap indicates much higher usage. Today, one of our squid cache servers hit (and stayed at) 50% swap utilization so I decided to do some digging. This machine has 512 MB physical RAM in it and is running FreeBSD 4.5-RELEASE-p7 Here's a ps with some cruft removed and columns widened for readability. ps -axel CPU PRI NIVSZRSS WCHAN STAT TT TIME COMMAND 0 -18 0 0 0 sched DLs ??0:00.00 (swapper) 0 10 0544116 wait ILs ??0:00.31 /sbin/init -- 0 -18 0 0 0 psleep DL??5:30.16 (pagedaemon) 0 18 0 0 0 psleep DL??0:00.04 (vmdaemon) 0 -18 0 0 0 psleep DL??0:33.61 (bufdaemon) 0 -2 0 0 0 vlruwt DL??0:29.52 (vnlru) 0 18 0 0 0 syncer DL?? 29:36.89 (syncer) 0 2 0948340 select Ss??0:15.27 /usr/sbin/syslogd -s 0 2 0 1300352 select Ss??3:52.69 ntpd -p /var/run/ntpd.pid 0 2 0 1064560 select Is??0:00.18 /usr/sbin/inetd -wW 0 10 0984216 nanslp Is??0:15.08 /usr/sbin/cron 28 2 0 2136264 select Is??3:00.12 /usr/local/sbin/sshd 0 10 0 2940 0 wait IWs ??0:00.00 () /usr/local/sbin/squid 4 2 0 398380 381916 poll S ?? 286:58.56 (squid) (squid) 0 -6 0860176 piperd Ss??1:35.35 (unlinkd) (unlinkd) 0 2 0 4792512 select Ss??0:01.48 sshd: 0 2 0 2732 1920 select Ss??0:02.73 /usr/local/sbin/gated 0 2 0 2096 1464 select Ss??0:00.08 /usr/local/sbin/httpd 0 2 0 2504 1660 accept I ??0:00.01 /usr/local/sbin/httpd 0 2 0 2512 1668 accept I ??0:00.01 /usr/local/sbin/httpd 0 18 0 1584820 pause Ssp00:00.51 SSH_CLIENT= 0 28 0416172 - R+p00:00.00 SSH_CLIENT= 0 3 0948528 ttyin Is+ v00:00.00 /usr/libexec/getty Pc ttyv0 0 3 0948524 ttyin Is+ v10:00.00 /usr/libexec/getty Pc ttyv1 === === Totals427,688 393,208 -393,208 === 34,480 So, swap usage should be about this much. But: pstat -s Device 1K-blocks UsedAvail Capacity Type /dev/ad0s1b614272 304792 30948050%Interleaved This seems very excessive as well as unjustified. Is there some way I can find out if I have a swap leak or some other way to figure out what is going on? As I mentioned, we noticed a significant increase in swap usage on many servers between 4.3 or 4.5 and 4.6 /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: setting quotas _inside_ a jail for users _inside_ a jail
On Fri, Aug 30, 2002 at 12:41:54AM -0700, Patrick Thomas wrote: I wonder, is it possible for the root user of a jail to set quotas _inside_ her jail for users _inside_ her jail ? Can anyone simply confirm or deny that this is possible ? Yes, it is possible. The following procedure (assuming I documented it properly here) works fine. We make the following assumptions: We want quotas within the jail. We don't care about matching userids from the jail to the server This is not undoable but it means synccing the password file which we consider pointless. We do not try to apply quotas to the jailed server by running any quota tools on the main server. To administer quotas on the jail, we log into the jail to do it. If you find something wrong in here, please let me know. Now that I've taken the time to write it all down, I will make some noise about getting it into the documentation. This REALLY, REALLY should be in the handbook. Was a bear to figure out the first time. For this example server (S) runs a jail (J) with a mount point of /J. So J:/foo is the same file as S:/J/foo. In S:/etc/fstab, for the filesystems to be quotaed, you must specify a location which will be available to the jail. Assuming we will start J with a mount point of /J, this example will work for user home directories within the jail (the nosuid,nodev is optional) /dev/da0s1d /J/home ufs rw,nosuid,nodev,userquota=/J/usr/quotas/J.home 2 2 Copy only the lines that have quotas from S:/etc/fstab to J:/etc/fstab On each of these lines, add the option noauoto and remove the original mount point. So, the example would put into J:/etc/fstab: /dev/da0s1d /home ufs rw,nosuid,nodev,userquota=/usr/quotas/J.home,noauto 2 2 ^ ^ ^^ | | |-MUST have no auto here! | | Removed the jail mount point|-Removed the jail mount point in S:/etc/rc.conf: enable_quotas=YES # turn on quotas on startup Now there are some problems in /etc/rc. The following patch deals with these, if in a somewhat inelegant way. Ideally, /etc/rc would use if jail around these, making /etc/rc usable inside as well as outside of jails. Note that the instructions continue FOLLOWING the patch! *** rc.ORIG Fri Aug 30 12:56:34 2002 --- rc Fri Aug 30 12:56:59 2002 *** *** 38,44 # first before contemplating any changes here. If you do need to change # this file for some reason, we would like to know about it. ! # Msen off for jails stty status '^T' # Set shell to ignore SIGINT (2), but not children; # shell catches SIGQUIT (3) and returns to single user after fsck. --- 38,44 # first before contemplating any changes here. If you do need to change # this file for some reason, we would like to know about it. ! stty status '^T' # Set shell to ignore SIGINT (2), but not children; # shell catches SIGQUIT (3) and returns to single user after fsck. *** *** 179,185 set -T trap echo 'Reboot interrupted'; exit 1 3 - if [ ]; then # Msen shuts off ALL mount/umount activity for jails # root normally must be read/write, but if this is a BOOTP NFS # diskless boot it does not have to be. # --- 179,184 *** *** 214,220 ;; esac - fi# Msen shuts off ALL mount/umount activity for jails adjkerntz -i --- 213,218 Insure you have quotas in your kernel. Reboot S. Log into J and ues edquota to apply one quota to one account. Reboot S again. At this point, you should be able to log into J and use all the normal quota tools as desired. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: jail man page
On Thu, May 30, 2002 at 07:09:27AM -0400, Chris Faulhaber wrote: On Wed, May 29, 2002 at 11:44:12PM -0400, Michael R. Wayne wrote: Posted to -hackers in the hope that this can be tweaked in 4.6 RELEASE. 4.5-RELEASE-p4 % man jail D=/here/is/the/jail cd /usr/src make world DESTDIR=$D ^ | shouldn't that really be make installworld DESTDIR=$D Kinda difficult to installworld if you haven't built it yet... We are building from source here right? Not doing a binary install. So we should have recently followed the steps in UPDATING in order to get our host upgraded. So we use that. jail is confusing enough as it is. Having the man page tell people to rebuild the world for each jail they are going to install is not reasonable. So it's more than a one word fix: Prior to installing a jail, you should follow the instructions in /usr/src/UPDATING to build the world and install it on the host. Then, for each jail you wish to create, do the following /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
jail man page
Posted to -hackers in the hope that this can be tweaked in 4.6 RELEASE. 4.5-RELEASE-p4 % man jail D=/here/is/the/jail cd /usr/src make world DESTDIR=$D ^ | shouldn't that really be make installworld DESTDIR=$D /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: quotactl issues [Solved]
On Fri, Apr 12, 2002 at 08:15:49AM -0500, mark tinguely wrote: I tried to replicate the problem with DDB and QUOTA compiled into the kernel but could not. Built a test system, ran a bunch of gdb sessions found the problem. Despite having this: grep quota /etc/rc.conf enable_quotas=YES # turn on quotas on startup (or NO). check_quotas=YES # Check quotas on startup (or NO). Somehow quotas were off on the filesystem in question. I would suggest the following change to the man page for quotactl: [EINVAL] Cmd or the command type is invalid. Q_GETQUOTA returns EINVAL if quotas are not currently enabled for this filesystem. /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: quotactl issues
No replies on this. Nobody has any ideas? /\/\ \/\/ On Wed, Apr 10, 2002 at 01:33:21PM -0400, Michael R. Wayne wrote: Ported some code that uses quotactl to 4.3 p19 and it fails with EINVAL when trying to: quotactl(var/mail, QCMD(Q_GETQUOTA, USRQUOTA), VALID_UID, blk) Looked at the source for edquota on 4.5 RELEASE (what I had handy), and ran a copy of it through gdb, it fails with the same error, then it goes in and reads/writes the quota files directly! So, is quotactl just not supported or do the filesystems need to be converted or what? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: quotactl issues
On Thu, Apr 11, 2002 at 01:48:40PM -0700, Terry Lambert wrote:
Michael R. Wayne wrote:
No replies on this. Nobody has any ideas?
Nobody has seen it until now.
SOMEbody did - that's why they hacked edquota.c! See code fragment below.
On Wed, Apr 10, 2002 at 01:33:21PM -0400, Michael R. Wayne wrote:
Ported some code that uses quotactl to 4.3 p19 and it fails with EINVAL
when trying to:
quotactl(var/mail, QCMD(Q_GETQUOTA, USRQUOTA), VALID_UID, blk)
Looked at the source for edquota on 4.5 RELEASE (what I had handy),
and ran a copy of it through gdb, it fails with the same error,
then it goes in and reads/writes the quota files directly!
So, is quotactl just not supported or do the filesystems need to
be converted or what?
1)Path should be absolute
It is in the code. I messed up in the email post.
2)Path *must* refer to a mount point; you look like you are
treating quotas as if they are more granular than they are.
Quotas are on a per FS basis *only*.
/var/mail is a mount point on this box.
3)Setting a manifest VALID_UID doesn't make it valid, just
because you name it that. 8-).
OK, I am using 1017 and 1017 is a valid user id on the system. I
abstracted in the email.
4)[EINVAL] Cmd or the command type is invalid.
Right. But the same code works on other BSD systems.
5)Are you sure that quotas are enables on this FS already?
Yes. And edquota (sorta, see below) works OK.
6)Are you sure blk is a struct dqblk?
Yes.
7)Quota UID and GID ranges are more limited than FreeBSD
otherwise limits UID/GID ranges. Make sure that VALID_UID
isn't larger than 65535 or smaller than 0.
1017, which is a valid userid.
Now - to re-iterate my point. The code for edquota FAILS IN EXACTLY
THE SAME WAY with EINVAL. But edquota IGNORES this error. The
reason that edquota works is that, when it gets this failure, it
reads and writes the quota file directly. If quotactl works
properly, why is there code in edquota.c to read/write the quotactl
file directly?
/usr/src/usr.sbin/edquota/edquota.c
if (quotactl(fs-fs_file, qcmd, id, qup-dqblk) != 0) {
if (errno == EOPNOTSUPP !warned) { --- running through
gdb errno is EINVAL here.
warned++;
warnx(warning: quotas are not compiled into this kernel);
sleep(3);
}
if ((fd = open(qfpathname, O_RDONLY)) 0) {--- So, edquota
ignores quotactl and does it manually
fd = open(qfpathname, O_RDWR|O_CREAT, 0640);
if (fd 0 errno != ENOENT) {
warn(%s, qfpathname);
free(qup);
continue;
}
warnx(creating quota file %s, qfpathname);
sleep(3);
(void) fchown(fd, getuid(),
getentry(quotagroup, GRPQUOTA));
(void) fchmod(fd, 0640);
}
lseek(fd, (long)(id * sizeof(struct dqblk)), L_SET);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
quotactl issues
Ported some code that uses quotactl to 4.3 p19 and it fails with EINVAL when trying to: quotactl(var/mail, QCMD(Q_GETQUOTA, USRQUOTA), VALID_UID, blk) Looked at the source for edquota on 4.5 RELEASE (what I had handy), and ran a copy of it through gdb, it fails with the same error, then it goes in and reads/writes the quota files directly! So, is quotactl just not supported or do the filesystems need to be converted or what? /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Odd ipfw behaviour
On Mon, Feb 18, 2002 at 09:31:13AM -0800, Crist J. Clark wrote: Do these patches help? Unfortunately, I was called out of town and will not be able to get back to work with my test setup until next week. Will post update then. /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Odd ipfw behaviour
On Sat, Feb 16, 2002 at 12:47:21AM -0800, Crist J. Clark wrote: On Fri, Feb 15, 2002 at 06:09:51PM -0500, Michael R. Wayne wrote: Using this ipfw rule on ProxyFirewall: fwd $(squid-box) log tcp from $(windows-box) to any 80 and checking the logs on ProxyFirewall, I see this horrible mess: ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 in via fxp1 ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 out via fxp0 ---!!! ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 in via fxp1 ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 out via fxp1 ipfw: 6 Deny ICMP:5.1 ProxyFirewall BROWSERbox out via fxp1 ipfw: 6 Deny ICMP:5.1 ProxyFirewall SQUIDbox out via fxp1 last message repeated 31 times This, of course, causes terrible performance as the packets destined for the local net bounce out the default interface. It can be corrected by specifying an interface in the fwd rule: fwd $(squid-box) log tcp from $(windows-box) to any 80 via fxp1 Is it expected behaviour for ipfw to disregard routing and put packets out on interfaces where they have no chance of being properly delivered (which would be odd) or is this a bug? I believe you are misinterpretting the logs. Each of those log entries is saying, OK, it's possible that I was imprecise initially. But: 1) It is the case that the rule w/o the interface causes terrible performance for squid and adding the via fxp1 corrects it. 2) Since SQUIDbox is on the same net as fxp1, can you please explain the second log rule? How can fxp0 be involved at all? Supposedly, the packet went OUT on fxp0, triggering the rule. This is wrong. 3) Note the 33 ICMP errors that are going on. Something is really borked. Again, adding the via fxp1 corrects this too. At rule 11005 I am forwarding this packet to SQUIDbox. The packet that triggered this rule was TCP BROWSERbox:1631 216.136.204.21:80 that came (out of|into) to the firewall via interface (fxp0|fxp1) That is, the 'via fxp?' at the end is telling you about the packet that _triggered_ the rule, not where the packet was actually forwared to. If you sniffed the connection, I expect that you would have seen four packets go from the firewall to SQUIDbox. This is a good point. I'll fire up the packet sniffers and capture what is going on. But, that second line and the ICMP errors still have me concerned. And, as I mentioned, w/o the via fxp1, the performance is terrible (takes about 10 seconds to bring up a page that is just across the link). I have to believe that other people have attempted to use ipfw squid and given up when they saw the poor performance, failing to investigae further. /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Odd ipfw behaviour
On Mon, Feb 18, 2002 at 05:49:46AM -0800, Crist J. Clark wrote: What precise version of FreeBSD are you running, BTW? 4.5 RELEASE, as stated in original message. /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Odd ipfw behaviour
ipfw seems to be confused about where to forward packets if no interface is specifically mentioned. Before I file a PR on it, I'd like someone who is more familiar with how ipfw operates to quickly look over my findings. Test setup, showing 2 ethernets with 2 FreeBSD boxes and another machine running netscape +---NetscapeBROWSERbox +---squid SQUIDbox +---4.5 Release--+ ProxyFirewall router---+ | internet The internal net on ProxyFirewall is fxp1, external net is fxp0. All devices have real IP addresses and correct netmasks NAT is not involved. Using this ipfw rule on ProxyFirewall: fwd $(squid-box) log tcp from $(windows-box) to any 80 and checking the logs on ProxyFirewall, I see this horrible mess: ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 in via fxp1 ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 out via fxp0 ---!!! ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 in via fxp1 ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 out via fxp1 ipfw: 6 Deny ICMP:5.1 ProxyFirewall BROWSERbox out via fxp1 ipfw: 6 Deny ICMP:5.1 ProxyFirewall SQUIDbox out via fxp1 last message repeated 31 times This, of course, causes terrible performance as the packets destined for the local net bounce out the default interface. It can be corrected by specifying an interface in the fwd rule: fwd $(squid-box) log tcp from $(windows-box) to any 80 via fxp1 Is it expected behaviour for ipfw to disregard routing and put packets out on interfaces where they have no chance of being properly delivered (which would be odd) or is this a bug? /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Issues with /stand sysinstall
Tried -questions, no response. Verified issue on 4.5 PRERELEASE. Going to /usr/src/release/sysinstall and doing make all make install builds a sysinstall which seems not to include the functionality needed to run as /stand/sh, /stand/fsck and friends. What is the correct way to build and install all of /stand? /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
Given the amount of code that IPSTEALTH adds (only a few lines), eliminating it as a compile time option and making it a knob is a win. Also, I know that there is an issue for system using cards from ETinc: enabling IPSTEALTH causes them to panic. ETinc has taken the stand that this feature is not supported as it is not in the base release. I'd like to see that objection go away. /\/\ \/\/ On Wed, Dec 19, 2001 at 05:33:13PM +0200, Ruslan Ermilov wrote: On Wed, Dec 19, 2001 at 06:19:29PM +0300, Yar Tikhiy wrote: I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. What if the packet is directed to us? I think we should still process options in this case, and the patch in the PR doesn't seem to do it. PS I was going to replace IPSTEALTH functionality with the net.inet.ip.decttl knob. Setting it to 0 would match the IPSTEALTH behavior, the default value will be 1. /PS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Wed, Dec 05, 2001 at 10:15:30PM -0800, Terry Lambert wrote: and ordinary user will find FreeBSD is slower, could we let user to select which kernel to install at installing time? It's a possibility that I've considered, given that sysinstall had a hard time supporting installing FreeBSD from a single CDROM image to support both developers and the end product with a single golden system image. The problem with doing this is that it sort of grates against the idea of a GENERIC entirely. GENERIC is just fine the way it is. I have always considered it a way to get everything installed and a nice saftey net. The issue is not that GENERIC performs poorly, the issue is that the kernel that remains on the box performs poorly. I've been considering this issue for a quite some time. There needs to be an automatic way to help the new user get a better kernel on his box. Matt Dillon provided a man page, now what's needed is a program (call it autotune) that looks at the machine and, possibly after asking the user some questions about proposed machine use, builds OPTIMIZED and generates changes for system files (e.g. adding softupdates to /etc/fstab). A scaled back version of autotune would also run daily out of cron to check system resources (e.g. mbuf utilization), parse syslogs and suggest a kernel reconfig/rebuild as needed. Given a working, easy to update skeleton program, I suspect that convincing the person who most understands a given subsystem to write optimization rules would not be difficult. /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Interface alias accounting
Back on Nov 7, 2000, Josef Karthauser [EMAIL PROTECTED] answered my query regarding per alias accounting, suggesting that the solution was in current and would MFC after 4.2 was released. 4.2 was released, any idea when this might show up into stable? /\/\ \/\/ On Wed, May 17, 2000 at 05:39:15PM -0400, Michael R. Wayne wrote: On Wed, May 17, 2000 at 01:50:13PM -0700, D. W. Piper wrote: Hi folks, I'm trying to find out how to get IP accounting information for web hosting where multiple IPs are aliased to the same interface. I seem to recall seeing something about it a few weeks ago, but I've searched the archives, and can't seem to find the information I'm looking for. If I recall correctly, it involved compiling in some kernel option or other. Can anybody help out? BSD/OS does this per interface right on the box, FreeBSD seems not to. We've been trying for several months to get a straight answer regarding FreeBSD, nobody seems to know whether it's a bug, oversight or what. This is in current now. I'm going to MFC it after the 4.2 release. Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Protections on inetd (and /sbin/* /usr/sbin/* in general)
Background: We recently had a customer's web site suffer an attempted exploit via one of their cgi scripts. The attempted exploit involved writing a file into /tmp, then invoking inetd with that file to get a root shell on a non-standard port. While the exploit failed, they were able to write the file as user nobody and invoke inetd. There is not much we can do about that as long as we permit customers to use their own cgi scripts, which is a requirement with this type of account. Issue: The exploit managed to start inetd, camped on the specified port but inetd, properly, failed as soon as it tried to start the service (running as user nobody makes doing setuids difficult :-) Tests by our staff from the command line indicate that any user is able to start inetd with a local config file associating a service with a non standard port. It doesn't WORK but it does attach to the port. Leading to some DOS possibilities, albiet not very interesting ones. Recommendation: A number of the executables located in /sbin and /usr/sbin are never going to be invoked for any legitimate use by anyone other than the superuser. In particular, servers such as portmap and inetd run by non-root users are unlikely to do what was intended. It seems a prudent measure to simply not set execute permission by "other" on such programs during the install, giving the user a handy "Permission denied" message when such an attempt is made. For those reading quickly, I am NOT recommending removing execute permission on ALL of /sbin/* and /usr/sbin/*, only on programs such as "portmap", "inetd", "lpd", "syslogd", "halt", "reboot" and others which perform no useful function to normal users. /sbin/init already enforces this condition, how about expanding it? /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Ethernet de driver problem on 3.5 stable
I have run into an issue with the de driver and Dlink quad cards under 3.5 stable. Despite the messages from the driver, claiming to be in full duplex, (see trimmed dmesg output below) it's not. I removed a working Intel fxp card from a system and installed the Dlink quad card. Same cable, same switch port (HP 4000M locked at 100 Full Duplex). After booting the machine, slogin session felt like duplex was mismatched (after enough times, one recognizes the symptoms). The switch was seeing CRC errors about once a minute and netstat -in showed lots of collisions (which can not occur in FD Mode) and 1-2 Oerrs per minute. Locking the HP port to 100 Half-Duplex has reduced the Oerrs to four in 24 hours, along with about 1500 collisions (which are expected in HD). slogin sessions no longer feel like the duplex is mismatched. ifconfig claims the card is still in full duplex mode. As we did not see this problem with the Intel, I am not suspecting the cable or the switch port. Is there a known problem with the Dlinks or is this a possible issue in the driver? /\/\ \/\/ FreeBSD 3.5-STABLE #6: Wed Nov 8 18:28:20 EST 2000 Probing for devices on PCI bus 2: de0: Digital 21143 Fast Ethernet rev 0x41 int a irq 11 on pci2.4.0 de0: 21143 [10-100Mb/s] pass 4.1 de0: address 00:80:c8:c9:8c:60 de1: Digital 21143 Fast Ethernet rev 0x41 int a irq 9 on pci2.5.0 de1: 21143 [10-100Mb/s] pass 4.1 de1: address 00:80:c8:c9:8c:61 de2: Digital 21143 Fast Ethernet rev 0x41 int a irq 5 on pci2.6.0 de2: 21143 [10-100Mb/s] pass 4.1 de2: address 00:80:c8:c9:8c:62 de3: Digital 21143 Fast Ethernet rev 0x41 int a irq 10 on pci2.7.0 de3: 21143 [10-100Mb/s] pass 4.1 de3: address 00:80:c8:c9:8c:63 de1: enabling 100baseTX port de0: enabling 100baseTX port de0: enabling Full Duplex 100baseTX port de1: enabling 100baseTX port de1: enabling Full Duplex 100baseTX port To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Time to close the list?
How about simply 3.Automatically delete all MIME parts /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Servers with large amounts of RAM?
Is there a good reference URL for configuring FreeBSD with large amounts of RAM? I seem to remember there being "issues" with over 1GB but I don't remember the details and the search engine on www.freebsd.org is currently down. /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Flipping ARP ?
Running 3.2 RELEASE, I have 2 fxp cards (one on the motherboard) with two different addresses plugged into the same HP 2424M switch (not broken into seperate VLANs yet). About once an hour, fxp0 seems to steal the arp for fxp1 for one second: Jun 3 00:04:16 sgm1 /kernel: arp: 00:90:27:23:9e:ea is using my IP address 209.115.93.28! Jun 3 00:04:16 sgm1 /kernel: arp: 00:a0:c9:ed:e4:12 is using my IP address 209.115.93.28! Jun 3 00:25:16 sgm1 /kernel: arp: 00:90:27:23:9e:ea is using my IP address 209.115.93.28! Jun 3 00:25:16 sgm1 /kernel: arp: 00:a0:c9:ed:e4:12 is using my IP address 209.115.93.28! Jun 3 00:46:17 sgm1 /kernel: arp: 00:90:27:23:9e:ea is using my IP address 209.115.93.28! Jun 3 00:46:17 sgm1 /kernel: arp: 00:a0:c9:ed:e4:12 is using my IP address 209.115.93.28! Jun 3 01:08:57 sgm1 /kernel: arp: 00:90:27:23:9e:ea is using my IP address 209.115.93.28! Jun 3 01:08:57 sgm1 /kernel: arp: 00:a0:c9:ed:e4:12 is using my IP address 209.115.93.28! Jun 3 01:29:57 sgm1 /kernel: arp: 00:90:27:23:9e:ea is using my IP address 209.115.93.28! Jun 3 01:29:57 sgm1 /kernel: arp: 00:a0:c9:ed:e4:12 is using my IP address 209.115.93.28! Jun 3 01:50:57 sgm1 /kernel: arp: 00:90:27:23:9e:ea is using my IP address 209.115.93.28! Jun 3 01:50:57 sgm1 /kernel: arp: 00:a0:c9:ed:e4:12 is using my IP address 209.115.93.28! fxp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 148.59.160.1 netmask 0xff00 broadcast 148.59.160.255 ether 00:a0:c9:ed:e4:12 media: autoselect (100baseTX full-duplex) status: active supported media: autoselect 100baseTX full-duplex 100baseTX 10baseT/UTP full-duplex 10baseT/UTP fxp1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 209.115.93.28 netmask 0xfff8 broadcast 209.115.93.31 ether 00:90:27:23:9e:ea media: autoselect (100baseTX full-duplex) status: active supported media: autoselect 100baseTX full-duplex 100baseTX 10baseT/UTP full-duplex 10baseT/UTP Comments? /\/\ \/\/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: File system gets too fragmented ???
On Thu, May 27, 1999 at 07:15:56AM -0700, Don Lewis wrote: } } The problem seems to be that with successive updates that slightly change the } size of files, or add or delete files, that a large number of unallocated } fragments are created. Long ago, back when disks were small, slow and expensive, someone wrote a program that properly defragged a Unix filesystem. It was slow and clunky (run time was measured in days) but it DID work. I don't appear to have it handy anymore but you might try checking ancient comp.sources archives. Sorry, it's been too long to remember the program name. Back in another lifetime, I actually used the above mentioned program to maintain an active filesystem with a similar fragmentation problem. Eventually, we determined that it was much faster to run a script that locked a directory, rewrote the entire directory with tar, then removed the old files and directory. If you have periods where pieces of your filesystem is quiescent and script carefully (we actually compared checksums of every file), this should let you limp along until you come up with a better solution. /\/\ \/\/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
