Re: KDE Konsole, crashes, on a SIGABRT...
On Sat, Aug 23, 2003 at 09:12:38PM +0200, Michael Nottebrock wrote: Content-Description: signed data On Saturday 23 August 2003 16:52, I wrote: Incidentally, Adriaan de Groot just dug up a set of patches for konsole konsole_grantpty, I quickly adapted those for the kdebase port. They apply, but I'm still compiling kdebase with those myself, so beware, they might turn konsole into a Teletubbie FWIW (although Adriaan says they work okay for him, so there). Find the patch attached to this message. Or rather, find it at http://lofi.dyndns.org/~lofi/patch-konsole , the attachment has been stripped. BTW: Is there a place or a person that has a list of which mailing lists will actually accept mails with attachments these days? And which of the lists is subscriber only or not? It used to be very easy (outside-posts work everywhere, attachments work everwhere), but I guess times have changed. As far as I know text attachments are still accepted. So, if the attachment is being stripped either you are sending gziped/uuencoded attachments or your MUA is not describing it as text. The latter used to happen to me when I was using sylpheed (I've seen the light and switched to Mutt now :-) YMMV. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: 00E8 61BC 0D75 7FFB E4D3 6BF1 B239 D010 3215 D418 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon ! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On Sun, Aug 03, 2003 at 04:11:12PM +0200, Jens Rehsack wrote: the patch works for me very well. I've checked what's been done and had only small recommendations: - Wouldn't it be better to configure the devfs rules by /etc/devfs.conf or is it impossible? - Even it would be a good thing, if I could specify a ruleset for each jail, and fallback to devfs_ruleset_jail if no jail_example_devfs_ruleset is specified? Ok. Here's a retooled patch. It now includes a devfs rule specification format that we can even use in the general case (i.e. - for /dev). The default rules for a jail are included in it. It's in etc/defaults/devfs.rules and should be self-explanatory. I also put back Scott's code in rc.d/jail for handlind rulesets for individual jails. But I kept the default jail ruleset hard-coded. I don't see the poing of creating yet another knob for it. If a user doesn't want the default that's what the individual knobs for the jails are there for :) Let me know how it goes. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On Tue, Jul 29, 2003 at 08:27:07PM +0200, Jens Rehsack wrote:
On 29.07.2003 19:21, Mike Makonnen wrote:
On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote:
Yeah, I'll take care of this. I had asked scott to mail me his final
patch so I could commit it, but I never heard back from him. I'll
dig out the revisions from my mail archives and combine the
two.
You can mail me the patch first, so that I can test it before you
commit it, if you want.
Hi Jens,
Can you apply the attached patches and let me know how it goes?
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
[EMAIL PROTECTED]| FreeBSD - Unleash the Daemon!
Index: etc/rc.subr
===
RCS file: /home/ncvs/src/etc/rc.subr,v
retrieving revision 1.13
diff -u -r1.13 rc.subr
--- etc/rc.subr 9 Jun 2003 17:31:06 - 1.13
+++ etc/rc.subr 1 Aug 2003 23:05:21 -
@@ -1033,3 +1033,160 @@
esac
fi
}
+
+# devfs_init_rulesets
+# Initialize default system supplied rulesets.
+#
+devfs_init_rulesets()
+{
+ local rsHide rsBasic rsLogin rsJail _me
+ rsHide=$devfs_ruleset_hide
+ rsBasic=$devfs_ruleset_basic
+ rsLogin=$devfs_ruleset_login
+ rsJail=$devfs_ruleset_jail
+ _me=devfs_init_rulesets
+
+ # Go through this only once
+ if [ -n $devfs_rulesets_init ]; then
+ debug $_me: devfs rulesets already initialized
+ return
+ fi
+
+ # Hide: Hide all devices
+ #
+ /sbin/devfs rule -s $rsHide delset
+ /sbin/devfs rule -s $rsHide add hide
+
+ # Basic: Basic devices typically necessary
+ #
+ /sbin/devfs rule -s $rsBasic delset
+ /sbin/devfs rule -s $rsBasic add path null unhide
+ /sbin/devfs rule -s $rsBasic add path zero unhide
+ /sbin/devfs rule -s $rsBasic add path random unhide
+ /sbin/devfs rule -s $rsBasic add path urandom unhide
+
+ # Login: Devices typically needed to support loged-in users
+ #
+ /sbin/devfs rule -s $rsLogin delset
+ /sbin/devfs rule -s $rsLogin add path 'ptyp*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptyq*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptyr*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptys*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptyP*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptyQ*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptyR*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptyS*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyp*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyq*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyr*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttys*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyP*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyQ*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyR*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyS*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'fd/*' unhide
+ /sbin/devfs rule -s $rsLogin add path stdin unhide
+ /sbin/devfs rule -s $rsLogin add path stdout unhide
+ /sbin/devfs rule -s $rsLogin add path stderr unhide
+
+ # Jail: Devices typically usefull in a jail
+ #
+ /sbin/devfs rule -s $rsJail add path '*' include $rsHide
+ /sbin/devfs rule -s $rsJail add path '*' include $rsBasic
+ /sbin/devfs rule -s $rsJail add path '*' include $rsLogin
+
+ devfs_rulesets_init=1
+ debug $_me: devfs rulesets initialized
+}
+
+# devfs_set_ruleset ruleset [dir]
+# Sets the default ruleset of dir to ruleset.
+# Returns non-zero if it could not set it successfully.
+#
+devfs_set_ruleset()
+{
+ local devdir rs _me
+ rs=$1
+ [ -n $2 ] devdir=-m $2 || devdir=
+ _me=devfs_set_ruleset
+
+ if [ -z $rs ]; then
+ warn $_me: you must specify a ruleset number
+ return 1
+ fi
+ debug $_me: setting ruleset ($rs) on mount-point (${devdir#-m })
+ if ! /sbin/devfs $devdir ruleset $rs ; then
+ warn $_me: unable to set ruleset $rs to ${devdir#-m }
+ return 1
+ fi
+ return 0
+}
+
+# devfs_apply_ruleset ruleset [dir]
+# Apply ruleset number $ruleset to the devfs mountpoint $dir.
+# Returns 0 on success or non-zero if it could not apply
+# the ruleset.
+#
+devfs_apply_ruleset()
+{
+ local devdir rs _me
+ rs=$1
+ [ -n $2 ] devdir=-m $2 || devdir=
+ _me=devfs_apply_ruleset
+
+ if [ -z $rs ]; then
+ warn $_me: you must specify a ruleset
+ return 1
+ fi
+ debug $_me: applying ruleset ($rs) to mount-point (${devdir#-m })
+ if ! /sbin/devfs $devdir rule -s $rs applyset
Re: rcng: additional argument to run_rc_command
On Tue, Jul 29, 2003 at 01:13:51PM +0200, Tobias Roth wrote: is it possible to give an extra argument to an $extra_commands command? the usual call to run_rc_command run_rc_command $1 suggests otherwise, as $1 already is the name of the command to be executed (start, stop, etc). would this be possible/a good idea to implement? I very much doubt it. If you want to use multiple arguments just special case it in the script itself (i.e - rc.d/netif). Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote: On 29.07.2003 18:47, Robert Watson wrote: Someone, and unfortunately I appear to have lost track of who, had some tweaks to the rcNG scripts to set up some reasonable devfs rules for a jail, and apply them to the devfs mounted in a jail. Otherwise, you risk exposing undesired device nodes to the virtual environment. I suspect a search of the -current archives will turn up who, but I think a necessary part of a solution here will be to make sure jails are set up with the right devfs contents. Sorry, overseen. Sct W. Hetzel was the submitter, but it never becomes committed. If could be be so kind, please :-) (of course, not without prove it first) Yeah, I'll take care of this. I had asked scott to mail me his final patch so I could commit it, but I never heard back from him. I'll dig out the revisions from my mail archives and combine the two. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: syntax problem with /etc/rc.d/nfslocking
Thanks! I just committed a fix (reproduced here for your convenience). Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! Index: etc/rc.subr === RCS file: /home/ncvs/src/etc/rc.subr,v retrieving revision 1.13 diff -u -r1.13 rc.subr --- etc/rc.subr 9 Jun 2003 17:31:06 - 1.13 +++ etc/rc.subr 24 Jul 2003 18:15:02 - @@ -669,7 +669,7 @@ # if the precmd failed and force # isn't set, exit # - if [ -n $_precmd ]; then + if [ -n $_precmd ]; then eval $_precmd _return=$? [ $_return -ne 0 ] [ -z $rc_force ] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Portable USB hard drive regression
On Wed, Jul 23, 2003 at 11:00:18AM -0700, John-Mark Gurney wrote: Please provide more information, such as dmesg including the controller you are using. Also, you don't state if this is USB2.0 device or a USB1.1 device. This makes it hard to debug and understand. Also, I would recomment you recompile your kernel w/ USB_DEBUG, and be prepared to turn on various sysctl's to provide more information. OK, here's the data you asked for: The hard drive says it supports USB 2.0, but my machine only has USB 1.0 controllers. The complete dmesg is at: http://people.freebsd.org/~mtm/dmesg.boot , but the USB part is: uhci0: VIA 83C572 USB controller port 0xb400-0xb41f irq 12 at device 7.2 on pc i0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Microsoft Microsoft Wheel Mouse Optical\M-., rev 1.10/1.21, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. uhci1: VIA 83C572 USB controller port 0xb800-0xb81f irq 12 at device 7.3 on pc i0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ugen0: Genesys Logic USB Host To Host Bridge, rev 1.00/1.80, addr 2 The output when I try to connect the device (with options USB_DEBUG): Jul/24 [EMAIL PROTECTED] ~% sysctl -a | grep usb hw.usb.ehci.debug: 0 hw.usb.ohci.debug: 1 hw.usb.ugen.debug: 1 hw.usb.uhci.debug: 1 hw.usb.uhci.loop: 0 hw.usb.uhid.debug: 0 hw.usb.uhub.debug: 1 hw.usb.ukbd.debug: 0 hw.usb.ulpt.debug: 0 hw.usb.umass.debug: 1 hw.usb.ums.debug: 0 hw.usb.urio.debug: 1 hw.usb.uscanner.debug: 0 hw.usb.debug: 1 uhub_explore: status change hub=1 port=1 usbd_new_device bus=0xc261 port=1 depth=1 speed=2 usbd_new_device: adding unit addr=3, rev=200, class=0, subclass=0, protocol=0, maxpacket=64, len=18, speed=2 usbd_new_device: new dev (addr 3), dev=0xc2670200, parent=0xc2640b00 usbd_probe_and_attach: trying device specific drivers usbd_probe_and_attach: no device specific driver found usbd_probe_and_attach: looping over 1 configurations usbd_set_config_index: status=0x0001, error=NORMAL_COMPLETION usbd_set_config_index: (addr 2) cno=3 attr=0xc0, selfpowered=1, power=98 usbd_set_config_index: set config 2 umass0: NewAge International STORIX Fusion25, rev 2.00/11.00, addr 3 umass0: SCSI over Bulk-Only; quirks = 0x umass0:4:0:-1: Attached to scbus4 uhci_timeout: uxfer=0xc29a5100 uhci_timeout_task: xfer=0xc29a5100 uhci_check_intr: aborted xfer=0xc29a5100 uhci_timeout: uxfer=0xc2526500 uhci_timeout_task: xfer=0xc2526500 uhci_check_intr: aborted xfer=0xc2526500 umass0: BBB reset failed, TIMEOUT uhci_timeout: uxfer=0xc29a5100 uhci_timeout_task: xfer=0xc29a5100 uhci_check_intr: aborted xfer=0xc29a5100 uhci_timeout: uxfer=0xc2526500 uhci_timeout_task: xfer=0xc2526500 uhci_check_intr: aborted xfer=0xc2526500 umass0: BBB reset failed, TIMEOUT uhci_timeout: uxfer=0xc29a5100 uhci_timeout_task: xfer=0xc29a5100 uhci_check_intr: aborted xfer=0xc29a5100 uhci_timeout: uxfer=0xc2526500 uhci_timeout_task: xfer=0xc2526500 uhci_check_intr: aborted xfer=0xc2526500 umass0: BBB reset failed, TIMEOUT uhci_timeout: uxfer=0xc29a5100 uhci_timeout_task: xfer=0xc29a5100 uhci_check_intr: aborted xfer=0xc29a5100 uhci_timeout: uxfer=0xc2526500 uhci_timeout_task: xfer=0xc2526500 uhci_check_intr: aborted xfer=0xc2526500 umass0: BBB reset failed, TIMEOUT uhci_timeout: uxfer=0xc29a5100 uhci_timeout_task: xfer=0xc29a5100 uhci_check_intr: aborted xfer=0xc29a5100 uhci_timeout: uxfer=0xc2526500 uhci_timeout_task: xfer=0xc2526500 uhci_check_intr: aborted xfer=0xc2526500 umass0: BBB reset failed, TIMEOUT Please let me know how else I can be of assistance. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Portable USB hard drive regression
I have a Storix Fusion USB 60GB hard drive. It used to work on 5.0-CURRENT. I tried using it again after I noticed the USB crapiness thread, and it's now giving the following errors when I plug it into 5.1-CURRENT umass0: NewAge International STORIX Fusion25, rev 2.00/11.00, addr 3 umass0: BBB reset failed, TIMEOUT umass0: BBB reset failed, TIMEOUT umass0: BBB reset failed, TIMEOUT umass0: BBB reset failed, TIMEOUT umass0: BBB reset failed, TIMEOUT Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: improper umtx access
On Sat, Jul 19, 2003 at 08:12:42PM +1000, Peter Kostouros wrote: Hi I received a panic: improper umtx access from a system cvsup'ed about 8 hours ago. It occurred when executing mcs (mono C# compiler). Note /etc/libmap.conf had libc_r.so* pointing to libthr.so* for mono/mcs. I am also running the SCHED_ULE scheduler. My fault. It's fixed now. $FreeBSD: src/sys/kern/kern_umtx.c,v 1.11 2003/07/19 11:32:48 mtm Exp $ Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
XFree86 kernel panic
Hi guys,
Attached is a gdb trace of a panic on a -current system from a few
days ago. It seems like it was caused by a select(2) in XFree86.
Although I was testing some unrelated changes in libthr kernel code,
I have seen this panic before (about 2 weeks ago) on a stock
kernel.
FreeBSD kokeb.ambesa.net 5.1-CURRENT FreeBSD 5.1-CURRENT #12:
Sat Jul 5 02:00:40 EDT 2003 [EMAIL
PROTECTED]:/a/current/obj/a/current/src/sys/THRTEST i386
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
[EMAIL PROTECTED]| FreeBSD - The Power To Serve
Script started on Sat Jul 5 19:43:02 2003
Jul/05 [EMAIL PROTECTED] ~% sudo gdb -k
/a/current/obj/a/current/src/sys/THRTEST/kernel.debug /var/crash/vmcore.9
Password:
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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-undermydesk-freebsd...
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x818181b1
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc026a3e2
stack pointer = 0x10:0xd2657b08
frame pointer = 0x10:0xd2657b1c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 3
current process = 735 (XFree86)
trap number = 12
panic: page fault
syncing disks, buffers remaining... 2223 2223 2221 2221 2219 2219 2219 2219 2219
2219 2219 2219 2219 2219 2219 2219 2219 2219 2219 2219 2219 2219 2219 2219
giving up on 154 buffers
Uptime: 16h51m12s
Dumping 255 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from /boot/kernel/snd_via82c686.ko...done.
Loaded symbols for /boot/kernel/snd_via82c686.ko
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/netgraph.ko...done.
Loaded symbols for /boot/kernel/netgraph.ko
Reading symbols from /boot/kernel/ng_ether.ko...done.
Loaded symbols for /boot/kernel/ng_ether.ko
Reading symbols from /boot/kernel/ng_pppoe.ko...done.
Loaded symbols for /boot/kernel/ng_pppoe.ko
Reading symbols from /boot/kernel/ng_socket.ko...done.
Loaded symbols for /boot/kernel/ng_socket.ko
Reading symbols from /boot/kernel/if_tun.ko...done.
Loaded symbols for /boot/kernel/if_tun.ko
#0 doadump () at /a/current/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /a/current/src/sys/kern/kern_shutdown.c:240
#1 0xc023f1fd in boot (howto=256)
at /a/current/src/sys/kern/kern_shutdown.c:372
#2 0xc023f578 in panic () at /a/current/src/sys/kern/kern_shutdown.c:550
#3 0xc03d42a0 in trap_fatal (frame=0xd2657ac8, eva=0)
at /a/current/src/sys/i386/i386/trap.c:836
#4 0xc03d3fb3 in trap_pfault (frame=0xd2657ac8, usermode=0, eva=2172748209)
at /a/current/src/sys/i386/i386/trap.c:750
#5 0xc03d3b98 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 3, tf_esi = 36, tf_ebp =
-765101284, tf_isp = -765101324, tf_ebx = -1032921444, tf_edx = -1032921444, tf_ecx =
-1028802816, tf_eax = -2122219135, tf_trapno = 12, tf_err = 0, tf_eip = -1071209502,
tf_cs = 8, tf_eflags = 78466, tf_esp = -1032945408, tf_ss = 64})
at /a/current/src/sys/i386/i386/trap.c:435
#6 0xc03c56c8 in calltrap () at {standard input}:96
#7 0xc02654cf in selscan (td=0xc28bbd10, ibits=0xd2657b9c, obits=0xd2657b8c,
nfd=50) at file.h:272
#8 0xc0264f8d in kern_select (td=0xc28bbd10, nd=50, fd_in=0x81fba20,
fd_ou=0x0, fd_ex=0x0, tvp=0xd2657cd8)
at /a/current/src/sys/kern/sys_generic.c:822
#9 0xc0264b56 in select (td=0x0, uap=0xd2657d14)
at /a/current/src/sys/kern/sys_generic.c:726
#10 0xc03d459a in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1, tf_esi = 7482434, tf_ebp =
-1077937896, tf_isp = -765100684, tf_ebx = 0, tf_edx = 16, tf_ecx = 143876576, tf_eax
= 93, tf_trapno = 0, tf_err = 2, tf_eip = 673590515, tf_cs = 31, tf_eflags = 12870,
tf_esp = -1077938516, tf_ss = 47})
at /a/current/src/sys/i386/i386/trap.c:1023
#11 0xc03c571d in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
(kgdb) qqui uit t
]2;mtm (ttyp2) kokeb:~]1;[EMAIL PROTECTED]:~Jul/05 [EMAIL PROTECTED] ~% ^Dexit
Script done on Sat Jul 5 19:44:17 2003
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo
Re: default route not added (despite message to the contrary)
On Wed, Jul 02, 2003 at 08:33:58PM +1000, Graham Menhennitt wrote: I have the following /etc/rc.conf: -- network_interfaces=rl0 lo0 ifconfig_rl0=inet 203.2.73.2 netmask 255.255.255.0 hostname=fang.mencon.com.au defaultrouter=203.2.73.1 nfs_server_enable=YES nfs_client_enable=YES xntpd_enable=YES sshd_enable=YES lpd_enable=YES inetd_enable=YES ipv6_enable=YES linux_enable=NO --- When my machine boots, I see a message route add default 203.2.73.1 displayed on the console. However, when I try to ping an address outside my LAN, I get no route to host. If I then manually do route add default 203.2.73.1, it all starts working. I'm running -current as of a few days ago. Any clues?? Re-cvsup -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: libthr broken (was Re: HEADS UP: new KSE signal code)
Libthr should be working again. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: libthr broken (was Re: HEADS UP: new KSE signal code)
David's signal changes broke libthr. This is not his fault. The original implementation of sigtimedwait was broken and jdp (John Polstra) had worked up patches to fix it, but David beat him to it :-). Libthr depended on the old broken semantics of sigtimedwait, so any applications using libthr will be broken untill jdp commits the second part of his patch. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FeeBSD 5.1 and localdaemons
On Thu, 19 Jun 2003 03:33:48 -0400 Darin [EMAIL PROTECTED] wrote: But, the ProFTPD and MySQL still wont start.. I did some digging in the scripts in /etc/rc.d and found the local and localdaemons scripts.. After playing around a bit, I found that the localdaemons script is actually what executes the local scripts.. But for whatever reason, local is not starting localdaemons. It's not supposed to. rc.d/localdaemons is started independently later in the boot and the output you should see is: /etc/rc: DEBUG: run_rc_command: evaluating locald_start(). Local package initialization: I can start both daemons manually by running their scripts manually, so theres no problem that I can see with the installation.. I tried adding a line to the /etc/rc.d/local script that called the localdaemons script.. When I rebooted, MySQL and ProFTPD start fine during boot.. Anyone have any ideas on this one?? There must be something non-standard about your installation. This has been working fine for a long time. In fact, I have mysql server on my workstation and it comes up with every boot just like it's supposed to. Generally, the scripts in/usr/local/etc/rc.d should be executable and they should end with a '.sh' suffix. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-R: rcNG - 'mountall' missing?
On Tue, 17 Jun 2003 13:14:08 +1000 Johny Mattsson [EMAIL PROTECTED] wrote: I'm not sure what the best approach would be, so I'd like some feedback on this. Would it be acceptable to introduce another dummy target (like FILESYSTEMS)? From a purely FreeBSD perspective I would probably find this the cleanest, but I know we need to play nice with NetBSD too (do they have anything like md or vn?) so that might stuff things up. On FreeBSD all filesystems will be mounted by the time mountcritremote is done. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-R: rcNG - 'mountall' missing?
On Tue, 17 Jun 2003 12:16:53 +1000 Johny Mattsson [EMAIL PROTECTED] wrote: Is there a good reason why we don't have mountall? Are all avenues really covered by the mountcrit scripts? This stems from the fact that the way we handle filesystems is different from the way NetBSD handles it. For our purposes, we need one pass to mount local filesystems and a second one to mount remote ones. IIRC NetBSD requires that users specify their file systems in rc.conf. This might be useful to have on FreeBSD, as long as it's strictly optional, but I don't have the time or interest to work on it. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: -E flag in /etc/rc.d/ipfilter causes warnings
On 16 Jun 2003 21:35:44 -0400 Mike Bohan [EMAIL PROTECTED] wrote: Hello there, I recently ran into a slight issue with ipfilter running on 5.1-RELEASE. My machine serves the simple purpose as a nat gateway, so ipfilter is always going to be necessary on it. Due to this fact, i decided to include options IPFILTER in the kernel config, instead of dynamically loading the ipl.ko module. However, when ipfilter is used in the kernel image, it's automatically initialized (and thus does not need the -E flag). hmm... I thought it was the other way around (it's not effective when loaded as a module), but I may have misunderstood the man page. This has been noted in rc.conf for some time, and I of course removed the -E from the ipfilter_flags variable in that file. However, after booting my kernel with the IPFILTER options, I noticed warnings in my kernel logs that ipfilter has already been initialized, which is consistent with using flag -E when ipf is already initialized. After some brief analysis, I discovered that /etc/rc.d/ipfilter actually uses -E in the shell script function, ipfilter_start(). After removing the two instances of the -E and rebooting, the warning messages disappeared at boot time. Is this a known glitch in the hopes that people start soley using the ipl kernel module? It's really not a big deal either way, but I was more just curious than anything in which direction it's going. Thanks in advance! I believe it's harmless, and while not aesthetically pleasing, it's a necessary work-around. The stop command to rc.d/ipfilter uses -D to disable ipfilter, so it's necessary to use -E with the start command because there's no way to know how/when/why/in-what-environment it's being called. If I'm wrong or you have a better alternative to this please let me know. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sendmail starts before rpc.statd and rpc.lockd
On Sat, 7 Jun 2003 22:27:14 -0700 (PDT) David Yeske [EMAIL PROTECTED] wrote: Jun 8 00:52:33 photon sendmail[293]: h584pRfm000293: SYSERR(root): cannot flock(./tfh584pRfm000293, fd=5, type=6, omode=40001, euid=25^C. NFS access cache time=2 Starting statd. Starting lockd. I should clarify that /etc/rc.d/virecover is calling sendmail. Does virecover need to be called this early on? I've been thinking about moving nfs/nis stuff earlier in the boot processes. Can you try the following patch please? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve Index: etc/rc.d/accounting === RCS file: /home/ncvs/src/etc/rc.d/accounting,v retrieving revision 1.4 diff -u -r1.4 accounting --- etc/rc.d/accounting 12 Oct 2002 10:31:31 - 1.4 +++ etc/rc.d/accounting 9 Jun 2003 11:59:46 - @@ -5,7 +5,7 @@ # # PROVIDE: accounting -# REQUIRE: mountall +# REQUIRE: SERVERS mountall # BEFORE: DAEMON # KEYWORD: FreeBSD NetBSD Index: etc/rc.d/ldconfig === RCS file: /home/ncvs/src/etc/rc.d/ldconfig,v retrieving revision 1.6 diff -u -r1.6 ldconfig --- etc/rc.d/ldconfig 18 May 2003 03:39:39 - 1.6 +++ etc/rc.d/ldconfig 9 Jun 2003 12:01:37 - @@ -6,7 +6,7 @@ # PROVIDE: ldconfig # REQUIRE: mountall mountcritremote -# BEFORE: DAEMON +# BEFORE: SERVERS # KEYWORD: FreeBSD NetBSD . /etc/rc.subr Index: etc/rc.d/named === RCS file: /home/ncvs/src/etc/rc.d/named,v retrieving revision 1.6 diff -u -r1.6 named --- etc/rc.d/named 12 Jan 2003 04:53:54 - 1.6 +++ etc/rc.d/named 9 Jun 2003 15:13:26 - @@ -5,8 +5,8 @@ # # PROVIDE: named -# REQUIRE: SERVERS -# BEFORE: DAEMON +# REQUIRE: NETWORKING +# BEFORE: SERVERS # KEYWORD: FreeBSD NetBSD . /etc/rc.subr Index: etc/rc.d/nfslocking === RCS file: /home/ncvs/src/etc/rc.d/nfslocking,v retrieving revision 1.4 diff -u -r1.4 nfslocking --- etc/rc.d/nfslocking 20 Jan 2003 18:57:16 - 1.4 +++ etc/rc.d/nfslocking 9 Jun 2003 11:57:37 - @@ -6,7 +6,7 @@ # PROVIDE: nfslocking # REQUIRE: nfsserver nfsclient nfsd -# BEFORE: DAEMON +# BEFORE: SERVERS # KEYWORD: FreeBSD NetBSD . /etc/rc.subr Index: etc/rc.d/nisdomain === RCS file: /home/ncvs/src/etc/rc.d/nisdomain,v retrieving revision 1.1 diff -u -r1.1 nisdomain --- etc/rc.d/nisdomain 18 Apr 2003 17:51:54 - 1.1 +++ etc/rc.d/nisdomain 9 Jun 2003 11:53:47 - @@ -27,7 +27,7 @@ # # PROVIDE: nisdomain -# REQUIRE: SERVERS rpcbind +# REQUIRE: rpcbind # BEFORE: ypbind ypserv ypxfrd # KEYWORD: FreeBSD Index: etc/rc.d/rpcbind === RCS file: /home/ncvs/src/etc/rc.d/rpcbind,v retrieving revision 1.6 diff -u -r1.6 rpcbind --- etc/rc.d/rpcbind6 Sep 2002 16:18:05 - 1.6 +++ etc/rc.d/rpcbind9 Jun 2003 11:51:46 - @@ -6,6 +6,7 @@ # PROVIDE: rpcbind # REQUIRE: NETWORKING ntpdate syslogd named ppp +# BEFORE: SERVERS # KEYWORD: FreeBSD NetBSD . /etc/rc.subr Index: etc/rc.d/ypxfrd === RCS file: /home/ncvs/src/etc/rc.d/ypxfrd,v retrieving revision 1.4 diff -u -r1.4 ypxfrd --- etc/rc.d/ypxfrd 24 Jan 2003 00:37:52 - 1.4 +++ etc/rc.d/ypxfrd 9 Jun 2003 11:55:59 - @@ -4,7 +4,7 @@ # # PROVIDE: ypxfrd -# REQUIRE: rpcbind +# REQUIRE: SERVERS rpcbind # KEYWORD: FreeBSD . /etc/rc.subr ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient script in rc.d doesn't use ${dhcp_program}(conf/53007)
On Sat, 7 Jun 2003 03:18:18 -0600 John Nielsen [EMAIL PROTECTED] wrote: I just submitted a PR for a bug I noticed in the dhclient script. Namely, it ignores the setting of dhcp_program from rc.conf. A one-line fix did the trick for me, although there may be ramifications I'm not aware of. hmm it looks like the bug is actually our name for the program. In the new rc system there is glue code that automagically overides the command. But in order for it to work the variable has to be named a certain way in rc.conf. In this case the variable name is dhcp_program, but what it should really be is dhclient_program. This is another variable we're going to have to deprecate. Thanks for reporting this! Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rcNG automonter(amd)
On Sat, 07 Jun 2003 13:13:15 +0300
Danny Braniss [EMAIL PROTECTED] wrote:
hi,
I have a problem with /etc/rc.d/amd, because of the line
command_args=
${amd_program} gets run in the background, ldconfig failes to cache libraries
in /usr/local/lib (which is automounted :-)
Is there realy a need for the ? amd will background itself after it's
done
with the initialization stage anyway - and if not then it probably means
trouble.
This may have been because of a missed merge from rcOG. How does the following
work for you?
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
[EMAIL PROTECTED]| FreeBSD - The Power To Serve
Index: etc/rc.d/amd
===
RCS file: /home/ncvs/src/etc/rc.d/amd,v
retrieving revision 1.9
diff -u -r1.9 amd
--- etc/rc.d/amd12 Oct 2002 10:31:31 - 1.9
+++ etc/rc.d/amd7 Jun 2003 11:49:26 -
@@ -18,7 +18,6 @@
case ${OSTYPE} in
FreeBSD)
start_precmd=amd_precmd
- command_args=
;;
NetBSD)
command_args='-p -a '$amd_dir' -F /etc/amd.conf /var/run/amd.pid'
@@ -56,6 +55,7 @@
warn 'amd will not load without arguments'
return 1
fi
+ rc_flags=${rc_flags}
;;
*)
rc_flags=-p ${rc_flags} /var/run/amd.pid 2 /dev/null \
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rcNG automonter(amd)
On Sat, 07 Jun 2003 15:48:47 +0300 Danny Braniss [EMAIL PROTECTED] wrote: context I have a problem with /etc/rc.d/amd, because of the line command_args= [amd] gets run in the background, ldconfig failes to cache libraries in /usr/local/lib (which is automounted :-) /context my point is that amd should not be backgrounded by default, it does so anyway once it managed to register with the portmapper and some other initialization You might want to get David's (CCed) input then: description: revision 1.127 date: 2002/03/12 01:04:35; author: obrien; state: Exp; lines: +3 -3 Background the startup of `Amd', it often blocks on startup. = Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
How to ask for help on this list (was Re: Reproducible hard freezeon 5.1-CURRENT)
On Fri, 6 Jun 2003 08:48:17 -0400 Robin P. Blanchard [EMAIL PROTECTED] wrote: Upon launching samba-2.2.8a (via ports) on the below system, the machine immediately hard freezes. I've included interesting portions of kernel config. Any suggestions how I can acquire more useful information ? [snip] #optionsWITNESS #optionsWITNESS_DDB #optionsWITNESS_SKIPSPIN #optionsINVARIANTS #optionsINVARIANT_SUPPORT #optionsDIAGNOSTIC [snip] #optionsSCHED_4BSD options SCHED_ULE This is not to pick on you in particular. There have been a lot of these lately and I just picked this one to reply to. None of this is new, these points have already been made elsewhere and people on this list should be familiar with them. But I'll go ahead and point them out anyway. If you experience a freeze, panic, or any other fatal problem please keep in mind the following things: 1. There is a reason SCHED_ULE is labeled 'experimental'. It means that this is a new feature that needs some more testing and deguggin. Don't be surprised if it panics your system, eats your homework, or causes your hair to fall out. If you insist on using it, then please properly label your email with such information, and at the very least try to determine if _not_ using it makes your problems go away. 2. Before you report a problem enable all the debugging options in your kernel configuration file. If you don't want to put up with the reduction in performance, then build two kernels from the same source: one without the debuging options and one with. When you hit a problem, boot into the kernel with the debugging options and try to reproduce the problem. Report any Lock Oreder Reversals (LORs) and other errors reported by the kernel. When you do report a problem like my box freezes it is essential that you at least have 'options DDB' in your kernel so you can attempt to enter the kernel debugger and get an idea of what's happening. If enabling the debugging options makes your problems go away, that is helpful information in and of itself, so report it. 3. There is an entry in The Handbook and the Articles that provide information on how to obtain debuging information from your kernel. Greg Lehey also has an article about that in the works (see archives). Please read these before you ask How can I get more debugging information. 4. Some problems, are caused by faulty hardware. The ports tree has some applications you can use to check your hardware (memtest86, etc). If you see random panics and/or freezes it may be a good idea to use some of these programs to check your hardware. Believe it or not, hardware does fail, so don't discount this possibility. 5. You can greatly increase the chance that your problem gets resolved if you provide good quality debugging information, and actually do some of the diagnosing yourself. Even a partial attempt at solving the problem is better than nothing. 6. Finally, please try to understand that this is a volunteer project. Few developers actually get paid to work on FreeBSD, and when they do it's usually for something specific that their employer needs. Most developers give up free time during the week to work on FreeBSD. So, it may not be possible to devote the time and energy you believe your problem deserves. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
I have committed some changes to libthr today. All but one of them were bug fixes, so I encourage everyone to update their source. On Wed, 28 May 2003 22:20:19 -0700 Lars Eggert [EMAIL PROTECTED] wrote: Mike Makonnen wrote: Most major locking work in libthr is finished. I believe it is stable enough now that it can be used for most applications[1]. I would appreciate it if people would try it out and report any bugs. I had been running with libc_r symlinked to libthr for a few days with no problems, and rebuilt some ports during that time. The machine (SMP) would sometimes freeze solid (no panic). I symlinked libc_r back to the original library, and from then on, starting gnomepanel and some other gnome pieces would fail due to errors about libthr. I couldn't find them in any log file right now, but I think I remember one was about getpwuid_r not being found. (The ports that caused problems were gnome 2.3 beta ports from the marcuscom CVS tree.) From what I understand, libthr should be a drop-in replacement for libc_r, so I was surprised to see this, but maybe I misunderstood? No, you're right. The ports must have been statically linked. I'll investigate. As for the lockups, libthr by itself should not be able to lockup your machine. I'll investigate when I get back access to the SMP machine. I'll try to get a dump of the exact error messages when I have access to the box again in a few days. Please. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, 29 May 2003 17:06:52 -0400 Mike Makonnen [EMAIL PROTECTED] wrote: From what I understand, libthr should be a drop-in replacement for libc_r, so I was surprised to see this, but maybe I misunderstood? No, you're right. The ports must have been statically linked. I'll ^^^ scratch that. That's obviously not possible if it's looking for them. Anyways, I'd appreciate it if you could suply those logs. investigate. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, 29 May 2003 18:28:26 -0400 James Tanis [EMAIL PROTECTED] wrote: On Thu, 29 May 2003 17:39:18 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: It has been committed. Build rtld with WITH_LIBMAP defined and then setup a libmap.conf. -- Alright, I compiled and installed libthr, built rtld WITH_LIBMAP, and created the libmap.conf. I am using the example from the man page to have all programs use the libthr library. As far as I can tell my system is running perfectly fine, but there's nothing particularly special about my setup. Glad to hear it. Is there a way to find out for sure that the programs are now using libthr? As far as I can tell they should be, but I'd like to have a definitive answer. try: fstat -m /usr/lib/libthr.so.1 This should show you any running applications that have it loaded. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libthr vs ports/net/linuxigd
On Fri, 30 May 2003 15:10:37 +0800 leafy [EMAIL PROTECTED] wrote: Using libthr for upnpd produces following backtrace when starting up Are you using latest sources from about 17:00 EST 3/5/29? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Wed, 28 May 2003 21:57:35 -0500 Glenn Johnson [EMAIL PROTECTED] wrote: It seems to be working fine on a UP machine but it locks up my SMP machine just trying to load a gnome session. It leaves an image on the screen but the keyboard and mouse stop responding and I can not ssh into the box. Please try the attached patch and let me know how it works. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve Index: lib/libthr/thread/thr_create.c === RCS file: /home/ncvs/src/lib/libthr/thread/thr_create.c,v retrieving revision 1.9 diff -u -r1.9 thr_create.c --- lib/libthr/thread/thr_create.c 26 May 2003 00:37:07 - 1.9 +++ lib/libthr/thread/thr_create.c 29 May 2003 03:58:47 - @@ -171,7 +171,6 @@ new_thread-uniqueid = next_uniqueid++; THREAD_LIST_LOCK; - _thread_critical_enter(new_thread); /* * Check if the garbage collector thread @@ -202,8 +201,6 @@ /* Return a pointer to the thread structure: */ (*thread) = new_thread; - - _thread_critical_exit(new_thread); /* * Start a garbage collector thread ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Libthr stable enough for testing
On Thu, 29 May 2003 00:35:32 -0500 Dan Nelson [EMAIL PROTECTED] wrote: The real problem is in the kernel, though. A userland non-root process should not be able to hard lock the system. One of the threads people will probably have to get an SMP machine to be able to debug it. Upon first reading it I had assumed he meant gnome locked up. Can you confirm this Glenn? Is the machine itself locked solid (no ping, no ssh, not vtys, etc)? However, even if that is the case a bug in the kernel does not preclude a bug in libthr. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - The Power To Serve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
resource limits Giant patch
The following patches at http://people.freebsd.org/~mtm remove process resource limits out from under Giant. I have been bouncing them off jhb for a while now, and I think they are ready. I would appreciate a review/testing There are 4 incremental patches for your reviewing pleasure :-) infrastructure.diff - The necessary infrastructure to do the locking users.diff - Modify consumers of resource limits to use the locks giant.diff - actually remove Giant from (most of) those areas regen.diff - Regenerated files, if you don't care to regenerate your own The basic implementation: Each plimit now has an associated mutex. To read an individual limit it is sufficient that the proc lock is held. To modify a limit or in situations where you need a consitent view of a particular limit(s) both the proc lock and the plimit locks are held. Three new functions can be use to get limits: lim_cur(), lim_max(), and lim_rlimit(), that can be used to obtain the current limit, the hard limit, and the entire rlimit structure, respectively. A limit_lock has been defined to protect the following three globals: maxfiles, maxfilesperproc, and maxprocperuid They each now have their own sysctl proc that grabs the limit_lock in order to write them. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: resource limits Giant patch
err http://people.freebsd.org/~mtm/limits ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Removing Sendmail
On Thu, 03 Apr 2003 17:08:46 -0500 (EST) John Baldwin [EMAIL PROTECTED] wrote: On 03-Apr-2003 Dr Daniel Flickinger wrote: Secondly, I add the following to /etc/rc.conf: mta_start_script= # 2917: block their startup stealth attack sendmail_enable=NO sendmail_outbound_enable=NO sendmail_msp_queue_enable=NO sendmail_submit_enable=NO sendmail_enable=NONE should be all you need for rc.conf. Note NONE rather than NO. This is deprecated. It's a non-standard option that complicates rc.conf handling. Cheers -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_add segfault
On Wed, 19 Mar 2003 16:19:59 +0100 Joris Vandalon [EMAIL PROTECTED] wrote: Hi there, it seemd that pkg_add coredumps while doing pkg_add -r $package pkg_add $package seems work ok. anyone else experiencing the same problem? -example- [EMAIL PROTECTED] strace]# pkg_add -r lftp Segmentation fault (core dumped) [EMAIL PROTECTED] strace]# Use rev. 1.85 of /src/lib/libfetch/ftp.c -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pkg_add segfault
Here's a patch. Des, is this ok with you? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 Index: lib/libfetch/ftp.c === RCS file: /home/ncvs/src/lib/libfetch/ftp.c,v retrieving revision 1.86 diff -u -r1.86 ftp.c --- lib/libfetch/ftp.c 11 Mar 2003 08:20:58 - 1.86 +++ lib/libfetch/ftp.c 19 Mar 2003 17:24:20 - @@ -894,7 +894,7 @@ struct url *purl; char *p; - if (strchr(flags, 'd') != NULL) + if (flags != NULL strchr(flags, 'd') != NULL) return (NULL); if (((p = getenv(FTP_PROXY)) || (p = getenv(ftp_proxy)) || (p = getenv(HTTP_PROXY)) || (p = getenv(http_proxy))) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Startup scripts stop in middle of startup
On Wed, 12 Mar 2003 20:55:26 +0100 Aleksander Rozman - Andy [EMAIL PROTECTED] wrote: Did someone encounter the same problem? Is it possible to exactly determine which script is problem (script debuging os something)? put: rc_debug=yes in rc.conf -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FBSD 5.0 diskless environment does not work!
On Wed, 12 Mar 2003 19:56:47 +0100 (CET) Hartmann, O. [EMAIL PROTECTED] wrote: I nice feature would be to have some 'knob' switching on/off debugging, maybe this is possible or already realized in the shell? How to do the verbosity task? rc_debug=yes -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
signals still broken ?
# uname -a
FreeBSD kokeb.ambesa.net 5.0-CURRENT FreeBSD 5.0-CURRENT #8: Tue Feb 25 16:45:54
EST 2003
[EMAIL PROTECTED]:/daemon/build/current/obj/daemon/build/current/src/sys/QUARK i386
The following program is stuck in pause(3) forever. I have reproduced the bug in
5.0-RELEASE, but 4.7-STABLE behaves as expected: the child resumes upon
receiving SIGCONT.
#include err.h
#include signal.h
#include sys/time.h
#include sys/resource.h
static void
cont_handler()
{ ; }
int main()
{
int child, status;
if (signal(SIGCONT, cont_handler) == SIG_ERR)
err(1, signal());
if ((child = fork()) == 0) {
pause();
exit(0);
} else if (child == -1)
err(1, fork());
printf(sleeping 3s\n);
sleep(3);
if (kill(child, SIGCONT) == -1)
err(1, kill());
printf(waiting\n);
if ((child = wait(status)) == -1)
err(1, wait());
printf(done\n);
return (0);
}
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern kern_lock.c
jeff2003/02/16 02:39:49 PST Modified files: sys/kern kern_lock.c Log: - Add a WITNESS_SLEEP() for the appropriate cases in lockmgr(). Revision ChangesPath 1.64 +7 -0 src/sys/kern/kern_lock.c I now get the following: rebka# /daemon/build/current/rebka/src/sys/kern/kern_lock.c:239: could sleep with buf queue lock locked from /daemon/build/current/rebka/src/sys/kern/vfs_bio.c:2143 Debugger(witness_sleep) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db tr Debugger(c04a73dc,c04e005e,ef,c04e4d42,c04e769b) at Debugger+0x54 witness_sleep(1,c172c708,c04e005e,ef,c09f11e0) at witness_sleep+0x123 lockmgr(c172c7cc,10001,c172c708,c09f11e0,12) at lockmgr+0x71 vop_sharedlock(c5bfdc98,0,c04e95be,35c,c02efcf1) at vop_sharedlock+0x7d vn_lock(c172c708,12,c09f11e0,85f,c05b1d00) at vn_lock+0xeb flushbufqueues(c05b1d00,0,c04e765b,11e,64) at flushbufqueues+0xfb buf_daemon(0,c5bfdd48,c04df6c2,365,0) at buf_daemon+0xd5 fork_exit(c033e2e0,0,c5bfdd48) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc5bfdd7c, ebp = 0 --- -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NFS server vs YO
There are several things we need: 1. The contents of: /etc/exports /etc/fstab /etc/rc.conf 2. The output of the following commands: rpcinfo -p hostname showmount -e hostname 3. Make sure you are mounting them as the root user Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MSDOSFS wastes 256k when nothing is mounted!
On Mon, 10 Feb 2003 13:31:48 +1100 Tim Robbins [EMAIL PROTECTED] wrote: hashinit() can sleep, and I don't think it's safe to sleep here (msdosfs_hashget() and msdosfs_hashins()) with dehash_mtx and sometimes a vnode lock held. Doh! I should have noticed that. It might be better to initialise the table the first time an msdosfs filesystem is mounted. Sounds reasonable enough. So, maybe allocate it in msdosfs_mount or mountmsdosfs and deallocate it in msdosfs_unmount? If there isn't an easy way to tell if you're on the last mounted msdos filesystem, it might be better to just leave the deallocation in msdosfs_uninit. Is that basically what you're saying? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MSDOSFS wastes 256k when nothing is mounted!
On Mon, 10 Feb 2003 13:31:48 +1100 Tim Robbins [EMAIL PROTECTED] wrote: It might be better to initialise the table the first time an msdosfs filesystem is mounted. This implies that the existence of the hash table be revealed outside the module. Is this a layering violation? None of the _vfsops functions (except for init/uninit) can currently see the hash table, and of the ones that deal with denodes, none of them uses it directly. We can keep knowledge of the hashtablein module if we do the initialization in deget(), before the vnode lock. This seems like a better(if a little hackish) option to me, but this is the first time I've dealt with the filesystem so please let me know if I have the wrong idea. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: MSDOSFS wastes 256k when nothing is mounted!
How about the attached?
It's only partially tested since it seems I can't mount any msdos floppies (both
on this _and_ my previous kernel).
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
Index: sys/fs/msdosfs/msdosfs_denode.c
===
RCS file: /home/ncvs/src/sys/fs/msdosfs/msdosfs_denode.c,v
retrieving revision 1.67
diff -u -r1.67 msdosfs_denode.c
--- sys/fs/msdosfs/msdosfs_denode.c 21 Jan 2003 08:55:46 - 1.67
+++ sys/fs/msdosfs/msdosfs_denode.c 9 Feb 2003 22:14:41 -
@@ -73,6 +73,12 @@
static u_long dehash; /* size of hash table - 1 */
#defineDEHASH(dev, dcl, doff) (dehashtbl[(minor(dev) + (dcl) + (doff) /
\ sizeof(struct direntry)) dehash])
+#define DEHASH_INIT do {\
+ if (dehashtbl == NULL) {\
+ dehashtbl = hashinit(desiredvnodes/2, M_MSDOSFSMNT, dehash);\
+ KASSERT(dehashtbl != NULL, msdosfs dehashtbl == NULL);\
+ }\
+ } while (0)
static struct mtx dehash_mtx;
union _qcvt {
@@ -102,8 +108,8 @@
msdosfs_init(vfsp)
struct vfsconf *vfsp;
{
- dehashtbl = hashinit(desiredvnodes/2, M_MSDOSFSMNT, dehash);
mtx_init(dehash_mtx, msdosfs dehash, NULL, MTX_DEF);
+ dehashtbl = NULL;
return (0);
}
@@ -112,8 +118,10 @@
struct vfsconf *vfsp;
{
- if (dehashtbl)
+ if (dehashtbl) {
free(dehashtbl, M_MSDOSFSMNT);
+ dehashtbl = NULL;
+ }
mtx_destroy(dehash_mtx);
return (0);
}
@@ -130,6 +138,7 @@
loop:
mtx_lock(dehash_mtx);
+ DEHASH_INIT;
for (dep = DEHASH(dev, dirclust, diroff); dep; dep = dep-de_next) {
if (dirclust == dep-de_dirclust
diroff == dep-de_diroffset
@@ -154,6 +163,7 @@
struct denode **depp, *deq;
mtx_lock(dehash_mtx);
+ DEHASH_INIT;
depp = DEHASH(dep-de_dev, dep-de_dirclust, dep-de_diroffset);
deq = *depp;
if (deq)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: tmpfile breakage on setuid executables
The original poster was right. The following patch should fix it. I'll check it in as soon as my test cycle is over. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 Index: lib/libc/stdio/tmpfile.c === RCS file: /home/ncvs/src/lib/libc/stdio/tmpfile.c,v retrieving revision 1.8 diff -u -r1.8 tmpfile.c --- lib/libc/stdio/tmpfile.c13 Oct 2002 11:22:16 - 1.8 +++ lib/libc/stdio/tmpfile.c5 Feb 2003 23:37:28 - @@ -61,6 +61,7 @@ char *buf; const char *tmpdir; + tmpdir = NULL; if (issetugid() == 0) tmpdir = getenv(TMPDIR); if (tmpdir == NULL) msg51851/pgp0.pgp Description: PGP signature
Re: Seat-belt for source upgrades from stable to current
On Thu, 30 Jan 2003 20:05:06 -0800 David Schultz [EMAIL PROTECTED] wrote: That's a great answer...to a different question. ;-) Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on the repository remotely, so you don't need to have the files checked out localy. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg51322/pgp0.pgp Description: PGP signature
Re: rcconf.sh error
Fixed. Thanks! -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg50907/pgp0.pgp Description: PGP signature
Re: help: can't boot 5.0 diskless
Do you have device.hints in /boot of your diskless tree? -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg50827/pgp0.pgp Description: PGP signature
Re: pw
Attached is Terry's patch modified to include $ in group names as well. I have
tested it. Both adduser(8) and rmuser(8) work as expected. Please give -audit a
chance to object and then commit it. Also, please close PR: bin/46890 when you
do.
We should have had this a long time ago. If -audit doesn't object I say go for
it!
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
Index: usr.sbin/pw/pw.h
===
RCS file: /home/ncvs/src/usr.sbin/pw/pw.h,v
retrieving revision 1.13
diff -u -r1.13 pw.h
--- usr.sbin/pw/pw.h5 Jul 2001 08:01:15 - 1.13
+++ usr.sbin/pw/pw.h24 Jan 2003 03:16:41 -
@@ -62,6 +62,13 @@
W_NUM
};
+enum _checktype
+{
+ PWC_DEFAULT,
+ PWC_GECOS,
+ PWC_LOGIN
+};
+
struct carg
{
int ch;
@@ -105,7 +112,7 @@
int pw_user(struct userconf * cnf, int mode, struct cargs * _args);
int pw_group(struct userconf * cnf, int mode, struct cargs * _args);
-char*pw_checkname(u_char *name, int gecos);
+char*pw_checkname(u_char *name, enum _checktype checktype);
int addpwent(struct passwd * pwd);
int delpwent(struct passwd * pwd);
Index: usr.sbin/pw/pw_group.c
===
RCS file: /home/ncvs/src/usr.sbin/pw/pw_group.c,v
retrieving revision 1.13
diff -u -r1.13 pw_group.c
--- usr.sbin/pw/pw_group.c 22 Jun 2000 16:48:41 - 1.13
+++ usr.sbin/pw/pw_group.c 24 Jan 2003 03:59:07 -
@@ -135,7 +135,7 @@
grp-gr_gid = (gid_t) atoi(a_gid-val);
if ((arg = getarg(args, 'l')) != NULL)
- grp-gr_name = pw_checkname((u_char *)arg-val, 0);
+ grp-gr_name = pw_checkname((u_char *)arg-val, PWC_LOGIN);
} else {
if (a_name == NULL) /* Required */
errx(EX_DATAERR, group name required);
@@ -145,7 +145,7 @@
extendarray(members, grmembers, 200);
members[0] = NULL;
grp = fakegroup;
- grp-gr_name = pw_checkname((u_char *)a_name-val, 0);
+ grp-gr_name = pw_checkname((u_char *)a_name-val, PWC_LOGIN);
grp-gr_passwd = *;
grp-gr_gid = gr_gidpolicy(cnf, args);
grp-gr_mem = members;
Index: usr.sbin/pw/pw_user.c
===
RCS file: /home/ncvs/src/usr.sbin/pw/pw_user.c,v
retrieving revision 1.51
diff -u -r1.51 pw_user.c
--- usr.sbin/pw/pw_user.c 24 Jun 2002 11:33:17 - 1.51
+++ usr.sbin/pw/pw_user.c 24 Jan 2003 03:48:44 -
@@ -231,7 +231,7 @@
}
}
if ((arg = getarg(args, 'L')) != NULL)
- cnf-default_class = pw_checkname((u_char *)arg-val, 0);
+ cnf-default_class = pw_checkname((u_char *)arg-val, PWC_DEFAULT);
if ((arg = getarg(args, 'G')) != NULL arg-val) {
int i = 0;
@@ -293,7 +293,7 @@
}
if ((a_name = getarg(args, 'n')) != NULL)
- pwd = GETPWNAM(pw_checkname((u_char *)a_name-val, 0));
+ pwd = GETPWNAM(pw_checkname((u_char *)a_name-val, PWC_LOGIN));
a_uid = getarg(args, 'u');
if (a_uid == NULL) {
@@ -455,7 +455,7 @@
if ((arg = getarg(args, 'l')) != NULL) {
if (strcmp(pwd-pw_name, root) == 0)
errx(EX_DATAERR, can't rename `root' account);
- pwd-pw_name = pw_checkname((u_char *)arg-val, 0);
+ pwd-pw_name = pw_checkname((u_char *)arg-val, PWC_LOGIN);
edited = 1;
}
@@ -595,7 +595,7 @@
* Shared add/edit code
*/
if ((arg = getarg(args, 'c')) != NULL) {
- char*gecos = pw_checkname((u_char *)arg-val, 1);
+ char*gecos = pw_checkname((u_char *)arg-val, PWC_GECOS);
if (strcmp(pwd-pw_gecos, gecos) != 0) {
pwd-pw_gecos = gecos;
edited = 1;
@@ -1192,10 +1192,26 @@
}
char*
-pw_checkname(u_char *name, int gecos)
+pw_checkname(u_char *name, enum _checktype checktype)
{
int l = 0;
- char const *notch = gecos ? :!@ : ,\t:+#%$^()!@~*?=|\\/\;
+ char const *notch;
+ int gecos = (checktype == PWC_GECOS);
+
+ switch (checktype) {
+ case PWC_GECOS:
+ notch = :!@;
+ break;
+
+ case PWC_LOGIN:
+ notch = ,\t:+#%^()!@~*?=|\\/\;
+ break;
+
+ case PWC_DEFAULT:
+ default:
+ notch = ,\t:+#%$^()!@~*?=|\\/\;
+ break;
+ }
while (name[l]) {
if (strchr(notch, name[l]) != NULL || name
Re: Performance problems with 5.0-RELEASE
Just a me too. I have a procmail filter that uses spamassissin to filter all my incomming mail (downloaded with fetchmail). I have noticed that if I get a lot of messages at once, interactive response degrades tremendously with a lot of perl processes stuck in either swread or pfault state. The system becomes completely unuseable. I keep telling myself I'll track it down one of these days, but... -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg50846/pgp0.pgp Description: PGP signature
Re: adduser(8) in 5.0-R
Committed. Thanks! -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg50640/pgp0.pgp Description: PGP signature
Re: adduser(8) in 5.0-R
I have cc'ed bmah, because I think it should be in the errata. On Tue, 21 Jan 2003 14:36:11 - Robin Breathe [EMAIL PROTECTED] wrote: Hmmm, it might be worth mentioning, since md5 is the default passwd hash, it's not infeasible that someone might choose `rm -rf /`, or similar, as their passwd... Which would have somewhat unpleasant results since adduser runs as root. Well, you would have to be root to run it in the first place, but I deserve the pointy hat none the less. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg50656/pgp0.pgp Description: PGP signature
Re: aout support not working on todays -current
I believe aout support was removed from the kernel some months ago. It was going to be made a port, but I don't know if that has happened yet. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg50658/pgp0.pgp Description: PGP signature
Re: aout support not working on todays -current
On Tue, 21 Jan 2003 09:47:20 -0800 Kris Kennaway [EMAIL PROTECTED] wrote: You're confusing two issues. To run a.out binaries you just need COMPAT_AOUT. To generate new a.out binaries you need an a.out toolchain, which is what someone was going to make a port for, but never did. Ahh, I see. Thanks for clearing that up. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg50660/pgp0.pgp Description: PGP signature
Re: Adduser difference between 5.0 and earlier versions
The new adduser was not intended to be a feature-for-feature replacement of the perl version. This version allows you to enter multiple accounts from a file, so providing this type of functionality wasn't particularly important on my list of things to do. But, as long as someonle else is submitting the patch, that's fine with me :-) I have one request though: All the other yes/no prompts will repeat the prompt if they get anything other than what they expect, can you redo the patch so that it repeats the prompt if it gets no input or anything other than yes/no? For consistency's sake. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg50684/pgp0.pgp Description: PGP signature
Re: rcng script bugs
[ cc'ed imp@ since the second one concerns changes he recently made ]
On Sat, Dec 14, 2002 at 02:24:12PM -0800, Galen Sampson wrote:
17c17
pidfile=/var/run/${name}.pid
---
pidfile=/var/run/${name}/pid
in order to match the default named.conf file.
Yes, definitely a bug. I had changed my named.conf so I didn't notice
this. However, I think your solution is just as broken as the current
code. While it would work if the user doesn't change the default
pid path, it wouldn't work for people who do change it (like me).
I think the way to solve it is with a named_pidfile variable in
defaults/rc.conf that defaults to /var/run/named/pid. What are people's
thoughts on this? Secondly, the change would have to go into the
'FreeBSD' case-clause in order not to mess up the NetBSD case.
/etc/rc.d/network1:
When using a diskless configuration this file took the interface offline,
preventing the machine from booting. I noticed that a change has been added to
check if an interface is up and skip configuring it if it is. Instead of using
grep it is possible to use ifconfig's -d option (see man page) to only list
interfaces marked as down. This is my change for /etc/rc.d/network1
140c140
network_interfaces=`ifconfig -l -d`
---
network_interfaces=`ifconfig -l`
148a149,153
if ifconfig ${ifn} | grep -s UP, /dev/null 21; then
# Interface is already up, so ignore it.
continue;
fi
Warner,
He's working off the first set of changes you made but it seems
that in the diskless case you may have to reconfigure more
than just lo0.
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
msg48762/pgp0.pgp
Description: PGP signature
Re: rcng script bugs
[ ok, really cc him this time]
On Sun, Dec 15, 2002 at 01:02:51AM -0800, Mike Makonnen wrote:
[ cc'ed imp@ since the second one concerns changes he recently made ]
On Sat, Dec 14, 2002 at 02:24:12PM -0800, Galen Sampson wrote:
17c17
pidfile=/var/run/${name}.pid
---
pidfile=/var/run/${name}/pid
in order to match the default named.conf file.
Yes, definitely a bug. I had changed my named.conf so I didn't notice
this. However, I think your solution is just as broken as the current
code. While it would work if the user doesn't change the default
pid path, it wouldn't work for people who do change it (like me).
I think the way to solve it is with a named_pidfile variable in
defaults/rc.conf that defaults to /var/run/named/pid. What are people's
thoughts on this? Secondly, the change would have to go into the
'FreeBSD' case-clause in order not to mess up the NetBSD case.
/etc/rc.d/network1:
When using a diskless configuration this file took the interface offline,
preventing the machine from booting. I noticed that a change has been added to
check if an interface is up and skip configuring it if it is. Instead of using
grep it is possible to use ifconfig's -d option (see man page) to only list
interfaces marked as down. This is my change for /etc/rc.d/network1
140c140
network_interfaces=`ifconfig -l -d`
---
network_interfaces=`ifconfig -l`
148a149,153
if ifconfig ${ifn} | grep -s UP, /dev/null 21; then
# Interface is already up, so ignore it.
continue;
fi
Warner,
He's working off the first set of changes you made but it seems
that in the diskless case you may have to reconfigure more
than just lo0.
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
msg48763/pgp0.pgp
Description: PGP signature
Re: RC NG, ntp and routed
On Thu, Dec 12, 2002 at 08:09:24AM -0200, Daniel C. Sobral wrote: I mean that routed is _one_ routing daemon, one that supports the old, would someone please shot it in the head to give it peace, RIP. If you happen to run a modern routing protocol... hell, if you happen to run a middle-aged routing protocol, you'll be using something else. And, since you do not seem to be aware of it, Zebra, for one, is run as... router_enable=YES router=/usr/local/sbin/zebractl router_flags=start If you are using a daemon essential to network connectivity in /usr/local and at the same time have it (/usr/local) mounted remotely, then you haven't thought things through properly. Listen, I think we're talking past each other here. I _am_ in favour of adding routing to NETWORKING (look at an earlier email in the thread). My only argument is that if an admin chooses to use a daemon from ports then he should be bright enough to include it in a local filesystem. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48610/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Wed, Dec 11, 2002 at 08:17:50AM +0100, Brad Knowles wrote:
I believe that DISKS should be split into DISKS_LOCAL and
DISKS_NETWORK. This allows us to get NETWORKING going after
DISKS_LOCAL and before DISKS_NETWORK.
Don't over-engineer it. This is the order it is done in now.
The barier scripts are supposed to be major milestones. With your
suggestion DISKS_{LOCAL,NETWORK) would each have _only_ one
dependency (mountcritlocal and mountcritremote, respectively), so
what would be the point then?
We may also want to split
NETWORKING into INTERFACES and ROUTING (and higher level networking),
in case there is anything that we might need to slide in-between. We
might even need to split NETWORKING into three parts.
I think the current barrier scripts plus Gordon's suggestion to
include routing in NETWORKING works ok. However, improvements
to /etc/rc.d/network1 to allow bringing up/down the interfaces
individually would be nice.
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
msg48512/pgp0.pgp
Description: PGP signature
Re: RC NG, ntp and routed
On Tue, Dec 10, 2002 at 10:33:48PM -0800, Gordon Tetlow wrote: That sounds like a good idea. According to current NETWORKING requirements it just means the network interfaces are brought up, but routing seems to be a reasonable requirement as well. I can't think of a good reason why it would not be a good idea. Maybe we could move the other routing daemons there as well (from /usr/sbin)? Well, there in lies the chicken and the egg problem (and why I've been cursing rcng recently). /usr is mounted after networking so all the things that implictly require /usr must be run after networking is setup (but what about things like route6d that is in /usr/sbin?) You misunderstood. I meant let's move the routing daemons from /usr/sbin to /sbin. I think if we have routed there we might as well have the others there. Actually we only need to move route6d to /sbin. I can't think of a reason you would need multicast routing before the whole system was up. I think we can live with and additional 42k on /. IMO rc.d should have the following major catagories: DISKS FILESYSTEMS NETWORKING DAEMON LOGIN I don't see the need for FILESYSTEMS. As it is we only have two scripts mountcritlocal and mountcritremote. And since network mounted filesystems are quite common any script that needs FILESYSTEM is simply going to have to wait until NETWORKING is up. There's no way we can get around that. NETWORKING, DAEMON, and LOGIN exist in the NetBSD framework. NetBSD also describes a SERVERS catagory that I don't really understand the need for. Basicaly it's for daemons that you need running as early as possible, like syslogd. Other services are going to need them, but you can't really fit them in the other categories. I'd like to think about really sitting down and overhauling the rc.d system after 5.0 is branched. I think that it's reasonable to say we should not try to be compatible with NetBSD except for keeping a common rc.subr and major initialization catagories (basically anything that is in all caps). Does anyone have a problem with dyking out the NetBSD specific portions after 5.0? I was quite a ways through porting our scripts when David insisted that they be compatible with NetBSD in order to make it into the tree. It took quite a bit more work to restart almost from the beginning and redo them. And I would hate to see that work go to waste. So, I'm not an impartial party here and won't say anymore about it except to say that I think being in sync with NetBSD is a worthwhile and doable goal if we (both projects) make a firm commitment to do it. This means that we wouldn't be slavishly accepting NetBSD code, but that the projects would work the differences out so that the only differences left would be because of architectural differences between the two OSes. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48516/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Wed, Dec 11, 2002 at 09:16:27AM -0200, Daniel C. Sobral wrote: Mm. How about ntpd running in multicast mode? :-) Hah! I knew I should have checked that before I opened my mouth. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48525/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Wed, Dec 11, 2002 at 03:28:12PM -0200, Daniel C. Sobral wrote: [root@piratinga root]# ls -l /usr/local/sbin/ospfd -r-xr-xr-x 1 root wheel 471392 Dec 1 00:58 /usr/local/sbin/ospfd* [root@piratinga root]# ls -l /usr/local/sbin/bgpd -r-xr-xr-x 1 root wheel 691952 Dec 1 00:58 /usr/local/sbin/bgpd* Who said anything about moving ports into /? I meant the routing daemons in /usr/sbin. But as Gordon pointed out that's still quite a bit of disk space. And all this because... people don't want to break fs mounting in local and remote? I saw break it, and have routing run after local. If your /usr is remote, then either you'll copy routed (or whatever you use) to a local disk, or you won't be using it. People, let's face it. There *ARE* things you want to be run *after* local fs mount and *before* remote fs mount. And we are hurting ourselves in a few places just because we haven't admitted to it. I don't understand what you are saying. Why would we have routing run after local filesystems are mounted but before the network is up? btw, someone mentioned a freebsd-rc list, but I found no such list. Mispelling? Not freebsd.org list? Delusions? Yahoo! . Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48580/pgp0.pgp Description: PGP signature
Re: RCng -- docs and whatnot?
man 8 rc man 8 rc.subr -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48581/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Wed, Dec 11, 2002 at 10:11:18PM -0800, Doug Barton wrote: On Wed, 11 Dec 2002, Mike Makonnen wrote: I don't understand what you are saying. Why would we have routing run after local filesystems are mounted but before the network is up? What if /usr/local is an nfs-mounted partition (like it is on my systems, both at home and work)? I still don't see how having the routing daemon start before the network interfaces come up helps you. The correct order seems to me: local filesystem, network, routing, remote filesystem. Am I missing something here? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48584/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Tue, Dec 10, 2002 at 03:01:24PM -0200, Daniel C. Sobral wrote: On another note, I thought the patch a bit excessive. Here, I just added BEFORE: ntpd to routed. OTOH, it seems that patch did a bit more. It's not excessive. It's the correct solution. Your solution solves your specific problem but it's not the right way to go about solving the problem. It's kind of hard to explain, you have to work with it for a while to get the hang of it. For some things it might be easier _and_ right to say this must come before that. In this case; however, ntpd requires that routing be available as a prerequisite, but there's no real relationship that exists between the two that necessitates routed having to know about ntpd. If we were to follow your example to its logical conclusion the BEFORE line for the routing daemons would have to include _every_ daemon that requires network availability. I think in this case it would be more correct to have the network daemons REQUIRE the routing daemons. Does that make sense? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48487/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Tue, Dec 10, 2002 at 08:22:08AM -0800, Gordon Tetlow wrote: I think keeping our boot scripts the same is kind of a pipe dream. I think we should keep our rc.subr the same, but for individual scripts, I think we should just go our own way. I can see how keeping every we possibly can the same can make things easier and I'm in favor of it. What I don't like is this stradling the middle business. It's all or nothing. We can't keep some things in sync and others not because the parts make up the whole. If we change some parts that's going to affect other parts, which in turn is going to affect the whole. This is really frustrating sometimes. So, in short: Please let's pick a path and follow it whole-heartedly! Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48488/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Tue, Dec 10, 2002 at 04:23:18PM -0800, Gordon Tetlow wrote: Ideally, ntpd should require NETWORKING and that should solve all problems. The real problem is that routed is included with DAEMON, not NETWORKING. I think that's the real problem and judging that routed is in /sbin, we could probably move it there without a problem. That sounds like a good idea. According to current NETWORKING requirements it just means the network interfaces are brought up, but routing seems to be a reasonable requirement as well. I can't think of a good reason why it would not be a good idea. Maybe we could move the other routing daemons there as well (from /usr/sbin)? Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48503/pgp0.pgp Description: PGP signature
Re: Confused by mpd and ipnat
On Tue, Dec 10, 2002 at 12:06:21AM +0800, leafy wrote: map ng0 192.168.0.0/24 - 0/32 When I reboot, this line (along with ipnat stuff) got executed before mpd fiinishes PPPoE negotiation, and ipnat -l shows that the ng0 ip was 0.0.0.0/32. Is there anyway I can ensure that ipnat -f /etc/ipnat.rules get executed only after mpd has obtained proper ip settings? Does mpd install a startup script in /usr/local/etc/rc.d ? Does it get started in the background? If it's script is in /usr/local/etc/rc.d then it gets run by the /etc/rc.d/local script which runs after /etc/rc.d/ipnat. In this case you can simply re-apply the rules after the negotiation is completed: /etc/rc.d/ipnat reload Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48442/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
[ cc'd some more people on this ] On Mon, Dec 09, 2002 at 11:23:58AM -0200, Daniel C. Sobral wrote: I suggest that routed be specified as being BEFORE ntpd. In the absence of a route to the specified servers, ntpd has the annoying behavior of chosing the address of lo0 as the source address for ntp requests, resulting in all sorts of problems. Yeah, makes sense. It also worked like that (correctly, that is) in rc.network. I do see one contraindication to this behavior. Most routing protocols also react badly to time changes. Egg and chicken problem, but, personally, and running OSPF, which is one of those protocols that react badly to time changes, I find it preferably to run the router first. After all, having ntpd using 127.0.0.1 as source is useless to me. The following patch should solve your problem. However, it's only a partial solution. It fixes the case for ntpd and ntpdate but not for other network daemons like rpcbind, which still get started _before_ the routing daemons. I haven't included patches for those because sorting out the dependencies is going to be a bit more involved. I'll have it done when I get a chance later this week. (A consequence of this is going to be that we will be moving *away* from NetBSD in the dependency ordering, but we can sort that out with them later). Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 Index: etc/rc.d/ntpd === RCS file: /home/ncvs/src/etc/rc.d/ntpd,v retrieving revision 1.5 diff -u -r1.5 ntpd --- etc/rc.d/ntpd 2002/10/12 10:31:31 1.5 +++ etc/rc.d/ntpd 2002/12/10 02:09:05 @@ -5,7 +5,7 @@ # # PROVIDE: ntpd -# REQUIRE: DAEMON +# REQUIRE: DAEMON routed route6d mrouted mroute6d ntpdate # BEFORE: LOGIN # KEYWORD: FreeBSD NetBSD Index: etc/rc.d/ntpdate === RCS file: /home/ncvs/src/etc/rc.d/ntpdate,v retrieving revision 1.4 diff -u -r1.4 ntpdate --- etc/rc.d/ntpdate2002/10/12 10:31:31 1.4 +++ etc/rc.d/ntpdate2002/12/10 02:09:05 @@ -5,7 +5,8 @@ # # PROVIDE: ntpdate -# REQUIRE: NETWORKING syslogd +# REQUIRE: DAEMON routed route6d mrouted mroute6d +# BEFORE: LOGIN # KEYWORD: FreeBSD NetBSD . /etc/rc.subr Index: etc/rc.d/rpcbind === RCS file: /home/ncvs/src/etc/rc.d/rpcbind,v retrieving revision 1.6 diff -u -r1.6 rpcbind --- etc/rc.d/rpcbind2002/09/06 16:18:05 1.6 +++ etc/rc.d/rpcbind2002/12/10 02:09:05 @@ -5,7 +5,7 @@ # # PROVIDE: rpcbind -# REQUIRE: NETWORKING ntpdate syslogd named ppp +# REQUIRE: NETWORKING syslogd named ppp # KEYWORD: FreeBSD NetBSD . /etc/rc.subr msg48443/pgp0.pgp Description: PGP signature
Re: Confused by mpd and ipnat
On Tue, Dec 10, 2002 at 11:24:59AM +0800, leafy wrote: I finally got over this one. The problem is that mpd needs a very long time for PPPoE negotiation, thus if we run ipnat reload before it's settled, that will be totally useless. So I moved the mpd startup script to PREFIX/etc/rc.d/000.mpd.sh and the ipnat reload in zzz.ipnat_reload.sh and VIOLA! Putting them in the same script does not work, maybe this could be improved? How could this not work? Are you starting it in the background? Must be. I'm assuming that you don't want to run them serially because it would take too long to startup your system so you use some sort of mechanism (like the -background option to ppp(8)) to run it in the background. I would suggest that you do something like this: ( mpd -foreground; /etc/rc.d/ipnat reload ) ... unless it is not possible for some reason. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48446/pgp0.pgp Description: PGP signature
Re: The great perl script rewrite - progress report
On Mon, Dec 02, 2002 at 12:00:27AM -0500, Robert Watson wrote: Base system perl-based tools added to the TODO list. We need to deal with these ASAP. I have already submitted adduser/rmuser to Mark. http://www.identd.net/~mtm/adduser.tar.gz Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg47962/pgp0.pgp Description: PGP signature
Re: rc_ng breakage introduced with src/etc/rc.d/Makefile 1.5
On Wed, Nov 27, 2002 at 02:08:40AM +0300, Sergey Mokryshev wrote: Yes, I don't see these errors. But some scripts can change execution order without anchors like mountall For example, adding ldconfig dependancy directly into named brings this order: root@girvas-gw:/etc/rc.d# rcorder -k FreeBSD -s nostart * 2/dev/null ldconfig initdiskless initrandom dumpon vinum Isn't this wrong? I'm not in front of a -current box right now so I can't test it, but generally if you change the default order of the scripts you _may_ need to modify one or more BEFORE or REQUIRE lines. That's what they are there for after all. Cheers. -- Mike Makonnen [EMAIL PROTECTED] GPG Key-ID: 0xDBCC68B9 GPG-KEY: http://www.identd.net/~mtm/mtm.asc Key fingerprint = D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg47596/pgp0.pgp Description: PGP signature
Re: rc_ng breakage introduced with src/etc/rc.d/Makefile 1.5
On Thu, Nov 28, 2002 at 01:31:26AM +0300, Sergey Mokryshev wrote: [ snip ] ldconfig does not have proper anchor and is mistakenly ordered to run first (without any filesystems mounted (except R/O root) yet). This is a good example of why I didn't support the removal of the NetBSD scripts when it was done. However, I can also understand Gordon't point of view and why he removed them: namely, because of rc.d bloat, confusing users, and the implied suggestion that we support those scripts on our platform (correct me if I'm wrong Gordon). * So I'm complaining mostly about removing files without fixing dependencies in the remaining scripts * Probably the best solution is to backout rev 1.5 of src/etc/rc.d/Makefile. It was tested before 5.0-DP2 and it just works. The dependencies are fine for the default order. I don't think there was any implicit or explicit guarantee that if you changed the order things wouldn't break. For your particular situation I think the following will give the desired order: 1. Leave rc.d/named alone 2. Modify rc.d/ldconfig : # REQUIRE: SERVERS # BEFORE: named Cheers. -- Mike Makonnen [EMAIL PROTECTED] GPG Key-ID: 0xDBCC68B9 GPG-KEY: http://www.identd.net/~mtm/mtm.asc Key fingerprint = D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg47653/pgp0.pgp Description: PGP signature
Re: rc_ng breakage introduced with src/etc/rc.d/Makefile 1.5
These are benign. Those scripts are used by NetBSD only. You don't see the errors on boot because of a 2/dev/null in /etc/rc. Cheers. -- Mike Makonnen [EMAIL PROTECTED] GPG Key-ID: 0xDBCC68B9 GPG-KEY: http://www.identd.net/~mtm/mtm.asc Key fingerprint = D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg47550/pgp0.pgp Description: PGP signature
Re: cvs commit: src/etc rc.subr
On Fri, Nov 08, 2002 at 06:26:13PM -0800, Doug Barton wrote: I'm not sure I like this change actually... having the debug output go to syslog is very useful if you don't have a console on the system for whatever reason. I agree. It's also usefull when you're in an X session or other console messages have scrolled the output out of the buffer. Cheers, Mike. -- GPG Key: http://www.identd.net/~mtm/gpg.key pub 1024D/7D39509A 2002-10-08 Mike Makonnen [EMAIL PROTECTED] Key fingerprint = 5491 488A 0445 2DCC 777B 1F03 F3AB F9F8 7D39 509A msg46409/pgp0.pgp Description: PGP signature
Re: rc.d and sysctl.conf
On Wed, Oct 30, 2002 at 02:36:01PM -0800, Bill Fenner wrote: [ snip ] The update to the /etc/rc.d infrastructure keeps the ability to run twice, but does not actually run it twice. I started creating an /etc/rc.d/sysctl-last that would run /etc/rc.d/sysctl lastload, but realized that I didn't know how to say where the first/second call should go. To strictly follow /etc/rc.d, I could change the existing /etc/rc.d/sysctl to say BEFORE: serial and add BEFORE: securelevel to sysctl-last, but I'm not sure this is appropriate given the meta-checkpoints that we have. One of the hard things while I was doing the porting was deciding whether something in /etc/rc was there because it *must* run before the commands that were after it and after the commands that came before it. Since there haven't been any complaints in that regard I don't think the current order has broken anything. The general rule is to put something in REQUIRE and/or BEFORE only if it is necessary that some script be run before or after the current script. So, if the sysctls *must* be set before SERIAL, it should be in the BEFORE line. Otherwise, I would leave it as is and run `/etc/rc.d/sysctl lastload' in /etc/rc.d/securelevel just before rasing the securelevel (Please see the attached patch). (It also raises the question of if /etc/rc.d/securelevel actually runs at the right time. /etc/rc puts it almost at the absolute end, while rcorder sticks it somewhere in the middle -- number 67 of 102 on my system.) We wanted to keep the differences between our scripts and NetBSD's to a minimum. So, if it turns out we've broken something because of where rcorder puts the securelevel script, then we'll have to modify the BEFORE line of the affected script. Cheers, Mike -- GPG Key: http://www.identd.net/~mtm/gpg.key pub 1024D/7D39509A 2002-10-08 Mike Makonnen [EMAIL PROTECTED] Key fingerprint = 5491 488A 0445 2DCC 777B 1F03 F3AB F9F8 7D39 509A msg46410/pgp0.pgp Description: PGP signature
Re: rcNg messages
On Thu, 05 Sep 2002 13:17:04 +0200 (CEST)
Harti Brandt [EMAIL PROTECTED] wrote:
rcorder: requirement `ppp' in file `/etc/rc.d/rpcbind' has no providers.
rcorder: requirement `beforenetlkm' in file `/etc/rc.d/ipsec' has no
providers. rcorder: requirement `beforenetlkm' in file `/etc/rc.d/ipfilter'
has no providers. rcorder: requirement `altqd' in file
`/etc/rc.d/NETWORKING' has no providers. rcorder: requirement `dhclient' in
file `/etc/rc.d/NETWORKING' has no providers. rcorder: requirement `network'
in file `/etc/rc.d/NETWORKING' has no providers.
Well, gordon made a commit yesterday to prevent scripts not used by FreeBSD
from being installed. rcorder is complaining because some of those scripts are
in the REQUIRE line of the installed scripts. While your startup order may be
subtly different because of it, it's a benign error message (in this case).
You can redirect it to /dev/null with the following patch.
Cheers,
Mike Makonnen
Index: etc/rc
===
RCS file: /home/ncvs/src/etc/rc,v
retrieving revision 1.317
diff -u -r1.317 rc
--- etc/rc 15 Aug 2002 03:24:47 - 1.317
+++ etc/rc 5 Sep 2002 17:54:32 -
@@ -84,7 +84,7 @@
fi
os=`eval ${CMD_OSTYPE}`
- files=`rcorder -k ${os} -s nostart /etc/rc.d/*`
+ files=`rcorder 2/dev/null -k ${os} -s nostart /etc/rc.d/*`
for _rc_elem in ${files}; do
run_rc_script ${_rc_elem} ${_boot}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
why should buildworld touch stuff outside /usr/src ? (was Re:buildworld breakage)
On Fri, 16 Aug 2002 08:55:04 -0400 (EDT) Robert Watson [EMAIL PROTECTED] wrote: I ran into this also, and a bit of fiddling with a debugger was un-enlightening -- it was segfaulting on a write to __collate_substitute_table in parse.y. The pointer to the table didn't appear to be corrupted, and it should have been in writable memory. It also appeared to be properly aligned. I moved on to other stuff but was planning to submit a bug report if it persisted (and therefore wasn't a local nit of mine due to heavy local kernel mods). Ok I just updated to today's sources and it's gone. On the other hand I have another problem now. It seems buildworld touches stuff outside of /usr/src (specifically in /etc/mail). I noticed this behaviour some months ago but promptly forgot about it when I trashed my hard drive and had to rebuild my system. This is the first time since then (May/June) that I have tried running buildworld as a regular user. I would like to be able to continue doing everything short of install as a regular user. Is it really necessary to require root privs to buildworld? [ I've CCed gshapiro ] === usr.sbin/keyserv cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF-c /daemon/bui ld/current/src/usr.sbin/keyserv/keyserv.c cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF-c /daemon/bui ld/current/src/usr.sbin/keyserv/setkey.c cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF-c crypt_svc.c cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF-c /daemon/bui ld/current/src/usr.sbin/keyserv/crypt_server.c cc -O -pipe -DKEYSERV_RANDOM -DBROKEN_DES -I. -DOBJFORMAT_ELF -o keyserv ke yserv.o setkey.o crypt_svc.o crypt_server.o -lmp -lcrypto -lrpcsvc gzip -cn /daemon/build/current/src/usr.sbin/keyserv/keyserv.8 keyserv.8.gz === etc === etc/sendmail rm -f freebsd.cf (cd /daemon/build/current/src/etc/sendmail m4 -D_CF_DIR_=/daemon/build/curre nt/src/etc/sendmail/../../contrib/sendmail/cf/ /daemon/build/current/src/etc/s endmail/../../contrib/sendmail/cf/m4/cf.m4 freebsd.mc) freebsd.cf chmod 444 freebsd.cf rm -f /etc/mail/kokeb.ambesa.net.cf (cd /daemon/build/current/src/etc/sendmail m4 -D_CF_DIR_=/daemon/build/curre nt/src/etc/sendmail/../../contrib/sendmail/cf/ /daemon/build/current/src/etc/s endmail/../../contrib/sendmail/cf/m4/cf.m4 /etc/mail/kokeb.ambesa.net.mc) /etc /mail/kokeb.ambesa.net.cf cannot create /etc/mail/kokeb.ambesa.net.cf: permission denied *** Error code 2 Stop in /daemon/build/current/src/etc/sendmail. *** Error code 1 Stop in /daemon/build/current/src/etc. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. Cheers, Mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
buildworld breakage
I don't know if I'm the only one having this problem, but I haven't been able to make a complete buildworld for a couple of days now. The last time I upgraded was arround August 5. I have been getting a signal 11 consistently in the same spot. === secure/usr.sbin/sshd === share === share/colldef colldef -I /daemon/build/current/src/share/colldef -o bg_BG.CP1251.out /daemon/build/current/src/share/colldef/bg_BG.CP1251.src *** Signal 11 Stop in /daemon/build/current/src/share/colldef. *** Error code 1 Stop in /daemon/build/current/src/share. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. *** Error code 1 Stop in /daemon/build/current/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rcNG and dhcp
On Mon, 12 Aug 2002 12:40:20 +0400 Vladimir B. Grebenschikov [EMAIL PROTECTED] wrote: Hi There is patch to teach rcNG do not try dhcp on not-connected ethernet. simply put ifconfig_fxp0=dhcp-if-carrier into rc.conf It will be interested to somebody Theoretically there are another solution for problem - add new key to dhclient - check interface media before broadcasting. Yes, there is a simple solution: adjust the timeout in dhclient.conf. I will quote David Malone from PR conf/38559: I would have said that it would be a bug not to do DHCP if the interface has been configured for it and might upset people who want to be able to plug the network cable in at a more leasurely pace when they boot their laptops. It also means that dhclient won't be able to use a lease listed in its lease file, even if that lease is valid and the hub/switch/access point you're connected to happens to be temporally down or out of range. I'd suggest that you try reducing the timeouts if the long timeout isn't suitable for your setup. See the timeing options in dhclient.conf man page. Cheers, Mike. -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rcNG and dhcp
On Tue, 13 Aug 2002 20:36:39 +0400 Vladimir B. Grebenschikov [EMAIL PROTECTED] wrote: Yes, there is a simple solution: adjust the timeout in dhclient.conf. It is not solution - it is workaround - I do not wand any dhcp activity if I have no media (say in car) And dhclient in case of failure of detecting network address will install lask seen one, with last seen default gateway and I will get very long timeout while any of my apps will try to reach network instead of instant 'no route to host' Then, bring the interface down manually (it's even easier now that you can insert your own script in the rc boot process). I am not being flippant. Your suggestion, while it solves your problem, would create a problem for others (re-read the quote). Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
benign bug in src/sys/kern/kern_resource.c:limcopy() ?
Hello folks, The limcopy() function bcopy()s a struct rlimit, but the len argument to bcopy() is given as sizeof(struct plimit). This hasn't caused any problems so far because the destination address is the first member of struct plimit and all the other member of plimit are initialized immediately thereafter. The patch follows. Cheers, Mike Makonnen Index: sys/kern/kern_resource.c === RCS file: /home/ncvs/src/sys/kern/kern_resource.c,v retrieving revision 1.106 diff -u -r1.106 kern_resource.c --- sys/kern/kern_resource.c29 Jun 2002 02:00:01 - 1.106 +++ sys/kern/kern_resource.c7 Jul 2002 22:01:54 - @@ -811,7 +811,7 @@ MALLOC(copy, struct plimit *, sizeof(struct plimit), M_SUBPROC, M_WAITOK); - bcopy(lim-pl_rlimit, copy-pl_rlimit, sizeof(struct plimit)); + bcopy(lim-pl_rlimit, copy-pl_rlimit, sizeof(struct rlimit)); copy-p_lflags = 0; copy-p_refcnt = 1; return (copy); To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rc_ng: amd invocation is still broken
On Mon, 24 Jun 2002 10:54:06 -0700 (PDT)
John Polstra [EMAIL PROTECTED] wrote:
I updated my -current system yesterday, and AMD still isn't being
started quite right by rc_ng. The messages at boot time say:
does the following patch fix it? If so, please commit it.
Cheers,
Mike Makonnen
Index: amd
===
RCS file: /home/ncvs/src/etc/rc.d/amd,v
retrieving revision 1.4
diff -u -r1.4 amd
--- amd 21 Jun 2002 19:50:01 - 1.4
+++ amd 24 Jun 2002 19:10:44 -
@@ -17,8 +17,8 @@
case `${CMD_OSTYPE}` in
FreeBSD)
- start_cmd=echo 'Starting amd.'; /usr/sbin/${name}
start_precmd=amd_precmd
+ command_args=
;;
NetBSD)
command_args='-p -a '$amd_dir' -F /etc/amd.conf /var/run/amd.pid'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: rc_ng apm enable not run
On Fri, 21 Jun 2002 23:25:15 -0700
Mike Makonnen [EMAIL PROTECTED] wrote:
I don't know how I missed /etc/rc.i386 when I was doing the porting.
I'll have a chance to work on it Sunday, unless someone else beats me
to it.
Well, here it is. Let me know how goes it.
Cheers,
Mike Makonnen.
Index: etc/rc.d/apm
===
RCS file: etc/rc.d/apm
diff -N etc/rc.d/apm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ etc/rc.d/apm24 Jun 2002 19:53:06 -
@@ -0,0 +1,30 @@
+#!/bin/sh
+#
+# $FreeBSD: src/etc/rc.d/apmd,v 1.2 2002/06/13 22:14:36 gordon Exp $
+#
+
+# PROVIDE: apm
+# REQUIRE: DAEMON
+# BEFORE: LOGIN
+# KEYWORD: FreeBSD
+
+. /etc/rc.subr
+
+name=apm
+rcvar=`set_rcvar`
+start_precmd=apm_precmd
+command=/usr/sbin/${name}
+command_args=-e enable
+
+apm_precmd()
+{
+ case `${SYSCTL_N} hw.machine_arch` in
+ i386)
+ return 0
+ ;;
+ esac
+ return 1
+}
+
+load_rc_config $name
+run_rc_command $1
Index: etc/rc.d/apmd
===
RCS file: /home/ncvs/src/etc/rc.d/apmd,v
retrieving revision 1.2
diff -u -r1.2 apmd
--- etc/rc.d/apmd 13 Jun 2002 22:14:36 - 1.2
+++ etc/rc.d/apmd 24 Jun 2002 19:54:30 -
@@ -5,14 +5,37 @@
#
# PROVIDE: apmd
-# REQUIRE: DAEMON
+# REQUIRE: DAEMON apm
# BEFORE: LOGIN
+# KEYWORD: FreeBSD NetBSD
. /etc/rc.subr
name=apmd
-rcvar=$name
+rcvar=`set_rcvar`
command=/usr/sbin/${name}
+
+case `${CMD_OSTYPE}` in
+FreeBSD)
+ start_precmd=apmd_prestart
+ ;;
+esac
+
+apmd_prestart()
+{
+case `${SYSCTL_N} hw.machine_arch` in
+i386)
+;;
+ *)
+ return 1
+ ;;
+esac
+
+ # Don't start if apm is already running
+ /etc/rc.d/apm forcestatus 1/dev/null return 1
+
+ return 0
+}
load_rc_config $name
run_rc_command $1
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: rc_ng apm enable not run
On Fri, 21 Jun 2002 18:53:11 +0200 Ronald Klop [EMAIL PROTECTED] wrote: Hello, In the rc_ng is 'apm -e enable' not run if I have apm_enable=YES and/or apmd_enable=YES in my rc.conf. But apmd is run with the last option. uhh... my fault :( I don't know how I missed /etc/rc.i386 when I was doing the porting. I'll have a chance to work on it Sunday, unless someone else beats me to it. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fixing could sleeep... was (Re: ../../../vm/uma_core.c:132
On Tue, 11 Jun 2002 18:33:32 -0400 (EDT)
John Baldwin [EMAIL PROTECTED] wrote:
Well, it shouldn't be but it is. :-P However, one should try to avoid holding
locks except when necessary to maximize concurrency. Thus it is better to do
things like malloc() and free() while not holding locks if possible.
On which way to go:
I like your idea better, because it is less work and less bloat. Sometimes
I have to keep reminding myself: Choose the simplest design that works.
Fair enough. Thanks for working on this.
np. It's much fun!
I don't know if you recieved my earlier email about a bug that I found in
execve() while working on fixing the malloc w/ process lock held bugs.
Here's a simpler patch.
It fixes possible resource leaks and failure to unlock a lock, introduced
by nectar@ in rev. 1.162 of kern/kern_exec.c, in the case where the call
to fdcheckstd() fails. Basically it fails to deallocate resources and unlock the
process lock.
Cheers,
Mike Makonnen
Index: sys/kern/kern_exec.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.164
diff -u -r1.164 kern_exec.c
--- sys/kern/kern_exec.c7 Jun 2002 05:41:27 - 1.164
+++ sys/kern/kern_exec.c14 Jun 2002 14:06:14 -
@@ -133,7 +133,7 @@
struct image_params image_params, *imgp;
struct vattr attr;
int (*img_first)(struct image_params *);
- struct pargs *oldargs, *newargs = NULL;
+ struct pargs *oldargs=NULL, *newargs = NULL;
struct procsig *oldprocsig, *newprocsig;
#ifdef KTRACE
struct vnode *tracevp = NULL;
@@ -383,8 +383,10 @@
#endif
/* Make sure file descriptors 0..2 are in use. */
error = fdcheckstd(td);
- if (error != 0)
- goto exec_fail_dealloc;
+ if (error != 0) {
+ oldcred = NULL;
+ goto done1;
+ }
/*
* Set the new credentials.
*/
@@ -467,6 +469,7 @@
p-p_args = newargs;
newargs = NULL;
}
+done1:
PROC_UNLOCK(p);
/*
@@ -486,7 +489,8 @@
if (tracevp != NULL)
vrele(tracevp);
#endif
- pargs_drop(oldargs);
+ if (oldargs != NULL)
+ pargs_drop(oldargs);
exec_fail_dealloc:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Sat, 15 Jun 2002 15:18:43 -0700 Terry Lambert [EMAIL PROTECTED] wrote: Otherwise circular dependencies. That's what rcorder(8) is there for. It's not that simple. The most obvious example is the need to use DNS in order to look up syslog hosts, and whether you start syslogd before you start DNS, if DNS needs to syslog errors. Since the DNS information is only used by syslogd when actual logging to a remote host takes place, it should be possible to say that syslog has a soft dependency on DNS, and DNS has a hard dependency on syslog. So, what you're describing is a chicken and egg problem. The solution is simple, the sysadmin decides which one he wants to start first by fiddling with the REQUIRE and BEFORE lines, or the script can make use of the force_depend() subroutine to start required services that aren't already started. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fixing could sleeep... was (Re: ../../../vm/uma_core.c:132
On Sun, 16 Jun 2002 04:10:23 -0700
Mike Makonnen [EMAIL PROTECTED] wrote:
I don't know if you recieved my earlier email about a bug that I found in
execve() while working on fixing the malloc w/ process lock held bugs.
Here's a simpler patch.
It fixes possible resource leaks and failure to unlock a lock, introduced
by nectar@ in rev. 1.162 of kern/kern_exec.c, in the case where the call
to fdcheckstd() fails. Basically it fails to deallocate resources and unlock the
process lock.
embarrased grin
I didn't catch all instances of allocated resources (newargs).
/embarrased grin
Index: sys/kern/kern_exec.c
===
RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.164
diff -u -r1.164 kern_exec.c
--- sys/kern/kern_exec.c7 Jun 2002 05:41:27 - 1.164
+++ sys/kern/kern_exec.c16 Jun 2002 14:14:37 -
@@ -133,7 +133,7 @@
struct image_params image_params, *imgp;
struct vattr attr;
int (*img_first)(struct image_params *);
- struct pargs *oldargs, *newargs = NULL;
+ struct pargs *oldargs=NULL, *newargs = NULL;
struct procsig *oldprocsig, *newprocsig;
#ifdef KTRACE
struct vnode *tracevp = NULL;
@@ -383,8 +383,10 @@
#endif
/* Make sure file descriptors 0..2 are in use. */
error = fdcheckstd(td);
- if (error != 0)
- goto exec_fail_dealloc;
+ if (error != 0) {
+ oldcred = NULL;
+ goto done1;
+ }
/*
* Set the new credentials.
*/
@@ -467,6 +469,7 @@
p-p_args = newargs;
newargs = NULL;
}
+done1:
PROC_UNLOCK(p);
/*
@@ -476,7 +479,6 @@
crfree(oldcred);
else
crfree(newcred);
- KASSERT(newargs == NULL, (leaking p_args));
/*
* Handle deferred decrement of ref counts.
*/
@@ -486,7 +488,10 @@
if (tracevp != NULL)
vrele(tracevp);
#endif
- pargs_drop(oldargs);
+ if (oldargs != NULL)
+ pargs_drop(oldargs);
+ if (newargs != NULL)
+ pargs_drop(newargs);
exec_fail_dealloc:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Sat, 15 Jun 2002 12:49:52 -0700 Terry Lambert [EMAIL PROTECTED] wrote: David O'Brien wrote: On Fri, Jun 14, 2002 at 03:30:19PM -0700, Terry Lambert wrote: I.e. if REQUIRE describes soft dependency ordering, what describes hard dependency ordering? Why the need to distingish? Otherwise circular dependencies. That's what rcorder(8) is there for. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Fri, 14 Jun 2002 15:30:19 -0700 Terry Lambert [EMAIL PROTECTED] wrote: Ick. What should be used instead of REQUIRE to mean that it will be started? I.e. if REQUIRE describes soft dependency ordering, what describes hard dependency ordering? Correct, the REQUIRE line only describes the dependency ordering. To start it you twiddle the appropriate rc.conf knob. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Sat, 15 Jun 2002 10:44:31 +0930 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: On Thursday, 13 June 2002 at 15:37:55 -0700, Gordon Tetlow wrote: I've imported the excellent work by Mike Makonnen into the tree. Can you summarize what the differences are? o Instead of a few monolithic scripts in /etc there are many task oriented scripts in /etc/rc.d o Dynamic ordering of boot scripts performed at boot o Ability to run a daemon in a jailed environment as a non-privileged user o common subroutines to make scripts shorter and easier to maintain o If necessary, service specific knobs in /etc/rc.conf.d/ Basically, the scripts /etc/rc* scripts have been broken down into individual scripts, each one doing one specific task**. In addition the dependency ordering of the scripts is performed at boot time, so if you have local scripts that you want executed at boot time, it's just a matter of writing up the script, defining what services it should follow (i.e- after local disks have been mounted), and then putting it in /etc/rc.d/. There's a file: /etc/rc.subr, which is intended to make your scripts as short as possible. It contains common subroutines that are useful in writing scripts. Here's a quick introduction: #!/bin/sh # . /etc/rc.subr # PROVIDE: fooservice # REQUIRE: barservice mountcritlocal # KEYWORD: FreeBSD name=foo rcvar=`set_rcvar` command=/usr/bin/foo required_files=/etc/foo.conf load_rc_config $name run_rc_command $1 Given this script, the routines in rc.subr will do the following: o check rc.conf and /etc/rc.conf.d/foo to make sure 'foo_enable' is set. o pull in the correct path to the command if 'foo_command' is specified, and make sure it is executable o check that the required file /etc/foo.conf exists o pull in any command line options specified in the 'foo_flags' variable o if the appropriate variables are defined, start foo in a jail as a non-privileged user. o tell you whether foo is already started o tell you what pid foo is using o let you start foo o let you stop all instances of foo o and some more that I can't think of right now IMO the functionality you get for just those 11 lines is well worth the small effort required in readjusting to this new scheme. If what you want to do requires a little more customization, then you can also define custom start/stop/etc... routines that will be executed instead of the default one. Having said that, there is remarkably little to adjust to. Baring any bugs in the scripts, switching on rcng should not break anything. I have tried to include temporary compatibility shims to ensure that. I had intended to remove them before 5.0-RELEASE, but they should probably be marked as deprecated and instead removed in 6.0-RELEASE. Cheers, Mike Makonnen ** Most scripts do one specific task, but there are exceptions. It is acceptable to do more than one task if they are closely related: for example: /etc/rc.d/sendmail To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Sat, 15 Jun 2002 17:53:03 +0930
Greg 'groggy' Lehey [EMAIL PROTECTED] wrote:
On Saturday, 15 June 2002 at 0:34:36 -0700, Mike Makonnen wrote:
On Sat, 15 Jun 2002 10:44:31 +0930
Greg 'groggy' Lehey [EMAIL PROTECTED] wrote:
On Thursday, 13 June 2002 at 15:37:55 -0700, Gordon Tetlow wrote:
I've imported the excellent work by Mike Makonnen into the tree.
Can you summarize what the differences are?
o Instead of a few monolithic scripts in /etc there are many task oriented
scripts in /etc/rc.d
o Dynamic ordering of boot scripts performed at boot
o Ability to run a daemon in a jailed environment as a non-privileged user
o common subroutines to make scripts shorter and easier to maintain
o If necessary, service specific knobs in /etc/rc.conf.d/
Hmm, appears to be Luke Mewburn's NetBSD stuff, which I know.
Shouldn't there be an Obtained From: NetBSD in the commit messages?
Yes, it is a port of NetBSD's rc sytem as mentioned here:
http://home.pacbell.net/makonnen/rcng.html .
Oversight on Gordon's part I'm sure.
Are you (or is anybody) doing something about keeping as close as
possible to being in sync with NetBSD?
Yeah, when I get some time I'm going to try and get rid of those
case `${CMD_OSTYPE}` clauses together with Luke. David O'Brien said
a while back that he and some others were willing to make sure they stayed
in sync. That's the only reason I made the effort to set it up so that it would
be somewhat easy to do.
Cheers,
Mike Makonnen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Fri, 14 Jun 2002 19:38:15 +0200 Dennis Kristensen [EMAIL PROTECTED] wrote: sendmail_enable=NONE did'nt help either. This can be fixed with below patch. It still complains with /etc/rc: WARNING: $sendmail_enable is not set properly. but sendmail is no longer started. [patch ommited] Thanks. It's supposed to complain to remind me to get together with the sendmail maintainer to figure out how to handle sendmail's non-standard NONE option. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Fri, 14 Jun 2002 16:55:40 +0300 Danny Braniss [EMAIL PROTECTED] wrote: in amd, # REQUIRE: rpcbind mountall ypbind nfsclient ** since i don't use yp, how can i override this? or in other words, can REQUIRE be configurable too? The REQUIRE line doesn't mean it will be started. It just means that ypbind comes before amd in the boot process. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: rc.d is in the tree
On Thu, 13 Jun 2002 15:37:55 -0700 (PDT) Gordon Tetlow [EMAIL PROTECTED] wrote: I've imported the excellent work by Mike Makonnen into the tree. Please note that it should be fully functional but there are some parts that need some looking at: atm ipfilter some others that I'm forgetting Hopefully Mike will chime in with some others. I've been having some problems with named not starting properly since I synced up all the scripts with the NetBSD bits. I'm not sure exactly what it is, that it doesn't like (the order in which it was started changed), but I'll be taking a look at it in a bit. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fixing could sleeep... was (Re: ../../../vm/uma_core.c:132
On Tue, 11 Jun 2002 04:36:41 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: This solution has the advantage that the only code that has to change is the ucred and setuid/gid helper functions that already know about the struct uidinfo functions. In fact only three functions not related to uidinfo(9) need to be touched: proc0_init(), change_ruid(), change_uid(). The disadvantage is the memory bloat and a small amount of code complexity (but as I said, this is localized, and not very complex either). Do you like it? Should I go ahead and implement a patch? Anything I overlooked? It won't work if you have to change a uidinfo more than once. I still prefer just doing the uifind() at the beginning of the function, passing in the uidinfo pointer to the chnage_fooid() functions, and adding cleanup uifree's in case of failure. Yes... if you don't go through the setuid/gid family of functions. Currently, the only place uifind() is called, besides change_[re]uid() is in proc0_init. My assumption was that you need to change the uidinfo only when changing ucreds (either an exec or specific seteuid,etc), and that when you change ucreds you always crget() a new one and not reuse the old one. So, in this case there could be a maximum of 2 allocations (both on the new ucred): one for cr_uidinfo and one for cr_ruidinfo. With that assumption in mind I wanted to compartmentalize the allocation of struct uidinfo. It seemed cleaner to me to have only uifind() and its immediate callers have intimate knowledge struct uidinfo creation and destruction, but I suppose if setuid() (for example) knows enough to compare cr_ruid et al, its knowledge of one more member isn't that bad. Basically, I wanted to avoid having to touch every function that changes the r/e uid, and touch just those that already dealt with the uidinfo. In any case, I'll submit a patch to you doing it the way you suggested. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fixing could sleeep... was (Re: ../../../vm/uma_core.c:132
On Tue, 11 Jun 2002 13:07:03 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: Yes... if you don't go through the setuid/gid family of functions. Currently, the only place uifind() is called, besides change_[re]uid() is in proc0_init. My assumption was that you need to change the uidinfo only when changing ucreds (either an exec or specific seteuid,etc), and that when you change ucreds you always crget() a new one and not reuse the old one. So, in this case there could be a maximum of 2 allocations (both on the new ucred): one for cr_uidinfo and one for cr_ruidinfo. Oh, duh, you are right, it should work then. You can implement whichever you please then. I can see pros and cons cleanliness-wise of both. :) Disregard my earlier patch. It has a bug. Is it possible to sleep when doing a FREE()? I had assumed not, but it seems I may be mistaken. On which way to go: I like your idea better, because it is less work and less bloat. Sometimes I have to keep reminding myself: Choose the simplest design that works. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fixing could sleeep... was (Re: ../../../vm/uma_core.c:132
On Sat, 08 Jun 2002 10:57:32 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: Is the solution to this to use M_NOWAIT and continue re-trying untill it succeeds? Is there on-going smp work in locking down struct proc that will eliminate this problem? Well, the real solution probably involves changing where we dink with uidinfo structs so we bump the reference count on teh new one before we grab the proc lock, change over to the new one while holding the proc lock, then release the reference to the old one after we are done. Well... this is basically what happens setuid - creates a new ucred - locks p - calls change_ruid() change_ruid - calls uifind() uifind - does MALLOC w/ M_WAITOK After thinking about it for a while, this is the solution I came up with: Each new struct ucred will carry an array of pointers to struct uidinfo. This will be an array of 3 elements (a spare for cr_ruidinfo, cr_uidinfo, null). Obviously, it gets added after -cr_endcopy. When crget() is called it calls a function whose job it is to create an array of pointers to struct uidinfo and allocate the memory for them. When uifind() is called it will be given an array of pointers to uidinfo structs (the ones from ucred), in addition to the uid it is to lookup. If it already has a uidinfo for that uid, then it returns that to the calling function. If it can't find the uid, then it unhooks (copies the address, and deletes it from the array) the last struct uidinfo from the array, initializes it, inserts it into the hashtable and returns it to the caller. When crfree is called it calls a function that deallocates the spare structs uidinfo. This solution has the advantage that the only code that has to change is the ucred and setuid/gid helper functions that already know about the struct uidinfo functions. In fact only three functions not related to uidinfo(9) need to be touched: proc0_init(), change_ruid(), change_uid(). The disadvantage is the memory bloat and a small amount of code complexity (but as I said, this is localized, and not very complex either). Do you like it? Should I go ahead and implement a patch? Anything I overlooked? Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Fixing could sleeep... was (Re: ../../../vm/uma_core.c:1327: couldsleep with pcm0:play:0 locked from)
On Sat, 08 Jun 2002 04:03:40 -0700 (PDT)
Hiten Pandya [EMAIL PROTECTED] wrote:
--- Juan Francisco Rodriguez Hervella [EMAIL PROTECTED] wrote:
../vm/uma_core.c:1160
../../../vm/uma_core.c:1327: could sleep with process lock locked
from ../../../kern/kern_prot.c:511
../../../vm/uma_core.c:1327: could sleep with process lock locked
from
Hope this help. Do you think these errors are alarming ?
I mean, do you recommend me to recopile my kernel again ?
(please noo, it takes me a lot of time to recompile whatever
thing :)
I also get these and I figured they're as good an excuse as any to jump
into the kernel code :-} This particular one (and others related to the
setuid/gid family of functions) occur because some time after PROC_LOCK
is called in set{uid,euid} and further down the call stack uidfind()
allocates some memory specifying the M_WAITOK flag.
Is the solution to this to use M_NOWAIT and continue re-trying untill it
succeeds? Is there on-going smp work in locking down struct proc that
will eliminate this problem?
Cheers,
Mike Makonnen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Weekly run output: makewhatis
I started getting these recently in my weekly run outputs. Cleaning up kernel database files: Rebuilding locate database: Rebuilding whatis database: makewhatis: /usr/local/man/man1/etags.1.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_8859_to_t61.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_enable_translation.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_set_string_translators.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_t61_to_8859.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_translate_from_t61.3.gz: No such file or directory makewhatis: /usr/local/man/man3/ldap_translate_to_t61.3.gz: No such file or directory makewhatis: /usr/local/man/man8/ldif2id2children.8.gz: No such file or directory makewhatis: /usr/local/man/man8/ldif2id2entry.8.gz: No such file or directory makewhatis: /usr/local/man/man8/ldif2index.8.gz: No such file or directory -- End of weekly output -- I know the etags line has been happening for at least a couple of months, but all the rest are new. Is this a result of the recent de-perlifying of makewhatis? I'm assuming there's probably a missing 2/dev/null somewhere. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/kern subr_witness.c
On Sat, 08 Jun 2002 10:57:31 -0400 (EDT) John Baldwin [EMAIL PROTECTED] wrote: Heh, that's fine. Let me know if it works. :) Ok, no more exhausted messages. Before I applied it I had a bunch of dead witnesses when I did a show witness in ddb (i.e. - only about 1 out of 10 witnesses were _not_ dead). I didn't see any after the patch (I assume I'll probably see more as my uptime increases?). Before which patch? The one in CVS or the one I haven't committed yet. (The one I posted that's not in CVS has a bug btw). The one in CVS. Cheers. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
rc.d boot scripts are ready
Ok folks, I have our current rc.* scripts ported to the NetBSD framework. Preliminary testing says it's good to go, so consider this an official call for testers. Gordon has indicated he is ready to start committing it soon. I ask that people start testing it out before he does so. That will enable me to get any remaining bugs fixed before it hits the tree. Once you download and follow the directions at: http://home.pacbell.net/makonnen/rcng.html you can enable it by including rc_ng=YES in your /etc/rc.conf. If you experience any breakage please let me know so I can fix it. I'd appreciate it if people with the appropriate setups especially test the following: ATM ipfilter amd Any comments, constructive criticism welcome. Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rc.d boot scripts are ready
[ forgive this breach of net-ettiquette, but this should probably be given a wider audience] On Thu, 06 Jun 2002 05:01:18 -0600 Mike Makonnen [EMAIL PROTECTED] wrote: Ok folks, I have our current rc.* scripts ported to the NetBSD framework. Preliminary testing says it's good to go, so consider this an official call for testers. Gordon has indicated he is ready to start committing it soon. I ask that people start testing it out before he does so. That will enable me to get any remaining bugs fixed before it hits the tree. Once you download and follow the directions at: http://home.pacbell.net/makonnen/rcng.html you can enable it by including rc_ng=YES in your /etc/rc.conf. If you experience any breakage please let me know so I can fix it. I'd appreciate it if people with the appropriate setups especially test the following: ATM ipfilter amd Any comments, constructive criticism welcome. Cheers, Mike Makonnen 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
