Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
Marc G. Fournier wrote: You have more memory than you can allocate kernel memory to provide page table entries for. The only solution is to increase your kernel virtual address space size to accomodate the page mappings. How to do this varies widely by the version of FreeBSD you are using, and, unless you read NOTES and are running a recent -current, is not incredibly well documented, and requires an understanding of how the virtual address space is laid out and managed (which is also not well documented anywhere). Ya, this is the roadblock I'm hitting :( I'm running 4.5-STABLE here, as of this afternoon ... thoughts/suggestiosn based on that? Read the handbook as it existed for 4.5-STABLE, and read NOTES. It (sorta) tells you how to increase your KVA size. Also, is there somethign that I can run to monitor this, similar to running netstat -m to watch nmbclusters? DDB? 8-) 8-). No, there's no stats collected on this stuff, because it's a pretty obvious and straight-forward thing: you have to have a KVA space large enough that, once you subtract out 4K for each 4M of physical memory and swap (max 4G total for both), you end up with memory left over for the kernel to use, and your limits are such that the you don't run out of PTEs before you run out of mbufs (or whatever you plan on allocating). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
On Sat, 20 Apr 2002, Craig Boston wrote: Since -current by default uses devfs, is there a standard way to make the ownership/permissions of device nodes sticky so that they persist across boots? No. Or should we just put the appropriate commands in rc.local ? The problem has been moved to putting them in devfs. Besides bpf, this would be useful, for example, for people who want to change permissions on cd-rom devices to 644 so that non-root users can make iso images (or give a special group cd burner rights). I think you mean mode 660. acd devices already have the insecure permissions 644 in devfs. These are even more insecure than they should be, since read permission is enough to do most ioctls. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
Bruce Evans wrote: On Sat, 20 Apr 2002, Craig Boston wrote: Since -current by default uses devfs, is there a standard way to make the ownership/permissions of device nodes sticky so that they persist across boots? No. Or should we just put the appropriate commands in rc.local ? The problem has been moved to putting them in devfs. I'm pretty sure you can change it in the source code for the device node itself. Unfortunately, it's not handled with a marker-and-data approach, which would let you modify it in the object files, even for node instances that would not normally be created at boot time (using an ELF librarian and a linker set). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
On Sat, 20 Apr 2002, Doug Barton wrote: On Sat, 20 Apr 2002, Craig Boston wrote: Since -current by default uses devfs, is there a standard way to make the ownership/permissions of device nodes sticky so that they persist across boots? rc.devfs Unfortunately, this works poorly for cloned devices. At various meetings, there has been discussion of a devfsd and/or devd; that's probably the vehicle for doing that kind of administrative change. Unfortunately, it doesn't exist yet, although I think Warner had done some prototyping. For now, the only place to make the change is in the kernel, and for a variety of reasons, that's not really desirable (maintaining duplicated passwd entries in statically compiled kernel code isn't wonderful, especially given that we're starting to collide our reserved uids with uids on older UNIX boxes and NIS networks). The BPF group idea is an interesting one from the perspective of assigning users to the group so that they can sniff without great privilege. However, it's worth observing that BPF actually implicitly gives you more rights than it appears if you assign write access to the device, including the ability to *produce* packets that source from other IP addresses and hardware addresses, to influence the localhost interface (which is frequently presumed to be highly trusted), etc. I'd be very cautious about introducing this feature into the base system without some pretty careful analysis first. Off hand, the concerns I'd have would include: - Provides a very high level of privilege relative to the LAN/PPP segments the system is on, in particular relating to the production of link layer network packets that normally the network stack doesn't permit (arp, IP, etc). - Allows bypassing of normal network stack protections that local applications rely on, including the historical port 1024 limits, especially on the localhost interface. - For tunnels, abiity to bypass tunnel protection policies. There's probably more going on also. We should in particular sit down and see whether just providing read access (root:bpf, -rw--r---) is sufficient to protect against these problems. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Upgrade from 4,5Stable-4,5-RELASE . refuse to accept setting from rc.conf
Hi, I have upgraded my box from 4,5-STABLE to 4,5-RELEASE according to http://www.mostgraveconcern.com/freebsd/ But after the upgrade my box does not read the setting from rc.conf (ifconfig shows that the xl0 interface has no IP) Anyone got a idea about what went wrong here? Regards, Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PAM: plain login not print Last login line
Hi. Now I mean plain /usr/bin/login, I don't see Last login from it anymore, it seems it is gone when login was PAMifized. Please restore it back (depending on quietlog as it was before). -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
In message [EMAIL PROTECTED], Robe rt Watson writes: rc.devfs Unfortunately, this works poorly for cloned devices. At various meetings, there has been discussion of a devfsd and/or devd; that's probably the vehicle for doing that kind of administrative change. Unfortunately, it doesn't exist yet, although I think Warner had done some prototyping. Dima is actually working on this problem right now, and he has sent me a prototype which shows great promise. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSH: zombie appearse probably related to PAM
On Sat, Apr 20, 2002 at 20:07:53 +0400, Andrey A. Chernov wrote: On Sat, Apr 20, 2002 at 18:03:07 +0200, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: It happens only with 'localhost' and not in remote case. To reproduce it, call: ssh localhost login normally and then exit. At exit you'll see following message on console (or /var/log/messages): sshd[its_pid]: error: session_by_pid: unknown pid some_pid I can't reproduce this. Well, I'll try to dig out more details after some sleep... Finally I found who is responsoble for zombie. Yes it is PAM as I think initially. This process started in the pam_init_ctx() function in the auth2-pam.c, then dies to zombie. I found it simply printing pid after each fork and looking into 'ps' and error diagnostic above. It means PAM forget to wait for its own child. Please fix. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic:bremfree with today's current and linux-netscape
Hi,
Environment:
FreeBSD xphome.home.ady.ro 5.0-CURRENT FreeBSD 5.0-CURRENT #0:
Sun Apr 21 10:39:36 EEST 2002 i386
XFree86-4.2.0_1,1 (3dfx Velocity 100 graphics card)
gnome-1.4.1b2_2 + sawfish-gnome-1.0.1
linux_base-6.1_1
linux-netscape-communicator-4.79
Panicstring: bremfree: bp 0xc77fb678 not locked
How-to-repeat: launch linux-netscape while in X11
I've attached the stack trace from gdb'ing on the debug kernel file.
I'll keep the core (256Mb) around for a few hours, tell me if you need
further info.
Side note: are those lock order reversal meesages something to worry
about ?
Happy panicing,
Ady (freebsd.ady.ro)
___
| Programming in BASIC causes brain damage. |
| (Edsger Wybe Dijkstra)|
Script started on Sun Apr 21 15:13:31 2002
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-freebsd...
IdlePTD at phsyical address 0x00434000
initial pcb at physical address 0x0031f3a0
panicstr: bremfree: bp 0xc77fb678 not locked
panic messages:
---
panic: recurse
syncing disks... panic: bremfree: bp 0xc77fb678 not locked
Uptime: 4m30s
Dumping 255 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc019ce78 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:346
#2 0xc019d021 in panic (fmt=0xc02bdf5d bremfree: bp %p not locked)
at /usr/src/sys/kern/kern_shutdown.c:490
#3 0xc01cdd0d in bremfree (bp=0xc77fb678) at /usr/src/sys/kern/vfs_bio.c:619
#4 0xc01cf403 in vfs_bio_awrite (bp=0xc77fb678)
at /usr/src/sys/kern/vfs_bio.c:1593
#5 0xc0178204 in spec_fsync (ap=0xcecfd95c)
at /usr/src/sys/fs/specfs/spec_vnops.c:403
#6 0xc0177df1 in spec_vnoperate (ap=0xcecfd95c)
at /usr/src/sys/fs/specfs/spec_vnops.c:121
#7 0xc024d105 in ffs_sync (mp=0xcdf41200, waitfor=2, cred=0xc7765980,
td=0xc02eb300) at vnode_if.h:441
#8 0xc01dbfb7 in sync (td=0xc02eb300, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:1224
#9 0xc019caba in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:254
#10 0xc019d021 in panic (fmt=0xc02ba6c8 recurse)
at /usr/src/sys/kern/kern_shutdown.c:490
#11 0xc01b47a8 in witness_lock (lock=0xced36834, flags=8,
file=0xc02b3c40 /usr/src/sys/kern/kern_descrip.c, line=1114)
at /usr/src/sys/kern/subr_witness.c:533
#12 0xc0195766 in _mtx_lock_flags (m=0xced36834, opts=0,
file=0xc02b3c40 /usr/src/sys/kern/kern_descrip.c, line=1114)
at /usr/src/sys/kern/kern_mutex.c:314
---Type return to continue, or q return to quit---
#13 0xc0187203 in falloc (td=0xcec6ea3c, resultfp=0xcecfdaa0,
resultfd=0xcecfdaa8) at /usr/src/sys/kern/kern_descrip.c:1114
#14 0xc0187e3f in fdcheckstd (td=0xcec6ea3c)
at /usr/src/sys/kern/kern_descrip.c:1532
#15 0xc018b306 in execve (td=0xcec6ea3c, uap=0xcecfdcdc)
at /usr/src/sys/kern/kern_exec.c:372
#16 0xcea21aff in ?? ()
#17 0xc028e69b in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077950728, tf_esi = 145923594, tf_ebp = -1077950768,
tf_isp = -825238156, tf_ebx = -1077950728, tf_edx = 151214976,
tf_ecx = -1077950612, tf_eax = 11, tf_trapno = 12, tf_err = 2,
tf_eip = 685394187, tf_cs = 31, tf_eflags = 582, tf_esp = -1077950784,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1022
#18 0xc0281a0d in syscall_with_err_pushed ()
Cannot access memory at address 0xbfbfc6d0.
(kgdb) q
Script done on Sun Apr 21 15:13:38 2002
Re: Upgrade from 4,5Stable-4,5-RELASE . refuse to accept setting from rc.conf
- Original Message - From: Dennis Pedersen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, April 21, 2002 3:52 PM Subject: Upgrade from 4,5Stable-4,5-RELASE . refuse to accept setting from rc.conf Hi, I have upgraded my box from 4,5-STABLE to 4,5-RELEASE according to http://www.mostgraveconcern.com/freebsd/ But after the upgrade my box does not read the setting from rc.conf (ifconfig shows that the xl0 interface has no IP) Anyone got a idea about what went wrong here? Darn, it was just tip of the iceberg! It seems there are a problem with /usr/libexec/ld-elf.so.1. The file is there (and there is a file called .old). Can i reinstall this file/fix it somehow? I would do the hole upgrade process over again but the ld-elf.so.1 error keeps comming up. Any good ideas? Regards, Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
new expr(1) behaviour breaks libtool
Hi, I see the new new behaviour of expr(1) requires you to add '--' if your commandline arguments might start with a '-'. This does break things a little because our old expr(1) does not understand a '--' in the beginning and the new one don't work right without it. :-((( The place where I noticed it was when libtool started to complain when compiling jade. Libtool does things like: expr -L/export/ports/textproc/jade/work/jade-1.2.1/lib/.libs : -l\(.*\) expr -lsp : -l\(.*\) expr -lm : -l\(.*\) expr -lgrove : -l\(.*\) On -current this now have to be: expr -- -L/export/ports/textproc/jade/work/jade-1.2.1/lib/.libs : -l\(.*\) expr -- -lsp : -l\(.*\) expr -- -lm : -l\(.*\) expr -- -lgrove : -l\(.*\) If we are going to leave this behaviour, we will have to teach libtool how to call expr(1) differently on -stable and -current and it looks like yet again different from the rest of the world. :-((( Yes, I did read the commit message, but I still think the behaviour of the new expr(1) is wrong. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrade from 4,5Stable-4,5-RELASE . refuse to accept setting from rc.conf
On Sun, Apr 21, 2002 at 05:03:02PM +0200, Dennis Pedersen wrote: Hi, I have upgraded my box from 4,5-STABLE to 4,5-RELEASE according to http://www.mostgraveconcern.com/freebsd/ But after the upgrade my box does not read the setting from rc.conf (ifconfig shows that the xl0 interface has no IP) Anyone got a idea about what went wrong here? Darn, it was just tip of the iceberg! It seems there are a problem with /usr/libexec/ld-elf.so.1. The file is there (and there is a file called .old). Can i reinstall this file/fix it somehow? I would do the hole upgrade process over again but the ld-elf.so.1 error keeps comming up. Any good ideas? Dennis, You may have more success in getting your problems resolved by sending mail to the proper mailing list. Try [EMAIL PROTECTED] Now, what exactly did you do? Going from 4.5-stable to 4.5-release is NOT an upgrade. You should probably read chapter 19 of the Handbook. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new expr(1) behaviour breaks libtool
John Hay [EMAIL PROTECTED] writes: I see the new new behaviour of expr(1) requires you to add '--' if your commandline arguments might start with a '-'. This does break things a little because our old expr(1) does not understand a '--' in the beginning and the new one don't work right without it. :-((( I'm almost positive this issue was discussed before. Check the follow ups to the commit. The place where I noticed it was when libtool started to complain when compiling jade. Libtool does things like: expr -L/export/ports/textproc/jade/work/jade-1.2.1/lib/.libs : -l\(.*\) expr -lsp : -l\(.*\) expr -lm : -l\(.*\) expr -lgrove : -l\(.*\) On -current this now have to be: expr -- -L/export/ports/textproc/jade/work/jade-1.2.1/lib/.libs : -l\(.*\) expr -- -lsp : -l\(.*\) expr -- -lm : -l\(.*\) expr -- -lgrove : -l\(.*\) If we are going to leave this behaviour, we will have to teach libtool how to call expr(1) differently on -stable and -current and it looks like yet again different from the rest of the world. :-((( This should exactly match the behavior of any certified UNIX system. Yes, I did read the commit message, but I still think the behaviour of the new expr(1) is wrong. Not according to the Standard, or the response from Garrett's request for clarification of the Standard. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic:bremfree with today's current and linux-netscape
As Adrian Penisoara already reported
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=19645+0+current/freebsd-current
there is panic in -current. I believe it is related to the next
commit:
nectar 2002/04/18 17:45:29 PDT
Modified files:
sys/kern kern_descrip.c kern_exec.c
sys/sys filedesc.h
Log:
When exec'ing a set[ug]id program, make sure that the stdio file descriptors
(0, 1, 2) are allocated by opening /dev/null for any which are not already
open.
Reviewed by:alfred, phk
MFC after: 2 days
Here is my workaround but I am not sure is it correct or not. Seems
falloc() takes care about locking itself.
Index: src/sys/kern/kern_descrip.c
===
RCS file: /home/ncvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.138
diff -u -r1.138 kern_descrip.c
--- src/sys/kern/kern_descrip.c 20 Apr 2002 12:02:52 - 1.138
+++ src/sys/kern/kern_descrip.c 21 Apr 2002 17:04:58 -
@@ -1528,9 +1528,7 @@
if (fdp-fd_ofiles[i] != NULL)
continue;
if (devnull 0) {
- FILEDESC_LOCK(fdp);
error = falloc(td, fp, fd);
- FILEDESC_UNLOCK(fdp);
if (error != 0)
break;
NDINIT(nd, LOOKUP, FOLLOW, UIO_SYSSPACE, /dev/null,
%%%
--
Maxim Konovalov, MAcomnet, Internet Dept., system engineer
phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Upgrade from 4,5Stable-4,5-RELASE . refuse to accept setting from rc.conf
- Original Message - From: Steve Kargl [EMAIL PROTECTED] To: Dennis Pedersen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, April 21, 2002 6:19 PM Subject: Re: Upgrade from 4,5Stable-4,5-RELASE . refuse to accept setting from rc.conf On Sun, Apr 21, 2002 at 05:03:02PM +0200, Dennis Pedersen wrote: Hi, I have upgraded my box from 4,5-STABLE to 4,5-RELEASE according to http://www.mostgraveconcern.com/freebsd/ But after the upgrade my box does not read the setting from rc.conf (ifconfig shows that the xl0 interface has no IP) Anyone got a idea about what went wrong here? Darn, it was just tip of the iceberg! It seems there are a problem with /usr/libexec/ld-elf.so.1. The file is there (and there is a file called .old). Can i reinstall this file/fix it somehow? I would do the hole upgrade process over again but the ld-elf.so.1 error keeps comming up. Any good ideas? You may have more success in getting your problems resolved by sending mail to the proper mailing list. Try [EMAIL PROTECTED] Okai ill move it to the stabe list then :) Now, what exactly did you do? I updated the system according to the howto http://www.mostgraveconcern.com/freebsd/mw.html And used the following sup file: *default host=mirror03.inet.tele.dk *default base=/usr *default prefix=/usr *default release=cvs *default tag=RELENG_4_5 *default delete use-rel-suffix src-all *default tag= .ports-all And here on i must say im lost. There is no way of going back to the stable branch (cvsup dosnt work anymore ;)) Regards, Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM: plain login not print Last login line
Andrey A. Chernov [EMAIL PROTECTED] writes: Now I mean plain /usr/bin/login, I don't see Last login from it anymore, it seems it is gone when login was PAMifized. Please restore it back (depending on quietlog as it was before). See attached patch. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] //depot/user/des/pam/usr.bin/login/login.c#7 - /usr/src/usr.bin/login/login.c --- /tmp/tmp.36820.0 Sun Apr 21 19:46:53 2002 +++ /usr/src/usr.bin/login/login.c Sun Apr 21 19:45:59 2002 @@ -353,6 +353,8 @@ lc = login_getpwclass(pwd); quietlog = login_getcapbool(lc, hushlogin, 0); + if (!quietlog) + pam_silent = 0; /* * Switching needed for NFS with root access disabled.
Re: SSH: zombie appearse probably related to PAM
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
Actually, it means *sshd* omits waiting for its own child - PAM does
not fork - and it still does not explain why I can't reproduce the
problem. In any case, please try the attached patch.
Umm, my brain was off when I wrote that. Here's a working patch (that
also fixes some warnings)
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
//depot/user/des/pam/crypto/openssh/auth2-pam.c#1 - /usr/src/crypto/openssh/auth2-pam.c
--- /tmp/tmp.36998.0 Sun Apr 21 20:00:05 2002
+++ /usr/src/crypto/openssh/auth2-pam.c Sun Apr 21 19:58:57 2002
@@ -41,6 +41,7 @@
#include security/pam_appl.h
#include auth.h
+#include log.h
#include xmalloc.h
struct pam_ctxt {
@@ -128,8 +129,6 @@
void *data)
{
struct pam_ctxt *ctxt;
- char *line;
- size_t len;
int i;
ctxt = data;
@@ -176,7 +175,6 @@
{
struct pam_conv pam_conv = { pam_child_conv, ctxt };
pam_handle_t *pamh;
- char *msg;
int pam_err;
pam_err = pam_start(sshd, ctxt-pam_user, pam_conv, pamh);
@@ -315,10 +313,11 @@
pam_free_ctx(void *ctxtp)
{
struct pam_ctxt *ctxt = ctxtp;
- int i;
+ int status;
close(ctxt-pam_sock);
kill(ctxt-pam_pid, SIGHUP);
+ waitpid(ctxt-pam_pid, status, 0);
xfree(ctxt-pam_user);
xfree(ctxt);
}
Re: new expr(1) behaviour breaks libtool
I see the new new behaviour of expr(1) requires you to add '--' if your commandline arguments might start with a '-'. This does break things a little because our old expr(1) does not understand a '--' in the beginning and the new one don't work right without it. :-((( I'm almost positive this issue was discussed before. Check the follow ups to the commit. The only one I could find was in -current, where Kris asked if w3m or expr is to blame and Garrett said w3m is to blame. The place where I noticed it was when libtool started to complain when compiling jade. Libtool does things like: expr -L/export/ports/textproc/jade/work/jade-1.2.1/lib/.libs : -l\(.*\) expr -lsp : -l\(.*\) expr -lm : -l\(.*\) expr -lgrove : -l\(.*\) On -current this now have to be: expr -- -L/export/ports/textproc/jade/work/jade-1.2.1/lib/.libs : -l\(.*\) expr -- -lsp : -l\(.*\) expr -- -lm : -l\(.*\) expr -- -lgrove : -l\(.*\) If we are going to leave this behaviour, we will have to teach libtool how to call expr(1) differently on -stable and -current and it looks like yet again different from the rest of the world. :-((( This should exactly match the behavior of any certified UNIX system. Well libtool is still broken, so maybe if systems like that do exist, they don't need libtool? :-))) Yes, I did read the commit message, but I still think the behaviour of the new expr(1) is wrong. Not according to the Standard, or the response from Garrett's request for clarification of the Standard. H. I can understand the requirement to eat '--', but to throw a tantrum just because the commandline started with a '-' is a little too much. BTW, was the response posted somewhere? I searched through -standards, -commit and -current but couldn't find it. Maybe I just didn't ask the right question to the search engine or maybe it was in another list. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
noglob in recent tcsh
Hi,
As I upgraded my current and 4-stable boxes to recent ones, I noticed
that eval `tset -s` no longer works on the stock tcsh.
It gives error message such as ``Missing ].''
I tried to figure out what is going wrong and here's my finding:
1. If an open brace is included in the string to be executed through
the command substitution mechanism (i.e. enclosed in ``'), any `{'
and `[' that appear after the first occurrence of `{' (including
this first one) is not escaped even when the shell variable noglob
is set. So, for example, the following doesn't work:
% eval `tset -s`
2. This doesn't happen if you give name of the file that contains the
same string to tcsh as the command-line argument. So, for example,
the following works:
% tset -s tset.out
% tcsh tset.out
This is all I have been able to find out, and I don't have much clue
where to look into. Or, has there been any change to tcsh which
causes this problem?
Cheers,
Max
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PAM: plain login not print Last login line
On Sun, Apr 21, 2002 at 19:49:48 +0200, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: Now I mean plain /usr/bin/login, I don't see Last login from it anymore, it seems it is gone when login was PAMifized. Please restore it back (depending on quietlog as it was before). See attached patch. It helps, thanx. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSH: zombie appearse probably related to PAM
On Sun, Apr 21, 2002 at 20:02:59 +0200, Dag-Erling Smorgrav wrote: Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Actually, it means *sshd* omits waiting for its own child - PAM does not fork - and it still does not explain why I can't reproduce the problem. In any case, please try the attached patch. Umm, my brain was off when I wrote that. Here's a working patch (that also fixes some warnings) The bug is gone after patch, thanx. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM OpenSSH: two incorrect last login
While you're in here, does it make sense to use strftime() instead of printing just a portion of what ctime returns? This would allow i18n of the time format if desired (and if the locale is set this early -- maybe this is just a can of worms =). Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
On Sun, 21 Apr 2002, Terry Lambert wrote: No, there's no stats collected on this stuff, because it's a pretty obvious and straight-forward thing: you have to have a KVA space large enough that, once you subtract out 4K for each 4M of physical memory and swap (max 4G total for both), you end up with memory left over for the kernel to use, and your limits are such that the you don't run out of PTEs before you run out of mbufs (or whatever you plan on allocating). God, I'm glad its straightforwards :) Okay, first off, you say (max 4G total for both) ... do you max *total* between the two, or phy can be 4g *plus* swap can be 4g for a total of 8g? For instance, right now, I have 3Gig of physical and ~3gig of swap allocated ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new expr(1) behaviour breaks libtool
On Sun, Apr 21, 2002 at 05:58:22PM +0200, John Hay wrote: Hi, I see the new new behaviour of expr(1) requires you to add '--' if your commandline arguments might start with a '-'. This does break things a little because our old expr(1) does not understand a '--' in the beginning and the new one don't work right without it. :-((( I have a patch for this, but unfortunately it's on a HD I can't access right now. I need to test it on the cluster soon and commit it. Kris msg37498/pgp0.pgp Description: PGP signature
Re: panic:bremfree with today's current and linux-netscape
On Sun, Apr 21, 2002 at 05:22:20PM +0300, Adrian Penisoara wrote: Panicstring: bremfree: bp 0xc77fb678 not locked This isn't the real panic, it's a second panic caused by trying to sync disks. How-to-repeat: launch linux-netscape while in X11 Are you absolutely sure all kernel modules are up to date? A sure-fire way to cause panics with linux applications is to use an out of date linux.ko. Kris msg37499/pgp0.pgp Description: PGP signature
Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
On Sun, 21 Apr 2002, Terry Lambert wrote: Marc G. Fournier wrote: You have more memory than you can allocate kernel memory to provide page table entries for. The only solution is to increase your kernel virtual address space size to accomodate the page mappings. How to do this varies widely by the version of FreeBSD you are using, and, unless you read NOTES and are running a recent -current, is not incredibly well documented, and requires an understanding of how the virtual address space is laid out and managed (which is also not well documented anywhere). Ya, this is the roadblock I'm hitting :( I'm running 4.5-STABLE here, as of this afternoon ... thoughts/suggestiosn based on that? Read the handbook as it existed for 4.5-STABLE, and read NOTES. It (sorta) tells you how to increase your KVA size. Also, is there somethign that I can run to monitor this, similar to running netstat -m to watch nmbclusters? DDB? 8-) 8-). No, there's no stats collected on this stuff, because it's a pretty obvious and straight-forward thing: you have to have a KVA space large enough that, once you subtract out 4K for each 4M of physical memory and swap (max 4G total for both), you end up with memory left over for the kernel to use, and your limits are such that the you don't run out of PTEs before you run out of mbufs (or whatever you plan on allocating). ... and translated to english, this means? :) Okay, I'm going to assume that I'm allowed 4Gig of RAM + 4Gig of Swap, for a total of 8Gig ... so, if I subtract out 4K for each 4M, that is 8M for ... what? So, I've theoretically got 8184M of VM available for the kernel to use right now? what are PTEs and how do I know how many I have right now? as for mbufs, I've currently got: jupiter netstat -m 173/1664/61440 mbufs in use (current/peak/max): 77 mbufs allocated to data 96 mbufs allocated to packet headers 71/932/15360 mbuf clusters in use (current/peak/max) 2280 Kbytes allocated to network (4% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines So how do I find out where my PTEs are sitting at? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Adding a 'bpf' group for /dev/bpf*
On Sun, 21 Apr 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Robe rt Watson writes: rc.devfs Unfortunately, this works poorly for cloned devices. At various meetings, there has been discussion of a devfsd and/or devd; that's probably the vehicle for doing that kind of administrative change. Unfortunately, it doesn't exist yet, although I think Warner had done some prototyping. Dima is actually working on this problem right now, and he has sent me a prototype which shows great promise. This is great news. I look forward to seeing some details on -arch once the prototype is ready. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lock order reversal and panic in kern_descrip.c
Today's -current kernel. This happend when I invoke linux-netscape.
lock order reversal
1st 0xe7fdf134 filedesc structure (filedesc structure) @
../../../kern/kern_descrip.c:1531
2nd 0xc0321ca0 filelist lock (filelist lock) @ ../../../kern/kern_descrip.c:1092
recursed on non-recursive lock (sleep mutex) filedesc structure @
../../../kern/kern_descrip.c:1114
first acquired @ ../../../kern/kern_descrip.c:1531
panic: recurse
cpuid = 0; lapic.id =
Debugger(panic)
Stopped at Debugger+0x41: xorl%eax,%eax
db trace
Debugger(c02d523a) at Debugger+0x41
panic(c02d8808,e7fdf134,0,c02d1af3,0) at panic+0xd8
witness_lock(e7fdf134,8,c02d1af3,45a) at witness_lock+0x198
_mtx_lock_flags(e7fdf134,0,c02d1af3,45a,e7a5be10) at _mtx_lock_flags+0x74
falloc(e7f8ed50,e805baa0,e805baa8,e7fdf134,0) at falloc+0xaf
fdcheckstd(e7f8ed50,e805bd20,e7f8ed50,bfbfc2d0,e7f8ec50) at fdcheckstd+0x1d7
execve(e7f8ed50,e805bcdc,e7f8ee2c,e7f8ec50,bfbffeb8) at execve+0x6ae
linux_execve(e7f8ed50,e805bd20,bfbfc2d0,84a9d2a,bfbfc2d0) at linux_execve+0x5b
syscall(85b002f,bfbf002f,bfbf002f,bfbfc2d0,84a9d2a) at syscall+0x223
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (11, FreeBSD ELF, nosys), eip = 0x2881990b, esp = 0xbfbfc298, ebp =
0xbfbfc2a8 ---
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc01b26b8 in boot (howto=260) at ../../../kern/kern_shutdown.c:346
#2 0xc01b28c9 in panic (fmt=0xc02be36a from debugger)
at ../../../kern/kern_shutdown.c:490
#3 0xc0131891 in db_panic (addr=-1071031351, have_addr=0, count=-1,
modif=0xe805b88c ) at ../../../ddb/db_command.c:449
#4 0xc013182f in db_command (last_cmdp=0xc03020e4, cmd_table=0xc0301f04,
aux_cmd_tablep=0xc02fc238, aux_cmd_tablep_end=0xc02fc23c)
at ../../../ddb/db_command.c:345
#5 0xc01318fb in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc0133c8f in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc029590a in kdb_trap (type=3, code=0, regs=0xe805b988)
at ../../../i386/i386/db_interface.c:161
#8 0xc02a98ec in trap (frame={tf_fs = -403177448, tf_es = 16,
tf_ds = -403177456, tf_edi = -1070024964, tf_esi = 256,
tf_ebp = -402277936, tf_isp = -402277964, tf_ebx = -1070757880,
tf_edx = 0, tf_ecx = 0, tf_eax = 18, tf_trapno = 3, tf_err = 0,
tf_eip = -1071031351, tf_cs = 8, tf_eflags = 582, tf_esp = -1070645245,
tf_ss = -1070771654}) at ../../../i386/i386/trap.c:585
#9 0xc0295bc9 in Debugger (msg=0xc02d523a panic) at machine/cpufunc.h:68
#10 0xc01b28b4 in panic (fmt=0xc02d8808 recurse)
at ../../../kern/kern_shutdown.c:477
#11 0xc01ca3d8 in witness_lock (lock=0xe7fdf134, flags=8,
file=0xc02d1af3 ../../../kern/kern_descrip.c, line=1114)
at ../../../kern/subr_witness.c:533
#12 0xc01aad4c in _mtx_lock_flags (m=0xe7fdf134, opts=0,
file=0xc02d1af3 ../../../kern/kern_descrip.c, line=1114)
at ../../../kern/kern_mutex.c:314
#13 0xc019c3df in falloc (td=0xe7f8ed50, resultfp=0xe805baa0,
resultfd=0xe805baa8) at ../../../kern/kern_descrip.c:1114
#14 0xc019d01b in fdcheckstd (td=0xe7f8ed50)
at ../../../kern/kern_descrip.c:1532
#15 0xc01a04e2 in execve (td=0xe7f8ed50, uap=0xe805bcdc)
at ../../../kern/kern_exec.c:372
#16 0xe7cc3aff in ?? ()
#17 0xc02aa08f in syscall (frame={tf_fs = 140181551, tf_es = -1078001617,
tf_ds = -1078001617, tf_edi = -1077951792, tf_esi = 139107626,
tf_ebp = -1077951832, tf_isp = -402277004, tf_ebx = -1077951792,
tf_edx = 143628032, tf_ecx = -1077951676, tf_eax = 11, tf_trapno = 12,
tf_err = 2, tf_eip = 679581963, tf_cs = 31, tf_eflags = 582,
tf_esp = -1077951848, tf_ss = 47}) at ../../../i386/i386/trap.c:1022
#18 0xc02968dd in syscall_with_err_pushed ()
Cannot access memory at address 0xbfbfc2a8.
(kgdb) up 11
#11 0xc01ca3d8 in witness_lock (lock=0xe7fdf134, flags=8,
file=0xc02d1af3 ../../../kern/kern_descrip.c, line=1114)
at ../../../kern/subr_witness.c:533
533 panic(recurse);
(kgdb) list
528 printf(
529 recursed on non-recursive lock (%s) %s @ %s:%d\n,
530 class-lc_name, lock-lo_name, file, line);
531 printf(first acquired @ %s:%d\n, lock1-li_file,
532 lock1-li_line);
533 panic(recurse);
534 }
535 CTR4(KTR_WITNESS, %s: pid %d recursed on %s r=%d, __func__,
536 td-td_proc-p_pid, lock-lo_name,
537 lock1-li_flags LI_RECURSEMASK);
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED] // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Offtopic, but hilarious
Okay, this was pointed out to me on linpeople irc network. Basically if your in the US, and you know who Jerry Fallwell is (spelling??), the story is something you would expect from him. http://members.truepath.com/objective/propaganda.html I apologise in advance if I offended anyone with this, but its too funny to pass up. Heres a sample quote from said story. quote Apparently the Darwin OS is not the original creation of Apple Computers but is instead based off of an older, obsolete OS called BSD Unix. The child-indoctrinatingly-cute cartoon mascot of this OS is a devil holding a pitchfork (pictured above). This OS -- and its Darwin offspring -- extensively use what are called daemons (which is how Pagans write demon -- they are notoriously poor spellers: magick, vampyre, etc.) which is a program that hides in the background, doing things without the user's notice. If you are using a new Macintosh running OS X then you probably have these daemons on your computer, hardly something a good Christian would want! This clearly illustrates that not only is Macintosh based on Darwinism, but Darwinism is based on Satanism. /quote To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM OpenSSH: two incorrect last login
Bill Fenner [EMAIL PROTECTED] writes: While you're in here, does it make sense to use strftime() instead of printing just a portion of what ctime returns? Might, might not. ISTR strftime() can't correctly emulate ctime(), but some other format might be preferrable. Do you have a format string handy? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Offtopic, but hilarious
I posted it for its amusement value, nothing else :) -Original Message- From: Igor Roboul [mailto:[EMAIL PROTECTED]] Sent: Monday, April 22, 2002 1:50 AM To: [EMAIL PROTECTED] Subject: Re: Offtopic, but hilarious On Mon, Apr 22, 2002 at 12:55:36AM -0400, [EMAIL PROTECTED] wrote: Okay, this was pointed out to me on linpeople irc network. Basically if your in the US, and you know who Jerry Fallwell is (spelling??), the story is something you would expect from him. http://members.truepath.com/objective/propaganda.html I apologise in advance if I offended anyone with this, but its too funny to pass up. There are so many crazy people, so if we'll worry about every of them, then we'll be so crazy as they are. -- Igor Roboul, System administrator at Speech Technology Center http://www.speechpro.com http://www.speechpro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
