Re: xscreensaver bug?
Terry Lambert wrote: Eugene M. Kim wrote: Terry Lambert wrote: I'm new in FreeBSD. I found that after I lock screen with xscreensaver, I can unlock it with the root's password as well as my normal user's password. I don't think it is a good thing. Is it a bug? It is intentional, although you can eliminate it with a recompile of the xscreensaver code, with the right options set. Wouldn't this lead to another security hazard, if a user compile his own hacked xscreensaver which captures and stashes the password into a file then runs it and leaves the terminal intentionally, `baiting' root? :o Not really. This type of thing would need to accept pretty much everything as a termination password, since there no password it can legitimately validate, since a user compiled trojan like this would not have access to the password database contents in order to perform validation. If the trojan is SUID, then they already have root, and don't need the trojan. Either way, there's no risk to just typing whatever crap you want to at it, including a message calling the user an idiot, the first time, to see if it's going to let you in without you giving it the real root password. Validating a root password is possible with other means in many cases, if not always. OpenSSH sshd is a good example. Even with PermitRootLogin set to no, the attacker can differentiate whether the password has been accepted or not. If attacker is able enough, he could also run a hacked version of Xnest on port 6000+N and the real xscreensaver on :N.0 for a suitable N. Attacker would feed the real xscreensaver with the captured password and see if the real xscreensaver releases the server grab. Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xscreensaver bug?
Terry Lambert wrote: [EMAIL PROTECTED] wrote: I'm new in FreeBSD. I found that after I lock screen with xscreensaver, I can unlock it with the root's password as well as my normal user's password. I don't think it is a good thing. Is it a bug? It is intentional, although you can eliminate it with a recompile of the xscreensaver code, with the right options set. Wouldn't this lead to another security hazard, if a user compile his own hacked xscreensaver which captures and stashes the password into a file then runs it and leaves the terminal intentionally, `baiting' root? :o Although I can see the merit of this `feature', I think sysadmins should stay away from using it in general. `su -m thatuser -c killall xscreensaver' seems to be far safer. Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forward: HEADS UP! Default value of ip6_v6only changed
Michael Nottebrock wrote: Christian Weisgerber wrote: If we ship with a default of v6only off, then people will not fix software to open two sockets. This in turn means that turning v6only on will break this software. I find the notion of making people fix their software to not rely on RFC-defined behaviour problematic. I'm actually glad to see NetBSD reversed their unfortunate decision regarding the default (and OpenBSD's stunt of not even providing a knob is very evil indeed). 100% agreed here. The standard exists for a reason. If people find the standard problematic (in fact I concur with Itojun's analysis about IPv4-mapped addresses), they should voice in the appropriate forum to fix the standard rather than just ignore the standard and implement things in their own way, which only creates and/or worsens the compatibility nightmare. (Another test knob into GNU autoconf. Sad.) It's not like IETF RFC's are particularly hard to amend, either, at least compared to other standarization bodies. IETF and its folks are *very* open and flexible IMHO. Eugene ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump -L and privilege
Moreover, the fact that the number of snapshots allowed on a filesystem is limited to a handful (src/sys/ufs/ffs/README.snapshot says 20) makes it possible for normal users to disrupt dump -L and other important operations that require snapshots. Alternative 2 seems a lot more sensible. Just my 2 KRW (1 USD ~= 1250 KRW) :D, Eugene On Thu, Jan 30, 2003 at 05:15:01PM -0600, Jacques A. Vidrine wrote: On Wed, Jan 29, 2003 at 06:17:31PM -0800, Kirk McKusick wrote: Alternative 1 `usermount' The first would be to change the default for vfs.usermount == 1 and then have dump -L create the snapshot in a directory owned by operator (or by whatever user runs the dumps). Then the snapshot could be created, used, and deleted by that user. Alternative 2 `/sbin/snapshot' The other alternative would be to create a setuid-to-root program that would take a snapshot and chown it to the user that does dumps. This setuid program could then be invoked by dump -L to create a snapshot for it. Despite a distaste for setuid executables, I think I'd prefer a simple /sbin/snapshot setuid program. Primarily, enabling `vfs.usermount' gives more privileges to more users than I'm comfortable with. Secondarily, /sbin/snapshot may be useful on its own. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I've just had a massive file system crash
On Sun, Jan 26, 2003 at 04:08:31PM +0800, Greg Lehey wrote:
On Sunday, 26 January 2003 at 14:24:02 +1030, Daniel O'Connor wrote:
On Sun, 2003-01-26 at 08:08, David Schultz wrote:
Good. I was referring to IDE in this case, because I assume
that's what Greg's laptop uses. The ATA driver flushes the cache
when the device is closed, but I don't think that happens during
shutdown. It probably needs to register a shutdown hook like the
SCSI driver. Also, the driver is a bit optimistic about how long
the flush will take; it times out after 5 seconds, whereas the ATA
spec says a flush can take up to 30 seconds.
I am wondering if I experienced this problem with my -stable laptop..
I shut it down and then booted it up later to find fsck having a nice
good chew on the drive (deleting REAMS of files).
Did you use shutdown -p? If my hypothesis is correct, it's possible
to get this result with shutdown -h if you press the power switch as
soon as the System halted message appears, but normally you'd give
it a few seconds longer. With shutdown -p, it's immediate, modulo
delay.
Just a random idea: If that poses an issue, how about this patch?
Eugene
--- src/sys/kern_shutdown.c Sun Jan 26 14:24:56 2003
+++ src/sys/kern_shutdown.c.new Sun Jan 26 14:25:42 2003
@@ -545,7 +545,7 @@
static void
poweroff_wait(void *junk, int howto)
{
- if(!(howto RB_POWEROFF) || poweroff_delay = 0)
+ if(!(howto (RB_POWEROFF | RB_HALT)) || poweroff_delay = 0)
return;
DELAY(poweroff_delay * 1000);
}
Re: LIBCOMPATDIR semantics mismatch
Coolio, thanks for letting me in the know. Cheers, Eugene On Thu, Apr 18, 2002 at 04:26:20PM +0300, Ruslan Ermilov wrote: Already fixed this earlier this morning (local time). And just removed the gratuitous LIBCOMPATDIR assignments. Cheers, -- Ruslan ErmilovSysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
LIBCOMPATDIR semantics mismatch
Don't know what prevented this from being caught, but:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/compat/Makefile.inc?only_with_tag=MAIN#rev1.5
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/compat/compat1x/Makefile?only_with_tag=MAIN#rev1.8
These two doesn't seem to mix together (note the last argument):
- snip - snip - snip -
sh /usr/src/tools/install.sh -c -o root -g wheel -m 444 libc.so.1.1 libcurses.so.1.1
libf2c.so.1.1 libg++.so.1.1 libgcc.so.1.1 libgnumalloc.so.1.1 libgnuregex.so.1.1
libln.so.1.1 libm.so.1.1 libmalloc.so.1.1 libreadline.so.1.1 libresolv.so.1.1
librpcsvc.so.1.1 libskey.so.1.1 libtelnet.so.1.1 libtermcap.so.1.1 libutil.so.1.1
liby.so.1.1 /usr/obj/usr/src/i386/usr/lib/compat/aout/aout
usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 file2
install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 ... fileN directory
install -d [-v] [-g group] [-m mode] [-o owner] directory ...
*** Error code 64
- snip - snip - snip -
Attached is a patch that fixes this by unifying the semantics of
LIBCOMPATDIR.
Thanks,
Eugene
--- src/lib/compat/Makefile.inc Sat Nov 10 02:08:09 2001
+++ src/lib/compat/Makefile.inc.new Wed Apr 17 14:27:40 2002
-1,6 +1,6
# $FreeBSD: src/lib/compat/Makefile.inc,v 1.8 2001/09/22 08:11:24 ru Exp $
-LIBCOMPATDIR?= ${LIBDIR}/compat/aout
+LIBCOMPATDIR?= ${LIBDIR}/compat
.if defined(LIBS) !empty(LIBS)
beforeinstall: __remove-stale-libs
--- src/lib/compat/compat3x.i386/Makefile Sat Nov 10 02:08:09 2001
+++ src/lib/compat/compat3x.i386/Makefile.new Wed Apr 17 14:28:05 2002
-2,8 +2,6
DISTRIBUTION= compat3x
-LIBCOMPATDIR= ${LIBDIR}/compat
-
LIBS= libalias.so.3 libc.so.3 libc_r.so.3 libc_r.so.4 libcurses.so.2 \
libdialog.so.3 libedit.so.2 libf2c.so.2 libfetch.so.1 libftpio.so.4 \
libg++.so.4 libhistory.so.3 libmytinfo.so.2 libncurses.so.3 \
--- src/lib/compat/compat4x.alpha/Makefile Wed Apr 17 01:16:56 2002
+++ src/lib/compat/compat4x.alpha/Makefile.new Wed Apr 17 14:28:12 2002
-2,8 +2,6
DISTRIBUTION= compat4x
-LIBCOMPATDIR= ${LIBDIR}/compat
-
LIBS= \
libc.so.4 \
libc_r.so.4 \
--- src/lib/compat/compat4x.i386/Makefile Wed Apr 17 01:16:57 2002
+++ src/lib/compat/compat4x.i386/Makefile.new Wed Apr 17 14:28:21 2002
-2,8 +2,6
DISTRIBUTION= compat4x
-LIBCOMPATDIR= ${LIBDIR}/compat
-
LIBS= \
libc.so.4 \
libc_r.so.4 \
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
--2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Attached is the requested DDB log (I guessed pid 7 `syncer' is the process doing the sync; if this is wrong let me know). Eugene PS. I used the serial console, so don't feel sorry to ask. =) On Fri, Feb 08, 2002 at 02:41:30PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, David Wolfskill wrote: Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 can you hit CTLALTESC and get into the debugger? My box shows the same symptom, and yes I can enter DDB. How may I help? Eugene show locks whould be good. also 'ps' and the stack trace of the process doing the sync... tr PID if you can get a serial console that would be best of course. you may wait a while to see if dave can get into ddb on his serial console. that may save you a lot of writing :-) --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=screenlog.0 syncing disks... 4 4 Debugger(manual escape to debugger) Stopped at Debugger+0x41: xorl%eax,%eax db show locks exclusive (sleep mutex) Giant (0xc02e6100) locked @ /usr/src/sys/kern/kern_intr.c:532 db ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 192 cc989300 cdbc50000 0 0 204 3 nfsidl c1d0538c nfsiod 3 191 cc989600 cdbc10000 0 0 204 3 nfsidl c1d05388 nfsiod 2 190 cc989900 cdbbd0000 0 0 204 3 nfsidl c1d05384 nfsiod 1 189 cc989c00 cdbb90000 0 0 204 3 nfsidl c1d05380 nfsiod 0 9 cc98c000 cd1af0000 0 0 204 3 pccbbev c1b39400 pccbb1 8 cc98c300 cd1ab0000 0 0 204 3 pccbbev c1b39800 pccbb0 7 cc98c600 cd1a70000 0 0 204 3 ktsusp cc98c800 syncer 6 cc98c900 cd1a30000 0 0 204 3 ktsusp cc98cb00 vnlru 5 cc98cc00 cd19f0000 0 0 204 3 ktsusp cc98ce00 bufdaemon 4 cc98cf00 cd19b0000 0 0 204 3 pgzero c0327fc8 pagezero 3 cc98d200 cd1970000 0 0 204 3 psleep c0327fdc vmdaemon 2 cc98d500 cd1930000 0 0 204 3 psleep c02e06d8 pagedaemon 31 cc98d800 cc9920000 0 0 204 6 irq8: rtc 30 cc98db00 cc98e0000 0 0 204 6 irq0: clk 29 cc320f00 cc9850000 0 0 204 6 irq4: sio0 28 cc321200 cc9810000 0 0 204 6 swi0: tty:sio 27 cc321500 cc97d0000 0 0 204 6 irq7: ppc0 26 cc321800 cc9790000 0 0 204 6 irq12: psm0 25 cc321b00 cc9750000 0 0 204 2 irq1: atkbd0 24 cc321e00 cc9710000 0 0 204 3 usbevt c1b60210 usb0 --More-- 23 cc322100 cc96d0000 0 0 204 6 irq15: ata1 22 cc322400 cc9690000 0 0 204 6 irq14: ata0 21 cc322700 cc9640000 0 0 204 6 irq11: pccbb0++ 20 cc322a00 cc95a0000 0 0 204 6 irq5: pcm0 19 cc322d00 cc9520000 0 0 204 6 irq13: 18 cc323000 cc94e0000 0 0 204 6 swi5: acpitaskq 17 cc323300 cc94a0000 0 0 204 6 swi5: task queue 16 cc323600 cc9460000 0 0 204 6 swi3: cambio 15 cc323900 cc9420000 0 0 204 6 swi2: camnet 14 cc323c00 cc93e0000 0 0 204 3 sleep c0417120 random 13 cc323f00 cc93a0000 0 0 204 6 swi4: vm 12 cc324200 cc9360000 0 0 20c 2 swi6: tty:sio clock 11 cc324500 cc9320000 0 0 204 6 swi1: net 10 cc324800 cc32d0000 0 0 20c 2 idle 1 cc324b00 cc3290000 0 1 0004200 2 init 0 c02c4200 c0480 0 0 200 3 sched c02c4200 swapper db tr 7 mi_switch(cc98c800,cc98c600,c1b688dc,1,0) at mi_switch+0x153 msleep(cc98c800,cc98c814,68,c0288668,0,cc98c800) at msleep+0x322 kthread_suspend_check(cc98c600,cc98c704,c01b5cf4,cc98c600,cd1aacf8) at kthread_suspend_check+0x50 sched_sync(0,cd1aad48,0,c01b5cf4,0) at sched_sync+0x4c fork_exit(c01b5cf4,0,cd1aad48) at fork_exit+0x9e fork_trampoline() at fork_trampoline+0x8 db --2oS5YaxWCcQjTEyO-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
It's an UP kernel running on an UP box. Eugene On Fri, Feb 08, 2002 at 04:53:28PM -0800, Julian Elischer wrote: yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w) thanks! On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
I'm not particularly good at reading the lock-related output, but it doesn't have other lines than the one that says about the Giant lock, so it seems there isn't any other locks being held by anyone. Eugene On Fri, Feb 08, 2002 at 04:55:42PM -0800, Julian Elischer wrote: I tlooks as if show locks would not show any locks held by anyone.. is this true? On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
--BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=screenlog.0 Content-Transfer-Encoding: quoted-printable show locks=0D exclusive (sleep mutex) Giant (0xc02e60c0) locked @ /usr/src/sys/kern/kern_= intr.c:532=0D db ps=0D pid proc addruid ppid pgrp flag stat wmesg wchan cmd=0D 279 cdbdc500 cdc6e0000 1 279 0004002 2 reboot= =0D 185 cc988900 cdbbc0000 0 0 204 3 nfsidl c1d053ac nfsiod= 3=0D 184 cc988c00 cdbb80000 0 0 204 3 nfsidl c1d053a8 nfsiod= 2=0D 183 cc988f00 cdbb40000 0 0 204 3 nfsidl c1d053a4 nfsiod= 1=0D 182 cc989200 cdbb0 0 0 204 3 nfsidl c1d053a0 nfsiod= 0=0D 7 cc98b600 cd1a60000 0 0 204 3 ktsusp cc98b800 syncer= =0D 6 cc98b900 cd1a20000 0 0 204 3 ktsusp cc98bb00 vnlru= =0D 5 cc98bc00 cd19e0000 0 0 204 3 ktsusp cc98be00 bufdae= mon=0D 4 cc98bf00 cd19a0000 0 0 204 3 pgzero c0327f88 pageze= ro=0D 3 cc98c200 cd1960000 0 0 204 3 psleep c0327f9c vmdaem= on=0D 2 cc98c500 cd1920000 0 0 204 3 psleep c02e0698 pageda= emon=0D 31 cc98c800 cc9910000 0 0 204 6 irq8: = rtc=0D 30 cc98cb00 cc98d0000 0 0 204 6 irq0: = clk=0D 29 cc321f00 cc9840000 0 0 204 6 irq4: = sio0=0D 28 cc322200 cc980 0 0 204 6 swi0: = tty:sio=0D 27 cc322500 cc97c0000 0 0 204 6 irq7: = ppc0=0D 26 cc322800 cc9780000 0 0 204 6 irq12:= psm0=0D 25 cc322b00 cc9740000 0 0 204 2 irq1: = atkbd0=0D 24 cc322e00 cc970 0 0 204 3 usbevt c1b60210 usb0=0D 23 cc323100 cc96c0000 0 0 204 6 irq11:= uhci0=0D --More--=0D 22 cc323400 cc9680000 0 0 204 6 = irq15: ata1=0D 21 cc323700 cc9640000 0 0 204 6 irq14:= ata0=0D 20 cc323a00 cc95b0000 0 0 204 6 irq5: = pcm0=0D 19 cc323d00 cc9530000 0 0 204 6 irq13:= =0D 18 cc324000 cc94f0000 0 0 204 6 swi5: = acpitaskq=0D 17 cc324300 cc94b0000 0 0 204 6 swi5: = task queue=0D 16 cc324600 cc9470000 0 0 204 6 swi3: = cambio=0D 15 cc324900 cc9430000 0 0 204 6 swi2: = camnet=0D 14 cc324c00 cc93f0000 0 0 204 3 sleep c04141c0 random= =0D 13 cc324f00 cc93b0000 0 0 204 6 swi4: = vm=0D 12 cc325200 cc9370000 0 0 20c 2 swi6: = tty:sio clock=0D 11 cc325500 cc9330000 0 0 204 6 swi1: = net=0D 10 cc325800 cc32e0000 0 0 20c 2 idle=0D 1 cc325b00 cc32a0000 0 1 0004200 3wait cc325b00 init=0D 0 c02c41c0 c047c0000 0 0 200 3 sched c02c41c0 swappe= r=0D db tr 279=0D mi_switch(0,cdbdc500,cdbdc604,10,0) at mi_switch+0x153=0D boot(0,cdbdc714,cdc71d40,c0262b80,cdbdc604) at boot+0x200=0D reboot(cdbdc604,cdc71d20,2,0,0) at reboot+0x37=0D syscall(2f,2f,2f,0,0) at syscall+0x254=0D syscall_with_err_pushed() at syscall_with_err_pushed+0x1b=0D --- syscall (55, FreeBSD ELF, reboot), eip =3D 0x8048b8b, esp =3D 0xbfbffb1= c, ebp =3D 0xbfbffb48 ---=0D db tr 1=0D mi_switch(1,0,cc32dd20,1,0) at mi_switch+0x153=0D msleep(cc325b00,0,15c,c0287e85,0) at msleep+0x322=0D wait1(cc325c04,cc32dd20,0,cc32dd40,c0262b80) at wait1+0x617=0D wait4(cc325c04,cc32dd20,0,bfbffe18,bfbffe24) at wait4+0x12=0D syscall(2f,2f,2f,bfbffe24,bfbffe18) at syscall+0x254=0D syscall_with_err_pushed() at syscall_with_err_pushed+0x1b=0D --- syscall (7, FreeBSD ELF, wait4), eip =3D 0x8050c37, esp =3D 0xbfbffcf8,= ebp =3D 0xbfbffd14 ---=0D db tr 0=0D mi_switch(c02def10,0,483000,1,0) at mi_switch+0x153=0D msleep(c02c41c0,0,44,c02a7570,3e8) at msleep+0x322=0D scheduler(0,47bc00,47b000,0,c0121d1c) at scheduler+0x146=0D mi_startup() at mi_startup+0x95=0D begin() at begin+0x43=0D db ~~=08 =08=08 =08show witness=0D Sleep locks:=0D 0
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, David Wolfskill wrote: Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 can you hit CTLALTESC and get into the debugger? My box shows the same symptom, and yes I can enter DDB. How may I help? Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
Attached is the requested DDB log (I guessed pid 7 `syncer' is the process doing the sync; if this is wrong let me know). Eugene PS. I used the serial console, so don't feel sorry to ask. =) On Fri, Feb 08, 2002 at 02:41:30PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 01:43:54PM -0800, Julian Elischer wrote: On Fri, 8 Feb 2002, David Wolfskill wrote: Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 7 7 can you hit CTLALTESC and get into the debugger? My box shows the same symptom, and yes I can enter DDB. How may I help? Eugene show locks whould be good. also 'ps' and the stack trace of the process doing the sync... tr PID if you can get a serial console that would be best of course. you may wait a while to see if dave can get into ddb on his serial console. that may save you a lot of writing :-) syncing disks... 4 4 Debugger(manual escape to debugger) Stopped at Debugger+0x41: xorl%eax,%eax db show locks exclusive (sleep mutex) Giant (0xc02e6100) locked @ /usr/src/sys/kern/kern_intr.c:532 db ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 192 cc989300 cdbc50000 0 0 204 3 nfsidl c1d0538c nfsiod 3 191 cc989600 cdbc10000 0 0 204 3 nfsidl c1d05388 nfsiod 2 190 cc989900 cdbbd0000 0 0 204 3 nfsidl c1d05384 nfsiod 1 189 cc989c00 cdbb90000 0 0 204 3 nfsidl c1d05380 nfsiod 0 9 cc98c000 cd1af0000 0 0 204 3 pccbbev c1b39400 pccbb1 8 cc98c300 cd1ab0000 0 0 204 3 pccbbev c1b39800 pccbb0 7 cc98c600 cd1a70000 0 0 204 3 ktsusp cc98c800 syncer 6 cc98c900 cd1a30000 0 0 204 3 ktsusp cc98cb00 vnlru 5 cc98cc00 cd19f0000 0 0 204 3 ktsusp cc98ce00 bufdaemon 4 cc98cf00 cd19b0000 0 0 204 3 pgzero c0327fc8 pagezero 3 cc98d200 cd1970000 0 0 204 3 psleep c0327fdc vmdaemon 2 cc98d500 cd1930000 0 0 204 3 psleep c02e06d8 pagedaemon 31 cc98d800 cc9920000 0 0 204 6 irq8: rtc 30 cc98db00 cc98e0000 0 0 204 6 irq0: clk 29 cc320f00 cc9850000 0 0 204 6 irq4: sio0 28 cc321200 cc9810000 0 0 204 6 swi0: tty:sio 27 cc321500 cc97d0000 0 0 204 6 irq7: ppc0 26 cc321800 cc9790000 0 0 204 6 irq12: psm0 25 cc321b00 cc9750000 0 0 204 2 irq1: atkbd0 24 cc321e00 cc9710000 0 0 204 3 usbevt c1b60210 usb0 --More-- 23 cc322100 cc96d0000 0 0 204 6 irq15: ata1 22 cc322400 cc9690000 0 0 204 6 irq14: ata0 21 cc322700 cc9640000 0 0 204 6 irq11: pccbb0++ 20 cc322a00 cc95a0000 0 0 204 6 irq5: pcm0 19 cc322d00 cc9520000 0 0 204 6 irq13: 18 cc323000 cc94e0000 0 0 204 6 swi5: acpitaskq 17 cc323300 cc94a0000 0 0 204 6 swi5: task queue 16 cc323600 cc9460000 0 0 204 6 swi3: cambio 15 cc323900 cc9420000 0 0 204 6 swi2: camnet 14 cc323c00 cc93e0000 0 0 204 3 sleep c0417120 random 13 cc323f00 cc93a0000 0 0 204 6 swi4: vm 12 cc324200 cc9360000 0 0 20c 2 swi6: tty:sio clock 11 cc324500 cc9320000 0 0 204 6 swi1: net 10 cc324800 cc32d0000 0 0 20c 2 idle 1 cc324b00 cc3290000 0 1 0004200 2 init 0 c02c4200 c0480 0 0 200 3 sched c02c4200 swapper db tr 7 mi_switch(cc98c800,cc98c600,c1b688dc,1,0) at mi_switch+0x153 msleep(cc98c800,cc98c814,68,c0288668,0,cc98c800) at msleep+0x322 kthread_suspend_check(cc98c600,cc98c704,c01b5cf4,cc98c600,cd1aacf8) at kthread_suspend_check+0x50 sched_sync(0,cd1aad48,0,c01b5cf4,0) at sched_sync+0x4c fork_exit(c01b5cf4,0,cd1aad48) at fork_exit+0x9e fork_trampoline() at fork_trampoline+0x8 db
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene show locks exclusive (sleep mutex) Giant (0xc02e60c0) locked @ /usr/src/sys/kern/kern_intr.c:532 db ps pid proc addruid ppid pgrp flag stat wmesg wchan cmd 279 cdbdc500 cdc6e0000 1 279 0004002 2 reboot 185 cc988900 cdbbc0000 0 0 204 3 nfsidl c1d053ac nfsiod 3 184 cc988c00 cdbb80000 0 0 204 3 nfsidl c1d053a8 nfsiod 2 183 cc988f00 cdbb40000 0 0 204 3 nfsidl c1d053a4 nfsiod 1 182 cc989200 cdbb0 0 0 204 3 nfsidl c1d053a0 nfsiod 0 7 cc98b600 cd1a60000 0 0 204 3 ktsusp cc98b800 syncer 6 cc98b900 cd1a20000 0 0 204 3 ktsusp cc98bb00 vnlru 5 cc98bc00 cd19e0000 0 0 204 3 ktsusp cc98be00 bufdaemon 4 cc98bf00 cd19a0000 0 0 204 3 pgzero c0327f88 pagezero 3 cc98c200 cd1960000 0 0 204 3 psleep c0327f9c vmdaemon 2 cc98c500 cd1920000 0 0 204 3 psleep c02e0698 pagedaemon 31 cc98c800 cc9910000 0 0 204 6 irq8: rtc 30 cc98cb00 cc98d0000 0 0 204 6 irq0: clk 29 cc321f00 cc9840000 0 0 204 6 irq4: sio0 28 cc322200 cc980 0 0 204 6 swi0: tty:sio 27 cc322500 cc97c0000 0 0 204 6 irq7: ppc0 26 cc322800 cc9780000 0 0 204 6 irq12: psm0 25 cc322b00 cc9740000 0 0 204 2 irq1: atkbd0 24 cc322e00 cc970 0 0 204 3 usbevt c1b60210 usb0 23 cc323100 cc96c0000 0 0 204 6 irq11: uhci0 --More-- 22 cc323400 cc9680000 0 0 204 6 irq15: ata1 21 cc323700 cc9640000 0 0 204 6 irq14: ata0 20 cc323a00 cc95b0000 0 0 204 6 irq5: pcm0 19 cc323d00 cc9530000 0 0 204 6 irq13: 18 cc324000 cc94f0000 0 0 204 6 swi5: acpitaskq 17 cc324300 cc94b0000 0 0 204 6 swi5: task queue 16 cc324600 cc9470000 0 0 204 6 swi3: cambio 15 cc324900 cc9430000 0 0 204 6 swi2: camnet 14 cc324c00 cc93f0000 0 0 204 3 sleep c04141c0 random 13 cc324f00 cc93b0000 0 0 204 6 swi4: vm 12 cc325200 cc9370000 0 0 20c 2 swi6: tty:sio clock 11 cc325500 cc9330000 0 0 204 6 swi1: net 10 cc325800 cc32e0000 0 0 20c 2 idle 1 cc325b00 cc32a0000 0 1 0004200 3wait cc325b00 init 0 c02c41c0 c047c0000 0 0 200 3 sched c02c41c0 swapper db tr 279 mi_switch(0,cdbdc500,cdbdc604,10,0) at mi_switch+0x153 boot(0,cdbdc714,cdc71d40,c0262b80,cdbdc604) at boot+0x200 reboot(cdbdc604,cdc71d20,2,0,0) at reboot+0x37 syscall(2f,2f,2f,0,0) at syscall+0x254 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (55, FreeBSD ELF, reboot), eip = 0x8048b8b, esp = 0xbfbffb1c, ebp = 0xbfbffb48 --- db tr 1 mi_switch(1,0,cc32dd20,1,0) at mi_switch+0x153 msleep(cc325b00,0,15c,c0287e85,0) at msleep+0x322 wait1(cc325c04,cc32dd20,0,cc32dd40,c0262b80) at wait1+0x617 wait4(cc325c04,cc32dd20,0,bfbffe18,bfbffe24) at wait4+0x12 syscall(2f,2f,2f,bfbffe24,bfbffe18) at syscall+0x254 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (7, FreeBSD ELF, wait4), eip = 0x8050c37, esp = 0xbfbffcf8, ebp = 0xbfbffd14 --- db tr 0 mi_switch(c02def10,0,483000,1,0) at mi_switch+0x153 msleep(c02c41c0,0,44,c02a7570,3e8) at msleep+0x322 scheduler(0,47bc00,47b000,0,c0121d1c) at scheduler+0x146 mi_startup() at mi_startup+0x95 begin() at begin+0x43 db ~~ show witness Sleep locks: 0 (dead) -- last acquired @ (dead):0 0 (dead) -- last acquired @ (dead):0 0 Giant -- last acquired @ /usr/src/sys/kern/kern_intr.c:532 1 ithread -- last acquired @ /usr/src/sys/kern/kern_intr.c:269 2 struct filedesc -- last acquired @ /usr/src/sys/kern/kern_descrip.c:1170 2 fork list -- last acquired @ /usr/src/sys/kern/kern_fork.c:649 3lockmgr -- last acquired @ /usr/src/sys/kern/kern_lock.c:227 2 proctree -- last acquired @
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
It's an UP kernel running on an UP box. Eugene On Fri, Feb 08, 2002 at 04:53:28PM -0800, Julian Elischer wrote: yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w) thanks! On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
I'm not particularly good at reading the lock-related output, but it doesn't have other lines than the one that says about the Giant lock, so it seems there isn't any other locks being held by anyone. Eugene On Fri, Feb 08, 2002 at 04:55:42PM -0800, Julian Elischer wrote: I tlooks as if show locks would not show any locks held by anyone.. is this true? On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Hang on flushing buffers w/today's -CURRENT, SMP system
On Fri, Feb 08, 2002 at 05:09:31PM -0800, Julian Elischer wrote: h so what is the difference between your kernel and mine that works? /me scratches his head just out of curiosity, have you tried a very latest -current? Not the very latest; this source is about a day old. do you have your own config? how does GENERIC behave? I do have my own config; you can get it at: http://home.the-7.net/~ab/PL-DAAL (config file itself) http://home.the-7.net/~ab/PL-DAAL.hints (... and device hints) I haven't tried GENERIC yet. Eugene (what kind of disks do you have?) Julian On Fri, 8 Feb 2002, Eugene M. Kim wrote: It's an UP kernel running on an UP box. Eugene On Fri, Feb 08, 2002 at 04:53:28PM -0800, Julian Elischer wrote: yes but is it a SMP or UP kernel? (SMP kernel can run on some UP h/w) thanks! On Fri, 8 Feb 2002, Eugene M. Kim wrote: On Fri, Feb 08, 2002 at 03:56:21PM -0800, Julian Elischer wrote: In your case we need totrace proc 1 I think.. I got the `reboot' process at this session, so I traced that process. Before I had used `shutdown -r', which probably SIGINT'ed the init process so it's init (pid 1) calling reboot()... The attached log also has its trace JFYI. One more bit of info: as you see from the pcpu output, mine is not an SMP but an UP box. Thanks, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl build breakage
I think it is necessary to add the notice to UPDATING because it's been half an year since the incident day. If it were like within last few days, I definitely would've gotten some hints about the fix by scanning -current (which I did). But I had to scratch my heads helplessly until I asked the list, and you know that the typical response of the list to this type of inquiry has been `Welcome to Yesterday.' If UPDATING does not properly save people like me, what will? So, Warner, could you update the relevant entry in UPDATING? Thanks, Eugene On Sat, Dec 01, 2001 at 10:43:39PM +0100, Anton Berezin wrote: On Sat, Dec 01, 2001 at 01:26:11PM -0800, Eugene M. Kim wrote: Oh, never mind. I just re-read the thread you pointed (thanks) and saw it affects the systems *installed around the breakage date*. UPDATING does not mention about this fact (it simply says `Building perl was broken'); perhaps it should be updated to mention the misfortune of the installed system and the link to the fix; Warner?). Well, that would definitely be a good idea half a year ago. Nowadays, I doubt there will be any significant number of unlucky souls having operating -current systems built between May 1st and May 2nd. You might be unique at that. ;-) Cheers, %Anton. -- | Anton Berezin| FreeBSD: The power to serve | | catpipe Systems ApS _ _ |_ | http://www.FreeBSD.org | | [EMAIL PROTECTED](_(_|| |[EMAIL PROTECTED] | | +45 7021 0050| Private: [EMAIL PROTECTED] | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl build breakage
Well, I *did* read UPDATING, and I saw the perl breakage notice. But it seems not to be relevant to me, as my source code is current (I mean, up to date); I cvsupped it just before starting make world. Only my host system is built around May 1. Thanks, Eugene On Sat, Dec 01, 2001 at 05:18:45PM +0100, Anton Berezin wrote: On Thu, Nov 29, 2001 at 10:42:45AM -0800, Eugene M. Kim wrote: Hello, I am getting the following error in the make depend stage; could anyone shed a light? (The host system is 5-current as of around May 1.) From UPDATING (you do read UPDATING, don't you?): 20010502: Perl breakage in 20010501 was corrected at 14:18:33 PDT. 20010501: Building perl was broken at 02:25:25 PDT. Please see the old HEADS UP message, which describes the fix: http://www.freebsd.org/cgi/getmsg.cgi?fetch=192223+0+/usr/local/www/db/text/2001/freebsd-current/20010506.freebsd-current Thanks, Eugene snip snip === libperl === miniperl === perl Extracting config.h (with variable substitutions) Extracting cflags (with variable substitutions) Extracting writemain (with variable substitutions) Extracting myconfig (with variable substitutions) Missing right curly or square bracket at lib/SelfLoader.pm line 69, at end of line syntax error at lib/SelfLoader.pm line 69, at EOF Compilation failed in require at /usr/libdata/perl/BSDPAN/BSDPAN/Override.pm line 17. Compilation failed in require at /usr/libdata/perl/BSDPAN/Config.pm line 37. BEGIN failed--compilation aborted at /usr/libdata/perl/BSDPAN/Config.pm line 37. Compilation failed in require at /usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5/configpm line 430. *** Error code 255 Stop in /usr/src/gnu/usr.bin/perl/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. *** Error code 255 Stop in /usr/src/gnu/usr.bin/perl/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. snip snip Cheers, *Anton. -- | Anton Berezin| FreeBSD: The power to serve | | catpipe Systems ApS _ _ |_ | http://www.FreeBSD.org | | [EMAIL PROTECTED](_(_|| |[EMAIL PROTECTED] | | +45 7021 0050| Private: [EMAIL PROTECTED] | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl build breakage
Oh, never mind. I just re-read the thread you pointed (thanks) and saw
it affects the systems *installed around the breakage date*.
UPDATING does not mention about this fact (it simply says `Building perl
was broken'); perhaps it should be updated to mention the misfortune of
the installed system and the link to the fix; Warner?).
Thanks,
Eugene
On Sat, Dec 01, 2001 at 01:14:44PM -0800, Eugene M. Kim wrote:
Well, I *did* read UPDATING, and I saw the perl breakage notice. But it
seems not to be relevant to me, as my source code is current (I mean, up
to date); I cvsupped it just before starting make world. Only my host
system is built around May 1.
Thanks,
Eugene
On Sat, Dec 01, 2001 at 05:18:45PM +0100, Anton Berezin wrote:
On Thu, Nov 29, 2001 at 10:42:45AM -0800, Eugene M. Kim wrote:
Hello,
I am getting the following error in the make depend stage; could anyone
shed a light?
(The host system is 5-current as of around May 1.)
From UPDATING (you do read UPDATING, don't you?):
20010502:
Perl breakage in 20010501 was corrected at 14:18:33 PDT.
20010501:
Building perl was broken at 02:25:25 PDT.
Please see the old HEADS UP message, which describes the fix:
http://www.freebsd.org/cgi/getmsg.cgi?fetch=192223+0+/usr/local/www/db/text/2001/freebsd-current/20010506.freebsd-current
Thanks,
Eugene
snip snip
=== libperl
=== miniperl
=== perl
Extracting config.h (with variable substitutions)
Extracting cflags (with variable substitutions)
Extracting writemain (with variable substitutions)
Extracting myconfig (with variable substitutions)
Missing right curly or square bracket at lib/SelfLoader.pm line 69, at end of
line
syntax error at lib/SelfLoader.pm line 69, at EOF
Compilation failed in require at /usr/libdata/perl/BSDPAN/BSDPAN/Override.pm
line 17.
Compilation failed in require at /usr/libdata/perl/BSDPAN/Config.pm line 37.
BEGIN failed--compilation aborted at /usr/libdata/perl/BSDPAN/Config.pm line 37.
Compilation failed in require at
/usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5/configpm line 430.
*** Error code 255
Stop in /usr/src/gnu/usr.bin/perl/perl.
*** Error code 1
Stop in /usr/src/gnu/usr.bin/perl.
*** Error code 255
Stop in /usr/src/gnu/usr.bin/perl/perl.
*** Error code 1
Stop in /usr/src/gnu/usr.bin/perl.
snip snip
Cheers,
*Anton.
--
| Anton Berezin| FreeBSD: The power to serve |
| catpipe Systems ApS _ _ |_ | http://www.FreeBSD.org |
| [EMAIL PROTECTED](_(_|| |[EMAIL PROTECTED] |
| +45 7021 0050| Private: [EMAIL PROTECTED] |
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
kern/29530
Could anybody examine and commit the patch in the PR kern/29530? It fixes the support for KingByte USB Pen Drive by adding a quirk entry to src/sys/cam/scsi/scsi_da.c. It would be even better if this were MFC'ed before 4.4 comes out. Thank you in advance! Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Request for change: Disabling filename globbing by ftpd(8)
Greetings,
* Conclusion and suggestion first:
Csh-style filename globbing in ftpd(8) is *evil*. Please apply the
attached patch to make it an option and disable it in the default
configuration.
* What the patch does:
It makes the filename globbing an optional feature, controlled by the
new flag -g. -g none disables the globbing entirely (default),
-g tildeonly enables home expansion (aka tilde expansion) only, and
-g all enables all expansions using glob(3). The current behavior can
be kept by using -g all.
* My reason to it:
Many FTP clients, especially automated mirroring tools and GUI-based
ones, and most notably the `mget' command commonly found on standard
FTP clients, do one thing in common: they obtain the name of the remote
repository using NLST command then subsequently use some or all of the
returned names as the argument to other commands such as RETR.
In order for this approach to succeed, arguments to the RETR command
must not be parsed in any special way but they must be considered as
literal filenames. However, this is not the case with the stock ftpd(8)
shipped with FreeBSD; it has a `feature' that expands the argument to
RETR/CWD/STOR/... commands in a Csh-like way (i.e. filename globbing,
tilde/brace/bracket/ampersand expansions).
This changes the semantics of the on-the-wire protocol. RFC 959 does
not specify any special handling of pathname arguments, so the change
breaks compatibility with any potential client which legitimately
assumes no special tweaks to pathnames are necessary.
Moreover, commands such as RETR, CWD and STOR only expect an argument
that designates a single file or directory; it is impossible to fetch
multiple files using RETR, or chdir into multiple directories at once
:-). In this context, globbing by ftpd is nothing more than an useful
shorthand (e.g. we can say cd abc* instead of cd abcdefghijklmnopq),
which is much better to be done on the client side.
Example: the remote directory contains two files, `A.jpg' and `A{3}.jpg'
and the client tries to `mget A*.jpg'.
Step 1. The client sends NLST command.
Step 2. The server returns a full listing of the remote directory.
Step 3. The client searches through the list and picks up the two files.
Step 4. The client performs `RETR A.jpg', which succeeds.
Step 5. The client performs `RETR A{3}.jpg', which fails because the
server performs brace expansion on the name and tries to send `A3.jpg'.
Any comments and suggestions are welcomed. Thank you.
Best Regards,
Eugene
diff -urN ftpd/ftpcmd.y ftpd.new/ftpcmd.y
--- ftpd/ftpcmd.y Wed Apr 18 03:03:52 2001
+++ ftpd.new/ftpcmd.y Mon Jul 9 01:34:29 2001
@@ -71,6 +71,7 @@
#include libutil.h
#include extern.h
+#include types.h
extern union sockunion data_dest, his_addr;
extern int logged_in;
@@ -92,6 +93,8 @@
extern char tmpline[];
extern int readonly;
extern int noepsv;
+extern globbing_t globbing;
+extern char curname[MAXLOGNAME];
off_t restart_point;
@@ -924,7 +927,7 @@
* processing, but only gives a 550 error reply.
* This is a valid reply in some cases but not in others.
*/
- if (logged_in $1) {
+ if (logged_in globbing == GLOBBING_ALL $1) {
glob_t gl;
int flags =
GLOB_BRACE|GLOB_NOCHECK|GLOB_QUOTE|GLOB_TILDE;
@@ -944,6 +947,37 @@
}
globfree(gl);
free($1);
+ } else if (globbing == GLOBBING_TILDEONLY
+ $1[0] == '~') {
+ /* do tilde expansion by ourselves */
+ char *dir, *newdir, *afteruser, afteruser_ch;
+ struct passwd *pw;
+ $$ = $1;
+ do {
+ dir = strdup($1);
+ if (dir == NULL)
+ break;
+ afteruser = strchr(dir, '/');
+ if (afteruser == NULL)
+ afteruser = strchr(dir, '\0');
+ afteruser_ch = *afteruser;
+ *afteruser = '\0';
+ pw = getpwnam((dir[1] != '\0')
+ ? dir + 1 : curname);
+ *afteruser = afteruser_ch;
+ if (pw == NULL || pw-pw_dir == NULL)
+ break;
+ asprintf(newdir, %s%s,
+ pw-pw_dir, afteruser);
+
Cross-platform make world/release?
Greetings, Short question: is FreeBSD capable of cross-platform make world and release (e.g. build of Alpha world/release on x86 and vice versa)? TIA, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Small fix for compile error with internat crypto code
It looks like a race condition. -@mkdir -p openssl is a good workaround I guess, although it could be fine if we had a flag to mkdir(1) that makes it just succeed when there's already a directory of the same name. Just my 2 wons (1 KRW ~= .0084 USD as of this writing :-p), Eugene On Fri, 12 May 2000, David O'Brien wrote: | On Fri, May 12, 2000 at 04:41:09PM +0900, Munehiro Matsuda wrote: | When run 'make -j4 buildworld' with internat crypto code installed, | I get following error: | mkdir: openssl: File exists | *** Error code 1 | - @test -d openssl || mkdir -p openssl | + -@mkdir -p openssl | | The "-" is not needed as `mkdir -p' will not return an error condition. | | - @test -d openssl || mkdir -p openssl | + -@mkdir -p openssl | | Same here. Bruce Evans just told me the other day that make(1) can have | issues with shell "" and "||". Guess you hit one of the cases it can | fail with -j. | | -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Small fix for compile error with internat crypto code
On Fri, 12 May 2000, David O'Brien wrote: | On Fri, May 12, 2000 at 06:34:08AM -0700, Eugene M. Kim wrote: | I guess, although it could be fine if we had a flag to mkdir(1) that | makes it just succeed when there's already a directory of the same name. | | Yes, that is "-p". | Oh yes you're right. But then things still remain strange... Isn't this: test -d openssl || mkdir -p openssl supposed to never give the `mkdir: openssl: File exists' error? So I guess the real cause of that bug is not a race condition between two mkdir -p commands. Haven't seen the error recently so can't exactly tell, but it looks more like there is already an `openssl' that isn't a directory. Eugene -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Top, vmstat, systat, etc. Broken
Check if your /dev/null has been replaced by some stupid `real' file. The `nlist failed' problem bit me several weeks ago on two machines (one running 4-stable and the other running -current) and it turned out to be a /dev/null problem. You may want to remove /dev/null maually and do a `sh MAKEDEV std' to alleviate this problem. I don't have the vaguest idea how this happened, though. Hope this helped, Eugene On Mon, 3 Apr 2000, Thomas Dean wrote: | To build the kernel, I | | # cd sys/i386/conf | # config -r name | # cd ../../compile/name | # make depend | # make -j36 | # make install | | /etc/make.conf has no uncommented lines in it. | | # file /kernel | /kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), | dynamically linked, not stripped | | tomdean | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6: can a link-site (or global) address be configured inrc.conf?
(Cc'ed to the 6BONE mailing list in the hope that someone there could answer my question as well) Speaking of the address allocation, is there a way for an individual to get a non-local address space (so that all of my machines can get an unique IPv6 address)? I've read through the 6BONE website, and it seems to me that I somehow have to `qualify' in order to get one. (And the fact that I just need 10 addresses makes me feel guilty; AFAIK the minimum allocation unit is 2^64-address block :-p.) Thank you in advance, Eugene On Mon, 6 Mar 2000, Bill Fenner wrote: | Bruce is right that machines expect to learn their prefixes from their | local router; however if you're just playing around you might want to | set it yourself. The easiest way I've found to do this is to say that | this machine is a router: | | # sysctl -w net.inet6.ip6.forwarding=1 | net.inet6.ip6.forwarding: 0 - 1 | | and then run "prefix" to set a site-local prefix: | | # prefix dc0 fec0:0:0:1:: | # ifconfig dc0 | dc0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 | inet6 fe80::2a0:ccff:fe36:7410%dc0 prefixlen 64 scopeid 0x1 | inet6 fec0::1:2a0:ccff:fe36:7410 prefixlen 64 | | Of course, if you have global address space too you can assign that prefix | too. | | Bill -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with voxware/snd0 kernel compilations..
$ grep -l '^mpu401' /sys/i386/isa/sound/*.c /sys/i386/isa/sound/mpu401.c $ grep '^i386/isa/sound/mpu401\.c' /sys/conf/files.i386 i386/isa/sound/mpu401.c optionalmpu i386/isa/sound/mpu401.c optionalsscape $ I guess css0 needs mpu0 to handle the onboard MPU401 interface. HTH, Eugene On Thu, 10 Feb 2000, f.johan.beisser wrote: | | i'm attempting to build a kernel with the "old style" voxware drivers for | the CS423x (crystal sound, or css0 in the kernel config) and i get this | wonderful error torwards the end of the kernel build: | | cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes | -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual | -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include | -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c | linking kernel | cs4232.o: In function `attach_cs4232': | cs4232.o(.text+0x1cb): undefined reference to `probe_mpu401' | cs4232.o(.text+0x1d8): undefined reference to `attach_mpu401' | *** Error code 1 | | | and it fails, obviously. everything prior to the make goes just fine.. | | any clues or advice? | | -- jan | | +-/ f. johan beisser /--+ | email: jan[at]caustic.org web: http://www.caustic.org/~jan |"knowledge is power. power corrupts. study hard, be evil." | | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: any ideas on Vortex?
On Wed, 9 Feb 2000, Kenneth Wayne Culver wrote: | Just wondering, does anyone know if we will have a working driver for the | Aureal Vortex soundcard by the time 4.0 is released? I'm just curious | because I thought the driver for this card was supposed to be finished a | long time ago.. If my memory serves me correctly, the support for Vortex chipset family has been suspended due to lack of programming information. I hope the situation will get better when Aureal releases the technical documentation (which they promised to do on their website -- linux.aureal.com). Eugene -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Pre-3.3 to 4.0 w/ IPsec
On Sun, 6 Feb 2000, John Polstra wrote: | In article [EMAIL PROTECTED], | Eugene M. Kim [EMAIL PROTECTED] wrote: | Just wanted to share the knowledge of this little devil. | | For those who want to upgrade via cvsup their pre-3.3 system to test | IPsec: due to the addition of src-sys-crypto in secure-supfile, one will | have to cvsup first, upgrade their /usr/share/examples directory (cd | /usr/src/share/examples ; make depend all install) and cvsup again | before they can compile a kernel with IPsec. | | That seems like a pretty hard way to do it. Why not just edit your | supfile and add src-sys-crypto to it? Because the supfiles could have other changes as well, but yes I agree with you that it's an overdose :-). An alternative and more general way could be checking out `examples' from one of the anonymous CVS repositories (such as anoncvs.freebsd.org) and doing `make depend all install' in that directory before actually cvsupping the whole source tree. This shouldn't be too difficult given the fact that we already have cvs in the base system. Eugene -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ftp 10.10
Well, a reluctant yes. I've been enjoying the notation of '127.1' (and it's hardcoded to several scripts of mine). This is actually a hard decision; from the compatibility point of view inet_aton should allow non-standard forms, but from the standard's point of view it shouldn't. I'd rather leave this to the current trend (of which I don't have the vaguest idea). Regards, Eugene On Mon, 7 Feb 2000, Yoshinobu Inoue wrote: | marc With ping it is still functioning. I cannot find what changed this. | marc cvs messages for Changes to /usr/src/usr.bin/ftp/util.c of 18 and 20 | marc Jan do not mention it. So maybe somewhere else to look? | | Several applications which support both IPv4 and IPv6, such as | telnet/ftp, has used getaddrinfo() for resolving hostnames. | | If IPv4 dotted-decimal forms are given, getaddrinfo() calls finally | inet_pton(). inet_pton() is defined in RFC2553 and it does not permit | non-standard IPv4 dotted-decimal, such as 10.10 | | Do people have troubles with this change? | | Yoshinobu Inoue | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Pre-3.3 to 4.0 w/ IPsec
Just wanted to share the knowledge of this little devil. For those who want to upgrade via cvsup their pre-3.3 system to test IPsec: due to the addition of src-sys-crypto in secure-supfile, one will have to cvsup first, upgrade their /usr/share/examples directory (cd /usr/src/share/examples ; make depend all install) and cvsup again before they can compile a kernel with IPsec. Regards, Eugene PS. Could this be a candidate for UPDATING? -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Installing to a differnet root?
The following should do it: cd /usr/src make installworld DESTDIR=/remotefs cd /usr/src/etc make distrib-dirs distribution DESTDIR=/remotefs Regards, Eugene On Sat, 22 Jan 2000, Rod Taylor wrote: | I've briefly read various documents, and haven't discovered a way to | installworld to a different path than /. | | In particular, I'd like to install to /remotefs/. | | I've got tftp, bootp, etc. all setup and ready to go but would like a clean | 'world' to modify as opposed to a pre-existing one. | | Thanks! -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: config tool breaks
Recently there has been a change in config directory layout (all *.i386 files has been moved from /sys/i386/conf to /sys/conf), so you have to rebuild /usr/sbin/config first. HTH, Eugene PS. PACBELLThe Handbook is, once again, your friend :-)/PACBELL. On Tue, 11 Jan 2000, Forrest Aldrich wrote: | Is this a bug, or did I miss something on the list | that changed this procedure: | | | cd /usr/src/sys/i386/conf) | | bash-2.03# config MYMACHINE | config: files.i386: No such file or directory | bash-2.03# exit | | The files.* is missing, etc. No changes after a cvsup. | | | | _F | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 testing...willing to help
On Sat, 8 Jan 2000, Yoshinobu Inoue wrote: | I have a DEC Alpha at home running 4.0-current and am willing to help out with | the testing. I am not the worlds greatest coder, but am willing to do what I can | | Thanks! | | The 1st thing I want to be tested is that, a kernel with | following additions to the config file | | options INET6 #IPv6 communications protocols | options IPSEC #IP security | options IPSEC_ESP #IP security (crypto; define w/ IPSEC) | options IPSEC_IPV6FWD #IP security tunnel for IPv6 | options IPSEC_DEBUG #debug for IP security | | pseudo-device gif 4 #IPv6 and IPv4 tunneling | pseudo-device faith 1 #for IPv6 and IPv4 translation | | just works fine, | and also all apps on your environments which you are usually | using still works fine on that kernel. I've done this this morning and found that all of a sudden natd and related stuff stopped working; it leads to a kernel panic whenever a machine inside natd tries to access the Internet. IIRC, the kernel option IPDIVERT was documented to be incompatible in KAME LINT; maybe this should be documented in our LINT as well? For now, I've reverted to my previous kernel (because my mom would get upset if the Internet gets inaccessible from her Win98 box), but if you give further direction, I can do some testing while she's off the computer. :-) Thank you, Eugene -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: breakage in this morning's build
AOLMe too!/AOL Mine goes like: cc -O6 -m486 -pipe -Wall -Wall -Wformat -I/usr/obj/pubfs/1/root/world/src/tmp/usr/include -static -o rm rm.o stat_flags.o install -c -s -o root -g wheel -m 555 rm /usr/obj/pubfs/1/root/world/src/tmp/bin rm: /usr/obj/pubfs/1/root/world/src/bin/rm: Operation not supported by device *** Error code 1 Stop in /pubfs/1/root/world/src/bin/rm. *** Error code 1 Cheers, Eugene On Mon, 30 Aug 1999, Mike Muir wrote: | Pascal Hofstee wrote: | | I am suffering from the exact same problem here as well ... (tried about 4 | times now ... without success) | | Mines a little (little) different: | | install -c -s -o root -g wheel -m 555 mv /usr/obj/usr/src/tmp/bin | /usr/obj/usr/src/bin/mv created for /usr/src/bin/mv | cd /usr/src/bin/rm; /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO | -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -D_BUILD_TOOLS cleandepend; | /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC | -DNOPROFILE -DNOSHARED -D_BUILD_TOOLS all; | /usr/obj/usr/src/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC | -DNOPROFILE -DNOSHARED -D_BUILD_TOOLS -B install cleandir obj | rm -f .depend /usr/obj/usr/src/bin/rm/GPATH | /usr/obj/usr/src/bin/rm/GRTAGS /usr/obj/usr/src/bin/rm/GSYMS | /usr/obj/usr/src/bin/rm/GTAGS | cc -O -pipe -Wall -Wformat -I/usr/obj/usr/src/tmp/usr/include -c | /usr/src/bin/rm/rm.c | cc -O -pipe -Wall -Wformat -I/usr/obj/usr/src/tmp/usr/include -c | /usr/src/bin/rm/../ls/stat_flags.c | cc -O -pipe -Wall -Wformat -I/usr/obj/usr/src/tmp/usr/include -static | -o rm rm.o stat_flags.o | install -c -s -o root -g wheel -m 555 rm /usr/obj/usr/src/tmp/bin | rm: /usr/obj/usr/src/bin/rm: Inappropriate ioctl for device | *** Error code 1 | | Stop in /usr/src/bin/rm. | *** Error code 1 | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
