Re: RELENG_4 builds on -current
Gerhard Sittig wrote: On Wed, Oct 24, 2001 at 18:27 -0600, Warner Losh wrote: At timing solutions, we build all our products in a chroot jail. [...] We don't build RELEASES in the chroot. We build a system (make world DESTDIR=xxx outside of the chroot) that we then use to build the system (inside the chroot). What I've always been wondering since Kris first mentioned this technique in the thread's course (building -STABLE in a jail on a -RELEASE host or vice versa, IIUC) was the following: There's the host's kernel serving a differing world's userland. We all know what's the usual answer to I just updated my kernel and now -- insert whatever you please -- stopped working. :) What did I miss? Or is it plain luck when things just work and one shouldn't ask why they do? : I have a 10k shell script for doing this. It copies in all the stuff from the parent system which is important to match to the real kernel, including /kernel, the ps program, and basically all other programs that open /dev/kmem or link against libkvm. That means that the build environment works like the host system for all important commands, but acts like the target system for compilation, etc.. It can also copy in and install a list of packages. Basically, it operates off a tarball which is DISC 2. It also uses chroot (not jail, though I suspect he just meant chroot). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Upgrade Apache Web Server
Hi ; I have installed apache web server (Version 1.3.20) from port collection . How do I upgrade this software to version 1.3.22 from port collection ? Please advise . To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Change Prompt
Hi Please ask these questions on [EMAIL PROTECTED] M Hi ; I use bash shell in my FreeBSD machine . How do I change a promt from $ to # when I login as superuser from normal user to root ? my .bashrc script looks as following . PS1=[\u@\h: \w]\$ alias ls='ls -F' alias cp='cp -i' alias mv='mv -i' alias rm='rm -i Another question , what is the function of PS2 and when to use it ? Please advise To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Change Prompt
Another question , what is the function of PS2 and when to use it ? Please advise I advise you to use PS2=smokin'crack? as I do. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
winbindd support for samba
Hi, Is someone working on winbindd support for Free/NetBSD ? #man winbindd NAME winbindd - Name Service Switch daemon for resolving names from NT servers winbindd is a daemon that provides a service for the Name Service Switch capability that is present in most modern C libraries. The Name Service Switch allows user and system information to be obtained from different databases ser- vices such as NIS or DNS. The exact behaviour can be con- figured throught the /etc/nsswitch.conf file. Users and groups are allocated as they are resolved to a range of user and group ids specified by the administrator of the Samba system. Btw, since we don't support winbindd, the samba-devel port should not install the manpage :-/ A winbind deamon is really needed if you have a big environment and you don't want to add all the time MACHINE$ entrys to /etc/passwd, on which samba depends if you have samba acting as a PDC. Winbindd(8) depends on nsswitch support. We have some nsswitch support, but NOT the sun API we could use to complile free available programms like samba. Linux has a SUN compatible NSS implementation. So either we fix or NSS implementation, or we modify with patches the winbindd to support FreeBSD too. Suggestions ? PS: IMHO this is a real issue and we should look how we can soon have a working winbindd on BSD. Martin Blapp, [EMAIL PROTECTED] -- Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: 57E 7CCD 2769 E7AC C5FA DF2C 19C6 DCD1 1B3A EC9C -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade Apache Web Server
Kelvin Ng Chee Hoong [EMAIL PROTECTED] writes: I have installed apache web server (Version 1.3.20) from port collection . How do I upgrade this software to version 1.3.22 from port collection ? Please advise . For the last time, -current is *not* the appropriate place to ask such questions. Please use [EMAIL PROTECTED] or [EMAIL PROTECTED] instead. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT freeze under high load
Looks like the problem below is caused by this commit: dwmalone2001/10/04 06:11:48 PDT Modified files: lib/libc/rpc clnt_vc.c svc_vc.c sbin/mount_portalfs activate.c sys/kern uipc_socket.c uipc_usrreq.c sys/netgraph ng_socket.c sys/sys domain.h un.h usr.sbin/ppp bundle.c ACPI, which I previously wrongly blamed, isn't involved in any way. Right now I am running a very recent -CURRENT, modulo this commit and more recent commits to the same files, i.e. I updated using: # cvs -q -R update -A -P -d # cvs -q -R update -D'Oct 04 15:11' kern/kern_proc.c kern/kern_prot.c kern/uipc_socket.c kern/uipc_usrreq.c netgraph/ng_socket.c netinet/ip_fw.c netinet/raw_ip.c netinet/tcp_subr.c netinet/udp_usrreq.c sys/domain.h sys/socketvar.h sys/un.h All my problems are now gone. This sort of makes sense to me, as the culprit, qmail, is quite socket intensive. Anybody has any idea how to properly fix? Bye, Andrea On Wed, Oct 24, 2001 at 03:31:51PM +0200, Andrea Campi wrote: Hi all, I am trying to diagnose a problem I've been having for a few weeks (I didn't report it earlier because I didn't have much time to hunt for it). The symptom is a total system freeze, i.e. I can't get into DDB. I can repeat it only with qmail, but of course I don't think it's qmail specific in any way; probably something to do with locking. To reproduce it I run: find . -type f | xargs mutt (on my machine, all emails get delivered to me) A kernel from Oct 1 doesn't have this issue; a kernel from Oct 5 has. I'll start binary searching for a commit I can blame. Anybody seen anything like this? -- It is easier to fix Unix than to live with NT. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RELENG_4 builds on -current
On Thu, Oct 25, 2001 at 10:10:11PM +0200, Gerhard Sittig wrote: On Wed, Oct 24, 2001 at 18:27 -0600, Warner Losh wrote: At timing solutions, we build all our products in a chroot jail. [...] We don't build RELEASES in the chroot. We build a system (make world DESTDIR=xxx outside of the chroot) that we then use to build the system (inside the chroot). What I've always been wondering since Kris first mentioned this technique in the thread's course (building -STABLE in a jail on a -RELEASE host or vice versa, IIUC) was the following: There's the host's kernel serving a differing world's userland. We all know what's the usual answer to I just updated my kernel and now -- insert whatever you please -- stopped working. :) What did I miss? Or is it plain luck when things just work and one shouldn't ask why they do? : Things which still rely on libkvm don't work in the jail if it's different than the host version. Under -current there are many more things which use sysctls to obtain their data from the kernel, so the problem is getting less severe. Kris PGP signature
Re: RELENG_4 builds on -current
On Thu, Oct 25, 2001 at 11:53:30PM -0700, Terry Lambert wrote: I have a 10k shell script for doing this. It copies in all the stuff from the parent system which is important to match to the real kernel, including /kernel, the ps program, and basically all other programs that open /dev/kmem or link against libkvm. I'd love to see this. I've daydreamed about magic scripts to automatically install a port/package in its own minimalist jail by auto-populating it with the things it requires (a minimal /etc, appropriate shared libraries, etc). This script might be useful towards that goal. Kris PGP signature
Re: RELENG_4 builds on -current
Kris Kennaway wrote: What I've always been wondering since Kris first mentioned this technique in the thread's course (building -STABLE in a jail on a -RELEASE host or vice versa, IIUC) was the following: There's the host's kernel serving a differing world's userland. We all know what's the usual answer to I just updated my kernel and now -- insert whatever you please -- stopped working. :) What did I miss? Or is it plain luck when things just work and one shouldn't ask why they do? : Things which still rely on libkvm don't work in the jail if it's different than the host version. Under -current there are many more things which use sysctls to obtain their data from the kernel, so the problem is getting less severe. You copy the host versions of these programs in, of course. Why do you think my shell script is 10k instead of 1k? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RELENG_4 builds on -current
Kris Kennaway wrote: On Thu, Oct 25, 2001 at 11:53:30PM -0700, Terry Lambert wrote: I have a 10k shell script for doing this. It copies in all the stuff from the parent system which is important to match to the real kernel, including /kernel, the ps program, and basically all other programs that open /dev/kmem or link against libkvm. I'd love to see this. I've daydreamed about magic scripts to automatically install a port/package in its own minimalist jail by auto-populating it with the things it requires (a minimal /etc, appropriate shared libraries, etc). This script might be useful towards that goal. I'll clean it up and send it to you. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT freeze under high load
On Fri, Oct 26, 2001 at 06:16:12PM +0200, Andrea Campi wrote: All my problems are now gone. This sort of makes sense to me, as the culprit, qmail, is quite socket intensive. Anybody has any idea how to properly fix? This patch changed quite a few things, so it's not obvious exactly what is causing the problem. Do you know if qmail does any discriptor passing? The code makes discriptor passing a bit more mbuf intensive, so it's possible that you're running your machine out of mbufs. I know qmail tends to run machines as hard as it can, so it may have run the machine into the ground. Also, are you running on alpha or i386? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kernel build error
Today's -current build fails on my box with the following: linking kernel vm_fault.o: In function `vm_fault1': vm_fault.o(.text+0x941): undefined reference to `vm_object_set_writeable_dirty' vm_page.o In function `vm_page_insert': vm_page.o(.text+0x4c2): undefined reference to `vm_object_set_writeable_dirty' *** Error code 1 Stop in /usr/obj/usr/src/sys/GALAXY. *** Error code 1 Beech -- Micro$oft: Where can we make you go today? --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT freeze under high load
On Fri, Oct 26, 2001 at 05:52:37PM +0100, David Malone wrote: On Fri, Oct 26, 2001 at 06:16:12PM +0200, Andrea Campi wrote: All my problems are now gone. This sort of makes sense to me, as the culprit, qmail, is quite socket intensive. Anybody has any idea how to properly fix? This patch changed quite a few things, so it's not obvious exactly what is causing the problem. I know. I'd like to look deeper into the issue, but from a quick glance at the code, I don't think I could figure out a way to separate those things and try each one. Do you happen to have separate patches for them, that I could try? Do you know if qmail does any discriptor passing? The code makes discriptor passing a bit more mbuf intensive, so it's possible that you're running your machine out of mbufs. I know qmail tends to run machines as hard as it can, so it may have run the machine into the ground. I'm not 100% sure of how to check, but a grep SOL_SOCKET * in the sources didn't return anything. Also, from what I can understand without really reading all of that #@#@ DJB code, qmail mainly uses pipe and 2 or 3 fifos. AFAIK your commit wasn't intended to change that, but is it possible that a bug did sneak in? Anyway, both ways I can trigger the bug (find . -type f | xargs mutt, and actually running fetchmail -a) do generate a LOT of work, so it's actually possible that your diagnosis (mbuf exhaustion) is correct; trouble is, this shouln't hurt the machine to the point I can't even enter DDB. Also, are you running on alpha or i386? i386, IBM Thinkpad 570E (not that it being a laptop makes any difference, of course ;-)) Bye, Andrea -- Intel: where Quality is job number 0.9998782345! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT freeze under high load
On Fri, Oct 26, 2001 at 07:12:24PM +0200, Andrea Campi wrote: I know. I'd like to look deeper into the issue, but from a quick glance at the code, I don't think I could figure out a way to separate those things and tr each one. Do you happen to have separate patches for them, that I could try? It's a bit hard to seperate the bits out, which is why it happened as one commit. I'll see if I can come up with something to segregate the code out a bit. One possibility would be to add a printf to the internalise and externalise functions in uipc_usrreq.c - that way we can see if it is actually executing the code there. If it's not, then that narrows things down a bit. in the sources didn't return anything. Also, from what I can understand withou really reading all of that #@#@ DJB code, qmail mainly uses pipe and 2 or 3 fifos. AFAIK your commit wasn't intended to change that, but is it possible that a bug did sneak in? Hmm - I don't think my code should have changed fifos or pipes at all. Anyway, both ways I can trigger the bug (find . -type f | xargs mutt, and actually running fetchmail -a) do generate a LOT of work, so it's actually possible that your diagnosis (mbuf exhaustion) is correct; trouble is, this shouln't hurt the machine to the point I can't even enter DDB. Maybe I'll try installing qmail at home and reproducing the problem. Also, are you running on alpha or i386? i386, IBM Thinkpad 570E (not that it being a laptop makes any difference, of course ;-)) OK - that eliminates one possibility ;-) David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: kernel build error
On 26-Oct-01 Beech Rintoul wrote: Today's -current build fails on my box with the following: linking kernel vm_fault.o: In function `vm_fault1': vm_fault.o(.text+0x941): undefined reference to `vm_object_set_writeable_dirty' vm_page.o In function `vm_page_insert': vm_page.o(.text+0x4c2): undefined reference to `vm_object_set_writeable_dirty' *** Error code 1 Stop in /usr/obj/usr/src/sys/GALAXY. *** Error code 1 It's already fixed. re-cvsup. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Giant mutex wrappers implemented, starting wrapping work.
Everyone who is working on Giant unwinding should be aware of the new
giant wrapper routines which allow us to control whether Giant is turned
on around a subsystem with sysctls.
There are several sysctls:
kern.giant.all
kern.giant.proc
kern.giant.file
kern.giant.(etc...)
kern.giant.all defaults to 0 (off). If set to 1 it forces the Giant
wrappers to be turned on for all subsystems regardless of the state
of other kern.giant. sysctls. If set to 0 then Giant is wrapped around
subsystems based on the value of the other kern.giant. sysctls.
General developers should *NOT* mess with any of these sysctls for
the moment.
As various subsystems get wrapped, those doing the Giant unwinding work
will be able to use these sysctls to turn off Giant and test their work.
Those doing Giant unwinding work will also be able to request that other
developers test their work by turning off Giant around a subsystem, yet
still be able to maintain reasonably stable -current systems for their
own work.
Portions of routines that manipulate multiple subsystems may require
that all related Giant management sysctls be turned off in order to
turn off Giant around the routines in question.
Here is an example use for the new wrappers:
/*
* MPSAFE
*/
/* ARGSUSED */
int
getpid(td, uap)
struct thread *td;
struct getpid_args *uap;
{
struct proc *p = td-td_proc;
int s;
s = mtx_lock_giant(kern_giant_proc);
td-td_retval[0] = p-p_pid;
#if defined(COMPAT_43) || defined(COMPAT_SUNOS)
PROC_LOCK(p);
td-td_retval[1] = p-p_pptr-p_pid;
PROC_UNLOCK(p);
#endif
mtx_unlock_giant(s);
return (0);
}
In this example mtx_lock_giant() is called with kern_giant_proc
(the kern.giant.proc sysctl value) as an argument. The routine returns
whether Giant was actually locked or not. The return value must be passed
to a matching mtx_unlock_giant() later on. (This allows the sysctl
variables to change state out from under the system without blowing things
up).
I am going to begin instrumenting the proc and file code with these
wrappers. I would be very happy to see Alfred, John, and others working
on the Giant wrappers to also start using the wrappers. I believe that
the move to force people to start using the main tree again was a good
one that I believe that these routines will greatly improve the speed
at which -current developers are able to work. Those people who are
working on subsystems should feel free to add additional Giant wrapper
variables and sysctls to kern/kern_mutex.c.
Note that these are long term mechanisms, it will probably be several
years of diminishing bugs before we work the races out.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: RELENG_4 builds on -current
On Fri, Oct 26, 2001 at 09:49:42AM -0700, Terry Lambert wrote: Kris Kennaway wrote: On Thu, Oct 25, 2001 at 11:53:30PM -0700, Terry Lambert wrote: I have a 10k shell script for doing this. It copies in all the stuff from the parent system which is important to match to the real kernel, including /kernel, the ps program, and basically all other programs that open /dev/kmem or link against libkvm. I'd love to see this. I've daydreamed about magic scripts to automatically install a port/package in its own minimalist jail by auto-populating it with the things it requires (a minimal /etc, appropriate shared libraries, etc). This script might be useful towards that goal. I'll clean it up and send it to you. Thanks! Kris PGP signature
Re: cu(1) (Was: Re: cvs commit: src/etc/mtree BSD.var.dist)
On Fri, 26 Oct 2001 17:59:33 +0100, Mark Murray [EMAIL PROTECTED] said: Do you have a problem with cu being a port and not in the base system? (ie, a port that gives you _just_ cu with no other UUCP crap?) I think that's a POLA question; I have no fundamental objection. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RELENG_4 builds on -current
Gerhard Sittig [EMAIL PROTECTED] writes: What I've always been wondering since Kris first mentioned this technique in the thread's course (building -STABLE in a jail on a -RELEASE host or vice versa, IIUC) was the following: There's the host's kernel serving a differing world's userland. We all know what's the usual answer to I just updated my kernel and now -- insert whatever you please -- stopped working. :) What did I miss? Or is it plain luck when things just work and one shouldn't ask why they do? : The answer is that the tools used to build world *generally* aren't affected by changes in the kernel. The stuff that usually breaks when your kernel is out of synch (ps, top, ipfw...) isn't needed to build world. Of course, there are exceptions, like trying to run a 4.x or 5.x world on a pre-sigset_t kernel. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel build error
Beech Rintoul [EMAIL PROTECTED] writes: Today's -current build fails on my box with the following: I think it's safe to say, as a general rule, that whenever you hit a build error (as opposed to a run-time bug) you should wait a couple of hours, re-cvsup, rebuild, and check that the problem is still there before you ask the lists about it. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RELENG_4 builds on -current
Dag-Erling Smorgrav wrote: The answer is that the tools used to build world *generally* aren't affected by changes in the kernel. The stuff that usually breaks when your kernel is out of synch (ps, top, ipfw...) isn't needed to build world. Of course, there are exceptions, like trying to run a 4.x or 5.x world on a pre-sigset_t kernel. There's some code that depends on the current kernel version, as obtained from the preprocessor, in order to build. The preprocessor gets this from the sysctl. This type of thing is rare, but there is caode that is variant based on FreeBSD version. For the FreeBSD code itself, this variance is generally hidden in the CVS repository, under the asumption that you will attempt to build your userspace from code that matches your kernel. I've only been bitten twice by this in the history of FreeBSD, but there have been opportunities for this type of thing to happen a dozen times or so. The bottom line is that if you are going to be following the code very closely, expect to get bitten 1.5 times a year (not bad at all). If you are a little more careful in when you choose to grab the code, then you can reduce this risk to two times in ten years (like I have experienced, using FreeBSD or its progenitor for the last decade). If you use the chroot method, then the problem will end up being practically non-existant. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
