Re: CVSup vs inttypes.h,v
It's been moved to the Attic. From what I can gather most of what was in there was moved to sys/sys/stdint.h and whatever files *it* includes. Cheers, mikem On Mon, 31 Dec 2001 21:32:17 -0800 (PST) Julian Elischer <[EMAIL PROTECTED]> wrote: > > CVSup is refusing to give me a inttypes.h,v in sys/sys > > I sup from cvsup14 as it's very close. > How do I work out where the problem is? > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: conf/31358: Updated patch for -CURRENT
On Tue, 8 Jan 2002 11:02:06 +0100
Thomas Quinot <[EMAIL PROTECTED]> wrote:
[snip]
> + # Handle absent nfs client support
> + if sysctl vfs.nfs >/dev/null 2>&1; then
> + nfsclient_in_kernel=1
> + else
> + nfsclient_in_kernel=0
> + fi
> +
This should be handled inside the case statement for ${nfs_client_enable}, as you want
to load the nfsclient kld only if the nfs client is enabled.
> case ${nfs_client_enable} in
> [Yy][Ee][Ss])
> + kldload nfsclient && nfsclient_in_kernel=1
> +
> + case $nfsclient_in_kernel in
> + 1)
> + ;;
> + *)
> + echo 'Warning: NFS client kernel module failed to load'
> + nfs_client_enable=NO
> + ;;
> + esac
> + ;;
> + esac
> +
> + case "${nfs_client_enable}" in
> + [Yy][Ee][Ss])
> if [ -n "${nfs_access_cache}" ]; then
> echo -n " NFS access cache time=${nfs_access_cache}"
> sysctl
>vfs.nfs.access_cache_timeout=${nfs_access_cache} >/dev/null
> @@ -732,6 +754,27 @@
> echo -n ' rpc.lockd'; rpc.lockd
> ;;
> esac
You should clean this up so there is only *one* 'case "${nfs_client_enable}"'.
Look at the implementation of case ${nfs_server_enable}, earlier in rc.network for an
example of how it should be done.
Cheers,
mike makonnen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: undefined reference to `pfs_statfs'
You should read UPDATING. PROCFS now requires PSEUDOFS. mike makonnen On Tue, 8 Jan 2002 23:48:44 - "ADRIAN.BROWNE" <[EMAIL PROTECTED]> wrote: > Anyone got any ideas > > kern.version: FreeBSD 5.0-20020102-CURRENT #0: Wed Jan 2 12:00:48 GMT 2002 > > > > make failed on > > /usr/src/sys/i386/compile/WARSPITE/../../../fs/procfs/procfs.c(.data+0x6c): > undefined reference to `pfs_root' > /usr/src/sys/i386/compile/WARSPITE/../../../fs/procfs/procfs.c(.data+0x74): > undefined reference to `pfs_statfs' > *** Error code 1 > > source updated by cvs on 8-1-2002 still failed :( > > > [EMAIL PROTECTED] > __ _ >/ /___ ___ / __ ) ___// __ \ > / /_ / ___/ _ \/ _ \/ __ \__ \/ / / / > / __/ / / / __/ __/ /_/ /__/ / /_/ / > /_/ /_/ \___/\___/_//_/ > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new module-references compile error
On Sat, 12 Jan 2002 13:22:47 +0100 (MET) Michael Class <[EMAIL PROTECTED]> wrote: > pc-micha:/sys/i386/compile/MCSMP2# make > linking kernel.debug > linprocfs.o: In function `linprocfs_donetdev': > /sys/i386/compile/MCSMP2/../../../compat/linprocfs/linprocfs.c(.text+0xfe9): >undefined reference to `linux_ifname' > *** Error code 1 > A few days ago changes were made to sys/compat/linux/linux_ioctl.c (rev. 1.79, I believe) that removed linux_ifname(). Just checkout rev. 1.78 and use that instead. cheers, mike makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new module-references compile error
On Mon, 14 Jan 2002 11:25:47 +0600 (NOVT) [EMAIL PROTECTED] (Nickolay Dudorov) wrote: > And now linux_ioctl.c has rev. 1.81 and you can not simply revert > it to the rev 1.78 or 1.77. The commits after 1.79 touch a different part of the file. Just reverse diff 1.79 and patch it onto 1.81. Everything except the ident string should succeed. cheers, mike makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
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: 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 = ":!@"
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: 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: 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: 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: 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: 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 hashtable"in 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!
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: 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 showmount -e 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: 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
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
#include
#include
#include
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: 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]"
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: 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: port 0xb400-0xb41f irq 12 at device 7.2 on pc i0 usb0: 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: port 0xb800-0xb81f irq 12 at device 7.3 on pc i0 usb1: 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]"
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: [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
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: 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: 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
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
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]"
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: 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: 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 :-) > > 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]"
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]"
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: 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: 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: 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: 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]"
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: 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]"
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]"
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 li
Re: /etc/rc: WARNING: domainname(1) is not set.
On Tue, Jul 08, 2003 at 06:26:27PM -0400, Tom Parquette wrote: > Hi, > I have been getting the message "/etc/rc: WARNING: domainname(1) is not > set" every time I boot one of my machines. > It is a 5.1-CURRENT system but I have not updated since June 15. > > I have been ignoring this for some time because I have been trying to > get DDNS to work. > I thought it was related to my DDNS problem. Now that I have DDNS > working (finally) I was supprised to see the message still appearing. > It says domainname(1) for a reason :-) Domainname has nothing to do with DNS, it's talking about your NIS domain name. You are trying to use one of the yp* daemons without first setting your NIS domain. You need domainname="..." in rc.conf. 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: NVidia driver stability?
I don't know if this is relevant, but the NVidia drivers won't work with libkse or libthr, because it messes with the %gs segment register, which both threading libraries use. The only threading library it currently works with is libc_r. 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]"
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
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
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
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: 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 > > > 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: 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 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 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: 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.
I didn't catch all instances of allocated resources (newargs).
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: 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: 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
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: benign bug in src/sys/kern/kern_resource.c:limcopy() ?
On Mon, 08 Jul 2002 08:20:42 +0100 David Malone <[EMAIL PROTECTED]> wrote: > > bcopy(&(lim->pl_rlimit[0]), &(copy->pl_rlimit[0]), > sizeof(lim->pl_rlimit)); > > rather than just copying the first limit? It might be better to just > bcopy the whole struct plimit and make a note that other fields need > to be reset. > yeah, you're right. I replaced one benign bug with a worse one. Alfred emailed me about it earlier, but I wasn't paying attention. Sorry :( Cheers, Mike Makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: location of setkey in /etc/rc.d/ipsec
On Mon, 29 Jul 2002 00:22:46 +0900
Hajimu UMEMOTO <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I found that setup of IPsec doesn't work correctly if you are using
> /etc/rc.d/. While NetBSD has setkey in /sbin, FreeBSD has it in
> /usr/sbin. However, the location is hardcoded in /etc/rc.d/ipsec.
> Here is a patch.
Thanks for spotting this. I think the following patch might be better.
Cheers,
Mike.
Index: etc/rc.d/ipsec
===
RCS file: /home/ncvs/src/etc/rc.d/ipsec,v
retrieving revision 1.2
diff -u -r1.2 ipsec
--- etc/rc.d/ipsec 13 Jun 2002 22:14:36 - 1.2
+++ etc/rc.d/ipsec 29 Jul 2002 07:29:26 -
@@ -24,6 +24,15 @@
reload_cmd="ipsec_reload"
extra_commands="reload"
+case `${CMD_OSTYPE}` in
+FreeBSD)
+ ipsec_program="/usr/sbin/setkey"
+ ;;
+NetBSD)
+ ipsec_program="/sbin/setkey"
+ ;;
+esac
+
ipsec_prestart()
{
if [ ! -f "$ipsec_file" ]; then
@@ -45,7 +54,7 @@
ipsec_start()
{
echo "Installing ipsec manual keys/policies."
- /sbin/setkey -f $ipsec_file
+ ${ipsec_program} -f $ipsec_file
}
ipsec_stop()
@@ -56,16 +65,16 @@
# it is very questionable to do this during shutdown session, since
# it can hang any of remaining IPv4/v6 session.
#
- /sbin/setkey -F
- /sbin/setkey -FP
+ ${ipsec_program} -F
+ ${ipsec_program} -FP
}
ipsec_reload()
{
echo "Reloading ipsec manual keys/policies."
- /sbin/setkey -F
- /sbin/setkey -FP
- /sbin/setkey -f "$ipsec_file"
+ ${ipsec_program} -F
+ ${ipsec_program} -FP
+ ${ipsec_program} -f "$ipsec_file"
}
load_rc_config $name
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
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
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
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
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: 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: 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: 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: 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: 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
