Re: jail cpu/memory resource limits question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Monday, April 09, 2007 15:38:01 +0300 Evren Yurtesen <[EMAIL PROTECTED]> wrote: > Hi, > > FreeBSD supports jail cpu/memory resource limits. > http://wiki.freebsd.org/JailResourceLimits > > I hear that these are very inefficient (compared to FreeVPS for example) > and with over 1000 processes it creates noticable overhead. Is this true? Unless I'm missing something, these aren't included *in* FreeBSD at this time, but are only distributed as patches to it ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGIPcm4QvfyHIvDvMRAqVjAJ9Zz7136v341RnqvLvdiy+LkUUTvQCffyoL teIcJfeSXqjrob53cF6L+qo= =dFQd -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: technical comparison
On Sun, 27 May 2001, Doug Barton wrote: > Andrew Reilly wrote: > > > It is quite concievable that a performance tweak to the IMAP > > server could involve a header cache in a relational database of > > some sort, and that would certainly contain references to the > > individual files, which would then be accessed randomly. > > You might want to give mbox format a try. imap-uw will use this > format if you perform a few tweaks described in the documentation that > comes with it. Basically, instead of the mailbox being in plain text > it creates a type of database at the top of the file that describes > the contents. Makes access much faster for large (> 1k letters) > mailboxes. what you are suggesting sounds like something that Cyrus-IMAP already done, using Berkeley-DB ... loading up several thousand email's and sorting them takes no time ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Idea about "skeleton jail"
On Wed, 2 Feb 2005, Xin LI wrote: 在 2005-02-01二的 11:40 +0100，Pawel Jakub Dawidek写道： The thing that can be useful IMHO is possibility to use reboot(8)/shutdown(8), etc. inside a jail, but... I'm unfortunately too busy with other (probably less interesting, but profitable) projects. Quick question: Is this mean we can have init(8) running in jail? alias reboot 'kill -TERM -1' alias shutdown 'kill -TERM -1' ? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Status of unionfs in -STABLE
On Sun, 9 Nov 2003, Alexey Dokuchaev wrote: > Hi there, > > Recently I've began to consider making some use of unionfs in > (semi-)production environment. Can someone aware of its current status > in -STABLE comment a bit on this subject? I use it *quite* extensively on all my production servers ... one is running >90 unionfs mounted file systems to service as many jail'd environments ... current uptime on all 4 servers is *knock on wood* 27 days, without incident. There are a couple of conditions that I've noticed can force a crash as a result of unionfs, pkg_delete seeming to be one of them, and trying to work with a UNIX socket being the other ... Beyond that, I've been using unionfs for almost 2 years now ... there was a period there where I was hitting some major limits with vfs "file descriptors" that both Tor and David did work on ... but, beyond those, I've not been disappointed with using unionfs ... One caveat I will say though ... if it crashes, fsck is *painfully* slow ... unionfs creates a bunch of 'zero length directories', and fsck has to go through and clear each and every one of those ... I've had fsck's last >11hrs on a 100Gig file system :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Discussion on the future of floppies in 5.x and 6.x
On Thu, 8 Jan 2004, Michel TALON wrote: > > And, further, some of us don't have (and don't want) CD burners, and even > > if we had 'em, don't want to burn (no pun intended ;) a CD blank just to > > install an OS, when we can just (re-)use 2 floppies and do it across the > > LAN from a local FTP mirror, which is as fast as a CD drive anyway. > > Sincerely FreeBSD developers have more important tasks than spending > hours to fit an installable system on floppies. When FreeBSD used > one floppy, it was tolerable to do floppy installs. With 2 or 3 floppies > it is awfully slow, i have done once and will never do it again. I still use floppies to do my installs, and find getting the base system up over FTP to generally take <30minutes *shrug* Faster, IMHO, then downloading the ISO and burning it to a CD .. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel Virtual Address Space
On Thu, 29 Jan 2004, Sridhar Chellappa wrote: > As part of the Bootup sequence, I see create_pagetables allocate only 30 > Pages for Page Table entries in non-PAE mode and 120 pages in PAE mode. > Does this mean that all the kernel mode entities get only 4 * 30 * 1024 > * 1024 = 120 MB worth of Address Space ? Can I tune the kernel virtual > address space by just changing the "NKPT" define in pmap.h ? I don't believe so ... on our servers, we set the KVA_PAGES value: jupiter# grep KVA /etc/make.conf CFLAGS= -O -mpentium -pipe -g -DKVA_PAGES=512 COPTFLAGS= -O -mpentium -pipe -DKVA_PAGES=512 we do it in make.conf, since doing it into the kernel config itself doesn't propogate to various userland binaries that also need to know of the change ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Subversion/CVS experiment summary
On Mon, 9 Feb 2004, Michael Reifenberger wrote: > Hi, > first, this seems to be a good analysis of SVN and a good > starting point for thinking about moving away from CVS. I missed the original thread here, so this point may have already been made ... but ... we tried to use subversion for a project recently, and made a *big* mistake of upgrading to a newer version from what we started with ... and could no longer access the repository ... apparently there is a 'dump / reload' procedure that we weren't aware of at the time, but this is something that should be watched for ... >From the INSTALL file: Version 0.34.0 (released 3 December 2003, from revision r7859) http://svn.collab.net/repos/svn/tags/0.34.0 # ## WARNING WARNING WARNING WARNING WARNING WARNING WARNING ## # ## ## ## This release makes an incompatible change to the Subversion ## ## database.Repositories created with versions of Subversion ## ## prior to 0.34 will not work with Subversion 0.34. ## ## To upgrade, first use 'svnadmin dump' with your existing ## ## Subversion binaries. Then upgrade your binaries to 0.34, and ## ## use 'svnadmin load' to create a new repository from your ## ## dumpfile. ## ## Don't forget to copy any custom configuration/hooks from the ## ## old to the new repository. ## ## ## # note that this was pre-0.34, but since its still "under development", there is always the chance that this happens again ... a load of the system took 49hrs, I believe was mentioned ... how long to dump/reload the system once its already "in subvsersion" format? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
How do inodes work?
I'm fsck'ng a drive right now, and right now its up to: ZERO LENGTH DIR I=8913556 OWNER=root MODE=40755 SIZE=0 MTIME=May 10 18:36 2004 CLEAR? yes but according to df -i: # df -i /dev/da0s1h Filesystem 1K-blocksUsed Avail Capacity iused ifree %iused Mounted on /dev/da0s1h 119837208 101467120 878311292% 7460715 7587989 50% so I take there are 'gaps' in the inode list? it doesn't re-use freed ones but keeps climbing until maybe it rolls around or something? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fsck: % done possible?
right now, my fsck is reporting: ZERO LENGTH DIR I=9222075 OWNER=root MODE=40755 SIZE=0 MTIME=May 10 17:33 2004 CLEAR? yes any way of findign out what the max I= will be, so that one can know how close to the end things are? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck: % done possible?
On Sun, 16 May 2004, Dan Nelson wrote: > In the last episode (May 16), Marc G. Fournier said: > > > > right now, my fsck is reporting: > > > > ZERO LENGTH DIR I=9222075 OWNER=root MODE=40755 > > SIZE=0 MTIME=May 10 17:33 2004 > > CLEAR? yes > > > > any way of findign out what the max I= will be, so that one can know how > > close to the end things are? > > Run "dumpfs /mountpoint | head", and multiply ncg by ipg. That'll give > you your total inode count. 9 million inodes seems awfully high, so > it's got to be near the end. Actually, it hit >14million by the time the fsck finished ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck: % done possible?
Cause I never knew about that? :) I take it that that is the SIGINFO refer'd in: If fsck receives a SIGINFO (see the ``status'' argument for stty(1)) sig- nal, a line will be written to the standard output indicating the name of the device currently being checked, the current phase number and phase- specific progress information. Wish I had known that yesterday ... :( On Sun, 16 May 2004, Julian Elischer wrote: > how about just hitting ^T? > > > On Sun, 16 May 2004, Marc G. Fournier wrote: > > > > > right now, my fsck is reporting: > > > > ZERO LENGTH DIR I=9222075 OWNER=root MODE=40755 > > SIZE=0 MTIME=May 10 17:33 2004 > > CLEAR? yes > > > > any way of findign out what the max I= will be, so that one can know how > > close to the end things are? > > > > > > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > > Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 > > ___ > > [EMAIL PROTECTED] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Jail Replication
On Thu, 13 Feb 2003, Anders Nordby wrote: > Hi, > > On Tue, Feb 11, 2003 at 09:38:19PM -0400, The Hermit Hacker wrote: > >>The easiest way is to set the jail up as a file using vnconfig. > > there are various software packages that will not work in a vnconfig > > environment ... I tried using it, and one of the issues I hit was a > > distinct lack of inodes until you got into some relatively large vnodes > > ... postfix was one piece of software that I just couldn't get to work in > > a vnode, as it always told me the message was too large, yet I had >30Meg > > of free space ... > > Like I told you some time ago, you can set message_size_limit to 0 to > work around this. It may not be something you want to stay that way, but > at least it works. Actually, if I recall correctly, the issue was one of a lack of inodes, which setting message_size_limit to 0 doesn't help ... I even played with increasing the # of inodes, and the lose of space that resulted, I didn't find, warranted using it ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.8-stable kernel panic
and the problem is/was? On Sun, 14 Sep 2003 [EMAIL PROTECTED] wrote: > Hello, > > It's been almost a month now since I posted the original message on the > list and I'm wondering about the progress on resolving this problem. > > I still can reproduce the panics after cvs-supping to RELENG_4 ~ 23:00 EDT > today. > > Thanks much. > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [SAtalk] Partial analysis of FreeBSD/spamass-milter hang ...
Okay, have added what I think are the appropriate FreeBSD mailing lists
for this, since I know I can't answer this :(
On 13 Feb 2002, Craig Hughes wrote:
> Ok, any perl/BSD gurus out there? It spawns a new process but then
> hangs trying to read STDIN from the new subprocess? This is either a
> BSD bug or a perl-on-BSD bug, I think. There might be a way to work
> around it though -- the trick would be to find some other forking tcp
> daemon which does work...
>
> C
>
> On Tue, 2002-02-12 at 19:07, Marc G. Fournier wrote:
> >
> > Okay, here you go ... a hang:
> >
> > ===
> > logmsg: connection from earth.hub.org [ 64.49.215.11 ] at port 4329
> > logmsg: before spawn
> >
> > logmsg: after spawn
> >
> > logmsg: connection from earth.hub.org [ 64.49.215.11 ] at port 4331
> > logmsg: before spawn
> >
> > logmsg: after spawn
> >
> > =
> >
> > And pertinent area of code:
> >
> > =
> > logmsg "before spawn\n";
> > spawn sub {
> > $|=1; # always immediately flush output
> >
> > logmsg "after spawn\n";
> > # First request line off stream
> > local $_ = ;
> >
> > logmsg "got STDIN\n";
> > if (!defined $_) {
> > protocol_error ("(closed before headers)");
> > return 1;
> > }
> > =
> >
> > On 12 Feb 2002, Craig Hughes wrote:
> >
> > > Ok, interesting. n(spamc)+1 spamd's means that the fork already
> > > happened for both spamd's. Could you stick a trace on the spamd process
> > > though instead of spamass-milter? I'd like to try and figure out where
> > > it's getting to before it gets stuck. Possible alternative to ktrace
> > > (and possibly more useful) would be to add logging messages to the spamd
> > > code just after where it forks to see how far it's getting before it
> > > jams up.
> > >
> > > C
> > >
> > > On Tue, 2002-02-12 at 18:08, Marc G. Fournier wrote:
> > > >
> > > > Don't know how helpful this will be, but, just started it up and watched
> > > > it hang ...
> > > >
> > > > According to /var/log/maillog, as previously noted, the hang is based on a
> > > > simultaneous arrival of two messages:
> > > >
> > > > Feb 12 22:01:53 earth sendmail[91753]: g1D21pkw091747: to=<[EMAIL PROTECTED]>,
>delay=00:00:02, xdelay=00:00:00, mailer=cyrus, pri=30679, relay=localhost, dsn=2.0.0,
>stat=Sent
> > > > Feb 12 22:01:53 earth sendmail[91692]: g1D21bkw091692: Milter add: header:
>X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.01
> > > > Feb 12 22:01:54 earth sendmail[91758]: g1D21bkw091692: to=<[EMAIL PROTECTED]>,
>delay=00:00:17, xdelay=00:00:01, mailer=cyrus, pri=138802, relay=localhost,
>dsn=2.0.0, stat=Sent
> > > > Feb 12 22:02:01 earth sendmail[91780]: g1D21wkw091780:
>from=<[EMAIL PROTECTED]>, size=13424, class=0, nrcpts=1,
>msgid=<[EMAIL PROTECTED]>, proto=ESMTP,
>daemon=MTA, relay=mail2.stockwatch.com [207.102.62.11]
> > > > Feb 12 22:02:01 earth sendmail[91819]: g1D221kw091819: from=<>, size=6395,
>class=0, nrcpts=1, msgid=<[EMAIL PROTECTED]>, proto=ESMTP,
>daemon=MTA, relay=zanaco.com [64.49.215.210]
> > > >
> > > > processes of hte spam programs shows:
> > > >
> > > > earth# ps ax | grep spam
> > > > 90082 ?? IsJ0:00.10 /usr/bin/perl /usr/local/bin/spamd -d -A
>64.49.215.11 -u nobody -s local1
> > > > 91784 ?? IJ 0:00.00 /usr/bin/perl /usr/local/bin/spamd -d -A
>64.49.215.11 -u nobody -s local1
> > > > 91821 ?? IJ 0:00.00 /usr/bin/perl /usr/local/bin/spamd -d -A
>64.49.215.11 -u nobody -s local1
> > > > 90171 p1 IJ 0:00.20 /usr/local/bin/spamass-milter /var/run/spamass.sock
> > > > 91783 p1 IJ 0:00.01 /usr/local/bin/spamc
> > > > 91820 p1 IJ 0:00.01 /usr/local/bin/spamc
> > > >
> > > > And a tail end of a ktrace shows (before I killed off all the processes),
> > > > using kdump -l:
> > > >
> > > > (c) Copyright 2002 Canjex Publishing Ltd. http://www.stockwatch.com\r
> > > > \r
> > > > \r
> > > > \r
> > > >
4.5-STABLE panicks ... KVA_PAGES the solution?
Morning ... I have a server with the following specs from DMESG: Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-STABLE #7: Fri Apr 12 09:20:30 CDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/kernel Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (996.84-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x387fbff real memory = 3221225472 (3145728K bytes) avail memory = 3135082496 (3061604K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 16 pins in IOAPIC #1 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 4, version: 0x000f0011, at 0xfec0 io1 (APIC): apic id: 5, version: 0x000f0011, at 0xfec01000 Which crashes on me at around 2am in the morning (either after 24 or 48hrs of uptime, depending on my luck) with the following error: | panic: vm_map_entry_create: kernel resources exhausted | mp_lock = 0101; cpuid = 1; lapic.id = 0100 | boot() called on cpu#1 Attached at the bottom of this is my current kernel config ... last night, I ran top on the system and cut-n-paste the results from when it hung, which look like: last pid: 84988; load averages: 19.82, 57.35, 44.426 up 0+23:33:12 02:05:00 5021 processes:16 running, 5005 sleeping CPU states: 8.7% user, 0.0% nice, 24.3% system, 2.2% interrupt, 64.7% idle Mem: 2320M Active, 211M Inact, 390M Wired, 92M Cache, 199M Buf, 4348K Free Swap: 3072M Total, 1048M Used, 2024M Free, 34% Inuse, 448K Out So, I have plenty of swapspace left, lots of idle CPU and a whole whack of processes ... Someone suggested setting KVA_PAGES higher then the default for this, but, as this is a production server, and its not something I've ever played with, I'd like to know what the ramifications are ... The server has 3Gig of RAM now ... according to opt_global.h, KVA_PAGES is set to 256 (1G) right now ... but if its 1G by default, how does a system withi <1G of RAM in it "work"? Or does this limit something else altogether? I'm not finding any good 'reading material' on this so far, but from waht I found through a search, it seems that its recommended to be set to 768(3G) vs 256(1G)? Thanks for any help in advance .. --- machine i386 cpu I686_CPU ident kernel maxusers512 options NMBCLUSTERS=15360 options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM options SHMMAXPGS=98304 options SHMMAX=(SHMMAXPGS*PAGE_SIZE+1) options SYSVSEM options SEMMNI=2048 options SEMMNS=4096 options SYSVMSG #SYSV-style message queues options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM#Rate limit bad replies options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O device isa device pci device scbus # SCSI bus (required) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass# Passthrough device (direct SCSI access) device amr # AMI MegaRAID device sym device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0at atkbdc? irq 12 device vga0at isa? pseudo-device splash device sc0 at isa? flags 0x100 device npx0at nexus? port IO_NPX irq 13 device sio0at isa? port IO_COM1 flags 0x10 irq 4 device sio1at isa? port IO_COM2 irq 3 device miibus # MII bus support device fxp # Intel EtherExpress PRO/100B (82557, 82558) pseudo-device loop# Network loopback pseudo-device ether # Ethernet support pseudo-device pty 256 # Pseudo-ttys (telne
Re: 4.5-RELEASE generic kernel crashing on sysctl -a
On Thu, 16 May 2002, Gautham Ganapathy wrote: > Hi > > I had posted this sometime back, but didn't receive much feedback > > After installing 4.5-RELEASE, (BSD Mall Feb 2002 CD), when I ran > 'sysctl -a', the kernel crashed with the foll message. > > Fault trap 12: page fault while in kernel mode > fault virtual address = 0x6351ec0c > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc02207c > stack pointer = 0x10:0xede0ebf8 > frame pointer = 0x10:0xcde0ee20 > code segment = base 0x0, limit 0xff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupts enabled, resume, IOPL = 0 > current process = 228 (sysctl) > interrupt mask = > trap number = 12 > panic : page fault Something cool I just found searching for a similar issue on the WEB is information contained in: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/advanced.html Section 18.13 talks about how the above is next to useless in itself, but if you use the 0xc02207c value in the instruction pointer field, you can narrow down where the problem is using nm ... the problem is that a new compile of the kernel will show different values ... for instance, one of my *old* /kernel.GENERICs shows: jupiter> nm -n /kernel.GENERIC | grep c02207c jupiter> nm -n /kernel.GENERIC | grep c02207 jupiter> nm -n /kernel.GENERIC | grep c0220 c01c0220 T solisten c02200dc T nfsrv_getattr c02206e8 T nfsrv_setattr While my 4.5-STABLE kernel from April shows: jupiter> nm -n /kernel | grep c02207c jupiter> nm -n /kernel | grep c02207 jupiter> nm -n /kernel | grep c0220 c0220038 t psmintr c0220844 t psmpoll c02208a8 t mouse_id_proc1 c0220914 t mouse_ext_command c0220988 t enable_groller c02209cc t enable_gmouse c0220a04 t enable_aglide c0220a50 t enable_kmouse c0220b08 t enable_mmanplus c0220bd0 t enable_msexplorer c0220c60 t enable_msintelli c0220cc4 t enable_4dmouse c0220d28 t enable_4dplus c0220d5c t enable_versapad c0220ddc t psmresume c0220e68 t sysctl_machdep_comdefaultrate c0220f5c t sio_pci_attach c0220fd0 t sio_pci_kludge_unit So, the question is, what does yours show for your /kernel.GENERIC? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: reboot your own jail ?
web interface that is password protected that does: ssh root@ kill -TERM -1 On Thu, 16 May 2002, Patrick Thomas wrote: > > currently I reboot jails with this process: > > 1. someone logs into the jail and runs `kill -KILL -1` > 2. someone logs onto the BASE machine and starts it up again. > > I wish I could do this without involving the admin of the base machine. > > Has anyone come up with a strategy for allowing the root jail user to > successfully reboot their own jail without outside help ? > > I can think of some horrible hacks involving constantly checking if the > jail is runningand if it ever stops (presumably someone rebooted it) > then start it again...hopefully there is sonhmething more elegant than > that. > > --pt > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: reboot your own jail ?
from the man page: Managing the Jail Normal machine shutdown commands, such as halt(8), reboot(8), and shutdown(8), cannot be used successfully within the jail. To kill all processes in a jail, you may log into the jail and, as root, use one of the following commands, depending on what you want to accomplish: kill -TERM -1 kill -KILL -1 Last I read, a process couldn't trap SIGKILL to do anything with it, wheres SIGTERM is trappable, so a proper shutdown of the process can be accomplished, whereas -KILL just blows it out of the water ... On Thu, 16 May 2002, Patrick Thomas wrote: > > why -TERM ? the jail man page recommends -KILL ... just curious... > > On Thu, 16 May 2002, Marc G. Fournier wrote: > > > > > web interface that is password protected that does: > > > > ssh root@ kill -TERM -1 > > > > > > > > > > > > On Thu, 16 May 2002, Patrick Thomas wrote: > > > > > > > > currently I reboot jails with this process: > > > > > > 1. someone logs into the jail and runs `kill -KILL -1` > > > 2. someone logs onto the BASE machine and starts it up again. > > > > > > I wish I could do this without involving the admin of the base machine. > > > > > > Has anyone come up with a strategy for allowing the root jail user to > > > successfully reboot their own jail without outside help ? > > > > > > I can think of some horrible hacks involving constantly checking if the > > > jail is runningand if it ever stops (presumably someone rebooted it) > > > then start it again...hopefully there is sonhmething more elegant than > > > that. > > > > > > --pt > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
How to dump a 4gig system on panic ?
Evening all ... I have a 4gig Dual CPU system that is giving me kernel panic's ... Doug White suggested getting a trace, but, alas, not figuring I'd ever need to do such, my swap looks like: jupiter# pstat -s Device 1K-blocks UsedAvail Capacity Type /dev/amrd0s1b 524160 169116 35504432%Interleaved /dev/ramrd1s1b2621312 168992 2452320 6%Interleaved Total 3145472 338108 280736411% So nothing large enough for a dumpdev ... I do have a file system that has 8gig free on it right now: /dev/amrd1s1a 66972328 54742133 821185687%/v1 But, reading through the 'dumpon' man page, it says not to use a device that has a file system on it ... The server itself is both remote, and production, which makes using DDB near impossible ... So, how do ppl go about doing such a dump in a case like this, or am I totally out of luck on this? Is there any way of using that 8gig for this? Thanks ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to dump a 4gig system on panic ?
Oh, I like the netdump one ... I have a machine sitting right beside this one that I can use to dump to ... has anyone thought to include this as a 'standard' sort of thing with FreeBSD? So that it keeps up with the current code? On Fri, 17 May 2002, Andrew Gallatin wrote: > > > There are 3 things you could do: > > a) Limit your memory size in the loader > > b) Use partial dumps > > c) Use network dumps if you have another machine to run the dump > server on. > > Both the netdump & partial dump code can be found at: > > http://www.cs.duke.edu/~anderson/freebsd/ > > Both may be a little out of date & require some work to get working > with a recent -stable, as they were developed in the days when 4.0 was > -current. > > > Drew > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to dump a 4gig system on panic ?
Well, downloaded the files (a .tar.gz would be nice? *grin*) and the client built perfectly, and kldload worked fine ... is there some way someone can suggest of 'simulating a crash'? Some way to test to make sure that it is working as expected? I have a 4.6-PRE machine on my desk that I'd like to test with before I try it on "the real thing", if at all possible? On Fri, 17 May 2002, Andrew Gallatin wrote: > > Marc G. Fournier writes: > > > > Oh, I like the netdump one ... I have a machine sitting right beside this > > one that I can use to dump to ... has anyone thought to include this as a > > 'standard' sort of thing with FreeBSD? So that it keeps up with the > > current code? > > > > > > I plan to integrate partial dumps as an option at some point, but my > only -current machines are alphas, so I need to get gdb working again > there first. > > Drew > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to dump a 4gig system on panic ?
Okay, seem to be about halfway there ... client kldload's no problem, server runs ... do a ctl-alt-esc to get into DDB and type panic, and it gives a message that its looking for the server and it finds it on the right IP ... then it prints out a '1023' and finishes the panic ... On the 'dump server', a vmcore gets created, but its zero length ... thoughts? On Fri, 17 May 2002, Andrew Gallatin wrote: > > Marc G. Fournier writes: > > > > Well, downloaded the files (a .tar.gz would be nice? *grin*) and the > > client built perfectly, and kldload worked fine ... is there some way > > someone can suggest of 'simulating a crash'? Some way to test to make > > sure that it is working as expected? I have a 4.6-PRE machine on my desk > > that I'd like to test with before I try it on "the real thing", if at all > > possible? > > break into ddb & do: > ddb > call dumpsys() > > Unless you're running a savecore which supports partial dumps, you > need to disable partial dumps (sysctl net.net_dump.partial=0). > > And remember, you'll be spewing the contents of your ram (possibly > passwords, etc) across the network in clear text. > > Drew > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to dump a 4gig system on panic ?
Well, I have a machine to debug/test this on, if you can provide some directions on how to debug and get her up to date? :) With the larger and larger systems that ppl are implementing, is this something that might be useful to get into the core system? On Sat, 18 May 2002, Andrew Gallatin wrote: > > Marc G. Fournier writes: > > > > Okay, seem to be about halfway there ... client kldload's no problem, > > server runs ... do a ctl-alt-esc to get into DDB and type panic, and it > > gives a message that its looking for the server and it finds it on the > > right IP ... then it prints out a '1023' and finishes the panic ... > > > > On the 'dump server', a vmcore gets created, but its zero length ... > > > > thoughts? > > As I said, it hasn't been used for quite some time. It may require > work to get it working again. > > Drew > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Security of a JAIL UDP patch
U, named currently does work within a jail ... I run several at the
moment ...
On Thu, 26 Sep 2002, Martin Matuska wrote:
> I would like to ask which aspects has this patch on security of a jailed
> environment.
> This patch enables the use of named or ircd in jails.
>
> --- in_pcb.c.old Mon Mar 18 23:57:57 2002
> +++ in_pcb.c Tue Mar 19 09:52:45 2002
> @@ -501,6 +501,8 @@
> int error;
>
> if (inp->inp_laddr.s_addr == INADDR_ANY && p->p_prison != NULL) {
> + if (inp->inp_lport != 0)
> + inp->inp_laddr.s_addr = htonl(p->p_prison->pr_ip);
> bzero(&sa, sizeof (sa));
> sa.sin_addr.s_addr = htonl(p->p_prison->pr_ip);
> sa.sin_len=sizeof (sa);
>
> Patch author was Lamont Granquist [EMAIL PROTECTED]
> Reference:
> http://www.freebsd.org/cgi/getmsg.cgi?fetch=393634+395986+/usr/local/www/db/
> text/2002/freebsd-stable/20020331.freebsd-stable
>
> Thank you very much
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: I'm leaving the project
On Tue, 17 Dec 2002, Matthew Dillon wrote: > > : > :Matt Dillon wrote: > :> Thanks to my dear friend Warner Losh. I've decided to leave FreeBSD and > :> flame in another project. Maybe I could join OpenBSD, the seem to share > :> my views on how to deal with other people. > :> > :> I hereby give maintainership of all my code to Warner, or, whoever wants > :> it, for that matter. > : > :Does anyone know why this person is trying to (poorly) impersonate MD? > > Probably because I lambast him mercilessly for being such a whimp. It's > kinda sad, actually. He's probably not making any friends with the > people running the blind proxies he abuses to post, either. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > God, now this thread gave me a panic (and a heartattack) ... its funny how many times you can read someone's posts, and see their writing style, and still be sucker-punched:) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Squid under FreeBSD 3.3-STABLE ...
I'm running it right now on a 3.3-STABLE machien with a 166Mhz CPU (there are two inthe machine, but FreeBSD won't allow me to bring up the second oen *sigh*)...the machine has 512MB of RAM and ~24Gig of Disk space... The server is configured to use 128MB of RAM, and top is currently reporting: 39237 root 2 0 201M 200M poll 210:10 11.33% 11.33% squid And swap space isn't even being touched: demeter# pstat -s Device 1K-blocks UsedAvail Capacity Type /dev/da0s1b 10535840 1053456 0%Interleaved /dev/da1s1b2621440 262016 0%Interleaved /dev/da2s1b2621440 262016 0%Interleaved /dev/da3s1b2621440 262016 0%Interleaved /dev/da4s1b2621440 262016 0%Interleaved /dev/da5s1b2621440 262016 0%Interleaved /dev/da6s1b2621440 262016 0%Interleaved Total 26255520 2625552 0% All in all, I'm impressed...we did >490k requests through that server yesterday, after only ~7days since we brought it online, with 1800 hosts using it, and an average of 36% hit rate... Looking at the PolyGraph/BakeOff report, it has "FreeBSD Tweaks" in a section to its own...except that it pertains to FreeBSD 2.2.8, so I'm wondering both how much of it still applies as well as whether there is anything new I should be looking at... It lists: 1. Increase per process memory limits (already done) 2. Increase limit on mbuf clusters - netstat -m doesn't seem to indicate it being required, but it can't hurt - did it 3. Disabled TCP delayed acknowledgements (options TCP_ACK_HACK)...?? - can't find a reference to this one...was it just a 2.2.8ism? - didn't do it 4. Decreased TCP's Maximum Segment Lifetime to three seconds - did it 5. Apply a patch to uipc_socket.c to do with "fixing TCP bugs with small packets? - didn't do it 6. Increased system wide and per proces FD limits - did it 7. Increased ephemeral port range to 30,000 (net.inet.ip.portrange.last) - did it 8. Insrease the socket listen queue size (kern.somaxconn) - doesn't appear to exist anymore 9. Set resources limits in /etc/login.conf - did it 10. Disable unnecessary processes - didn't do this, since am using them This document can be found at http://bakeoff.ircache.net ... Comments/ideas on how to improve things? Thanks... Marc G. Fournier [EMAIL PROTECTED] Senior Systems AdministratorAcadia University "These are my opinions, which are not necessarily shared by my employer" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
