Re: Staroffice6.0 Linux beta with FreeBSD
Hi Marcel, What if you try it with linux_base-7? I've now more results. - The port works with old and new linux_base port, I it get started the right way. - Starting an install without -net does segfault suddenly. - Starting a user-install does segfault after registering the scripts. - Starting SO6.0 does loop indefinitly after starting it. You can find some linux_kdump output on the following location. Do you have a idea where it fails ? http://home.teleport.ch/freebsd/debug/ The port is still available on: http://home.teleport.ch/freebsd/ports/staroffice60.tgz Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: named pid file in /var/run/named/pid?
At Thu, 4 Oct 2001 11:21:19 + (UTC), Bernd Walter wrote: I run an md based filesystem for /var/run so it is empty after startup. Does that mean that I also need to take care of creating directories in it during boot - and maintaining myself on every box. Or it it the responsibility of the programms to enshure that the directories they need are created? /var/run/named is created by mtree (/etc/mtree/BSD.var.dist). If you want to use md(4) for /var/run, you should make directory after /var/run creation. -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ntfs panic (lockmgr: not exclusive lock holder 470 unlocking)
I tried to use mount_ntfs, but it panic'ed. % sudo mount -t ntfs /dev/ad0s1 /mnt % cd /mnt % ls -la panic: lockmgr: pid 551, not exclusive lock holder 470 unlocking Debugger(panic) Stopped at Debugger+0x44: pushl%ebx db t Debugger() at Debugger+0x44 panic(c02ef100,227,c02ef0e0,1d6,cab5f740) at panic+0x70 lockmgr(cb5f7dc,6,cab5f7ac,ca376404,caad4bf4) at lockmgr+0x369 vop_stdunlock(caad4be4,cab5f740,ca376404,c031dbc0,cab5f740) at vop_stdunlock+0x22 ntfs_inactive(caad4c08,cab5f740,0,c031db00,cab5f740) at ntfs_inactive+0x54 vput(cab5f740,caad4c44,ffdf,cab5f740,caad4c8c,ca376404) at vput+0x102 lstat(ca376404,caad4d20,80cd34c,80ce108,80cd300) at lstat+0x71 syscall(2f,2f,2f,80cd300,80ce108) at syscall+0x20b syscall_with_err_pushed() at syscall_with_err_pushded+0x1b --- syscall (190, FreeBSD ELF, lstat), eip = 0x80568f0, esp = 0xbfbff390, ebp = 0xbfbff41c --- -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: named pid file in /var/run/named/pid?
On Thu, Oct 04, 2001 at 10:16:25PM +0900, Jun Kuriyama wrote: At Thu, 4 Oct 2001 11:21:19 + (UTC), Bernd Walter wrote: I run an md based filesystem for /var/run so it is empty after startup. Does that mean that I also need to take care of creating directories in it during boot - and maintaining myself on every box. Or it it the responsibility of the programms to enshure that the directories they need are created? /var/run/named is created by mtree (/etc/mtree/BSD.var.dist). If you I know. want to use md(4) for /var/run, you should make directory after /var/run creation. That's annoying if it becomes popular for services to use their own subdirectory. It's much better and easier if the coresponding rc file did. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: named pid file in /var/run/named/pid?
On Thu, 4 Oct 2001, Jun Kuriyama wrote: At Thu, 4 Oct 2001 11:21:19 + (UTC), Bernd Walter wrote: I run an md based filesystem for /var/run so it is empty after startup. Does that mean that I also need to take care of creating directories in it during boot - and maintaining myself on every box. Or it it the responsibility of the programms to enshure that the directories they need are created? /var/run/named is created by mtree (/etc/mtree/BSD.var.dist). If you want to use md(4) for /var/run, you should make directory after /var/run creation. Is it possible to make the md-filesystem automatically make the needed subdirectories, when a program wants to create /var/run/a/very/deeply/nested/file ? Or would that just be too ugly, mixing device drivers with high-level file operations? Guess so.. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntfs panic (lockmgr: not exclusive lock holder 470 unlocking)
On Thu, 04 Oct 2001, Jun Kuriyama wrote: I tried to use mount_ntfs, but it panic'ed. % sudo mount -t ntfs /dev/ad0s1 /mnt % cd /mnt % ls -la panic: lockmgr: pid 551, not exclusive lock holder 470 unlocking Debugger(panic) Stopped at Debugger+0x44: pushl%ebx db t Debugger() at Debugger+0x44 panic(c02ef100,227,c02ef0e0,1d6,cab5f740) at panic+0x70 lockmgr(cb5f7dc,6,cab5f7ac,ca376404,caad4bf4) at lockmgr+0x369 vop_stdunlock(caad4be4,cab5f740,ca376404,c031dbc0,cab5f740) at vop_stdunlock+0x22 ntfs_inactive(caad4c08,cab5f740,0,c031db00,cab5f740) at ntfs_inactive+0x54 I reported the same panic a while ago. It appears to have been caused by the last large KSE commit. -- David Taylor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: named pid file in /var/run/named/pid?
On Thu, Oct 04, 2001 at 04:09:56PM +0200, Bernd Walter wrote: That's annoying if it becomes popular for services to use their own subdirectory. It would be much better to get rid of pidfiles altogether. They have all sorts of nasty problems. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: ntfs panic (lockmgr: not exclusive lock holder 470 unlocking
On 04-Oct-01 Jun Kuriyama wrote: I tried to use mount_ntfs, but it panic'ed. NTFS and NWFS are currently broken in -current due to the KSE stuff. Please don't use them for now. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current install failure
Hello. I have submitted a PR (bin/31009) with a followup including the patch. Hoping you have time to fix this soon... jkh = Jordan Hubbard [EMAIL PROTECTED] wrote: jkh mostly empty. Now that devfs is the default, phk needs to update jkh libdisk so that it doesn't attempt to make the device nodes in this jkh way. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: named pid file in /var/run/named/pid?
On Thu, Oct 04, 2001 at 06:17:13PM +0200, Leif Neland wrote: On Thu, 4 Oct 2001, Jun Kuriyama wrote: At Thu, 4 Oct 2001 11:21:19 + (UTC), Bernd Walter wrote: I run an md based filesystem for /var/run so it is empty after startup. Does that mean that I also need to take care of creating directories in it during boot - and maintaining myself on every box. Or it it the responsibility of the programms to enshure that the directories they need are created? /var/run/named is created by mtree (/etc/mtree/BSD.var.dist). If you want to use md(4) for /var/run, you should make directory after /var/run creation. Is it possible to make the md-filesystem automatically make the needed subdirectories, when a program wants to create /var/run/a/very/deeply/nested/file ? That wouldn't work. The whole point of /var/run/named is to set the permissions on the directory such that a non-root user (the 'bind' user in FreeBSD typically) can write files in the directory. In order to create the named directory in /var/run, you need root privs. Give that to the program, and we are back where we started, no point in using /var/run/named, just use /var/run. Or would that just be too ugly, mixing device drivers with high-level file operations? Guess so.. Yeah, that too. It is not that big of a deal to hack this support for named into the rc scripts. It is a hassle when considering the correct way to handle this to make it extensible to other daemons we may wish to run in such a manner. -- Crist J. Clark [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: named pid file in /var/run/named/pid?
On Thu, Oct 04, 2001 at 01:19:15PM -0700, Crist J. Clark wrote: On Thu, Oct 04, 2001 at 06:17:13PM +0200, Leif Neland wrote: On Thu, 4 Oct 2001, Jun Kuriyama wrote: At Thu, 4 Oct 2001 11:21:19 + (UTC), Bernd Walter wrote: I run an md based filesystem for /var/run so it is empty after startup. Does that mean that I also need to take care of creating directories in it during boot - and maintaining myself on every box. Or it it the responsibility of the programms to enshure that the directories they need are created? /var/run/named is created by mtree (/etc/mtree/BSD.var.dist). If you want to use md(4) for /var/run, you should make directory after /var/run creation. Is it possible to make the md-filesystem automatically make the needed subdirectories, when a program wants to create /var/run/a/very/deeply/nested/file ? That wouldn't work. The whole point of /var/run/named is to set the permissions on the directory such that a non-root user (the 'bind' user in FreeBSD typically) can write files in the directory. In order to create the named directory in /var/run, you need root privs. Give that to the program, and we are back where we started, no point in using /var/run/named, just use /var/run. Named is startet under root rights and drop these later. It has to be so otherwise it's not possible to open port 53 for listen. So there is no great magic in creating the pid file in /var/run. If that's a problem I consider it as a bug in named. Or would that just be too ugly, mixing device drivers with high-level file operations? Guess so.. Yeah, that too. Agreed. It's no the purpose of a filessystem to guess application needs. It is not that big of a deal to hack this support for named into the rc scripts. It is a hassle when considering the correct way to handle this to make it extensible to other daemons we may wish to run in such a manner. The question is what is the correct way. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: named pid file in /var/run/named/pid?
On Fri, Oct 05, 2001 at 12:03:02AM +0200, Bernd Walter wrote: On Thu, Oct 04, 2001 at 01:19:15PM -0700, Crist J. Clark wrote: [snip] That wouldn't work. The whole point of /var/run/named is to set the permissions on the directory such that a non-root user (the 'bind' user in FreeBSD typically) can write files in the directory. In order to create the named directory in /var/run, you need root privs. Give that to the program, and we are back where we started, no point in using /var/run/named, just use /var/run. Named is startet under root rights and drop these later. It has to be so otherwise it's not possible to open port 53 for listen. So there is no great magic in creating the pid file in /var/run. If that's a problem I consider it as a bug in named. You've never 'HUPped' a named running as non-root then. It will complain about not being able to write the pid file (not that it is a fatal problem). This is the reason for /var/run/named. [snip] It is not that big of a deal to hack this support for named into the rc scripts. It is a hassle when considering the correct way to handle this to make it extensible to other daemons we may wish to run in such a manner. The question is what is the correct way. It happens I've just been hacking around in /etc/rc where the clean-up of /var/run is done, and someone else mentioned mtree(8) in this thread (but in a different context). I think it would be easy enough to run mtree(8) right after /var/run is cleaned (and long after it would be mounted as an md(4)) to get it into good form. The problem reduces to maintaining the map file for this purpose. -- Crist J. Clark [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic at vlan_input()
I got another panic on my yesterday's -current. At this time, I made a kernel with device vlan. db t vlan_input(c0e73800,..) at vlan_input+0x42 ether_demux(c156b000,...) at ether_demux+0x12a ether_input(c156b000,...) at ether_input+0x5a wi_rxeof(c156000,...) at wi_rxeof+0x1b7 wi_intr(c156b000,...) at wi_intr+0xd6 pcic_pci_func_intr(c14fc200) at pcic_pci_func_intr+0x36 ithread_loop(c0ce0580,...) at ithread_loop+0x12a fork_exit(c01b6bac,...) at fork_exit+0x58 fork_trampoline() at fork_trampoline+0x8 -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kerberos in -current snapshots
Greetings: I was wondering which options in make.conf do I need to enable to get the same kerberos that is in the binary snapshots of -RELEASE and -CURRENT? Is it IV I need or is it 5 or both? Thanks. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: NIS client performance seems very poor under network load
Thyer, Matthew writes: So the answer is a name service caching daemon ala nscd on Solaris. Or linux. Apparently, there is an nscd in glibc. Perhaps somebody with motivation could determine if its any good. If so, they could chop it out of glibc, make it into a port add hooks to our libc for it. (I no longer work at Duke or even use NIS, so that motivated person would not be me). Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: uucp user shell and home directory
UUCP has many valid uses. Even today. If you don't understand the software, that's fine with me. Just don't use your ignorance as an excuse to dike the software out. Or more precisely, admit you want to rip the code out because you don't understand what it is, rather than making up specious excuses for it's removal. This is all nonsense. Nobody has removed UUCP, it is still available as a port. I use UUCP myself and agree with the move. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: uucp user shell and home directory
Just like with anonymous FTP, don't make it world writable if you don't want the world writing to it. Right - that's what actually was done. Don't install it unless you need. Oh give me a break. You do not disable anonymous FTP uploads by 'rm /usr/libexec/ftpd'. I'm talking about the one in FreeBSD. uux job is to setup the commands for the next site and break the next sitename if it equals 8 letters. That's strange. For over two years I've talked hourly to a pair of UUCP sites with eight character nodenames, and it works just fine. What is the specific breakage you are seeing? There is a big difference - they are maintained and don't contain known security issues. Again I ask: if maintenance is an issue, why would you not even attempt to find a maintainer? I don't get your point - what is wrong with having it a port? Well, here's one reason: 1) Remove all the network interfaces from your system (Ethernet, PPP, SL/IP, etc). 2) cd into /usr/ports and try to build UUCP. Unless you have a prepopulated /usr/ports/distfiles, it won't work. Requiring IP connectivity to bootstrap software on a machine that doesn't have IP connectivity is a non-starter. Yes, you can install from the CDROM, but there will always be cases where you can't do this (media errors, lack of CD, etc.) However my underlying argument still remains that nothing is being done to address the actual problem. I.e., people are going out of their way to see the problem NOT get fixed. There's an issue of principal at stake here, and I really don't like the precedent that is being set by this move. --lyndon Never hit a man with glasses. Hit him with a baseball bat. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: uucp user shell and home directory
Again I ask: if maintenance is an issue, why would you not even attempt to find a maintainer? How do you find a maintainer? Do you run a contest on your favourite TV channel or what? Maintainers appear by themselves or they don't. Considering how long UUCP has been unmaintained, they don't in this case. 1) Remove all the network interfaces from your system (Ethernet, PPP, SL/IP, etc). 2) cd into /usr/ports and try to build UUCP. Now ask yourself, how you have installed FreeBSD on this system. Unless you have a prepopulated /usr/ports/distfiles, it won't work. Requiring IP connectivity to bootstrap software on a machine that doesn't have IP connectivity is a non-starter. Yes, you can install from the CDROM, but there will always be cases where you can't do this (media errors, lack of CD, etc.) pkg_add freebsd-uucp.tgz If you can't do that from floppy/CD, then you can't install FreeBSD as well, so you don't have a problem. However my underlying argument still remains that nothing is being done to address the actual problem. I.e., people are going out of their way to see the problem NOT get fixed. There's an issue of principal at stake here, and I really don't like the precedent that is being set by this move. What are *you* doing to address the problem? Are you stepping up as a maintainer? Are you willing to fix the problems with UUCP in FreeBSD as it is? How much time are you willing to contribute? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: uucp user shell and home directory
I don't get your point - what is wrong with having it a port? Well, here's one reason: 1) Remove all the network interfaces from your system (Ethernet, PPP, SL/IP, etc). 2) cd into /usr/ports and try to build UUCP. Unless you have a prepopulated /usr/ports/distfiles, it won't work. Requiring IP connectivity to bootstrap software on a machine that doesn't have IP connectivity is a non-starter. Yes, you can install from the CDROM, but there will always be cases where you can't do this (media errors, lack of CD, etc.) Umm, how did you get FreeBSD installed in the first place, if you didn't have IP connectivity and no CDROM? IP connectivity is necessary to get the OS installed, so this is a moot point. And, if you want to maintain the UUCP software, it's as easy to do in the prot as it is in the OS, and is in fact *easier* to maintain as a port w/out IP connectivity since you can submit patches via email, but you can't commit changes to the CVS tree via email as easily. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: uucp user shell and home directory
What are *you* doing to address the problem? Are you stepping up as a maintainer? Yes. If you read the list archives you will see I've done so twice in the past already. Are you willing to fix the problems with UUCP in FreeBSD as it is Yes. How much time are you willing to contribute? As much as it takes. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: uucp user shell and home directory
What are *you* doing to address the problem? Are you stepping up as a maintainer? Yes. If you read the list archives you will see I've done so twice in the past already. Are you willing to fix the problems with UUCP in FreeBSD as it is Yes. How much time are you willing to contribute? As much as it takes. Great, so pack up your patches and submit them as a PR to the freebsd-uucp port. Good luck! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: uucp user shell and home directory
On Thu, Oct 04, 2001 at 12:14:49PM -0600, Lyndon Nerenberg wrote: I'm talking about the one in FreeBSD. uux job is to setup the commands for the next site and break the next sitename if it equals 8 letters. That's strange. For over two years I've talked hourly to a pair of UUCP sites with eight character nodenames, and it works just fine. What is the specific breakage you are seeing? But never with a hop between - I wrote about relaying! This one does not work: uux -z - !sys1!rmail user1 The command which gets created for site sys1 contains garbadge after the site name. Plain Taylor on Solaris never exposed this problem. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: log(9) bug? or feature?
In message [EMAIL PROTECTED], Kazutaka YOK OTA writes: In rev 1.67 and later, the message goes to the log buffer only if a process is reading the log buffer. If no process is reading, the message goes to the console ONLY, and it is not put into the log buffer. This behavior is inconsistent with the above comment. Is this a bug introduced in rev 1.67, or is it the intended new behavior and the comment is out of date? Actually, I think this is consistent, since console messages is now also put in the buffer, but I am not 100% sure... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: log(9) bug? or feature?
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Kazutaka Y OK OTA writes: In rev 1.67 and later, the message goes to the log buffer only if a process is reading the log buffer. If no process is reading, the message goes to the console ONLY, and it is not put into the log buffer. This behavior is inconsistent with the above comment. Is this a bug introduced in rev 1.67, or is it the intended new behavior and the comment is out of date? Actually, I think this is consistent, since console messages is now also put in the buffer, but I am not 100% sure... Actually, I *desperately* want a way to turn this off. I've backed out a bunch of changes locally on some machines, and we're considering doing this at Yahoo too. Having the userland /dev/console output blow away the kernel msgbuf is an absolute nightmare. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: uucp user shell and home directory
On Wed, Oct 03, 2001 at 01:36:26PM -0600, Lyndon Nerenberg wrote: All these solutions assume that everyone is wired up with IP connectivity. The original questions was who uses UUCP? Me. UUCP has many valid uses. Even today. If you don't understand the software, that's fine with me. Just don't use your ignorance as an excuse to dike the software out. Or more precisely, admit you want to rip the code out because you don't understand what it is, rather than making up specious excuses for it's removal. I support it's removal, because I think that software that is used by a tiny fraction of the userbase (and I suspect that uucp fits into that catagory) should be removed from the core distribution, and made into a seperate package; provided that obtaining the package and integrating it into FreeBSD is not too onerous. -- Mike Bristow, seebitwopie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: reinstatement of MSDOSFS on boot floppy fails
And the QLogic isp firmware (which has gotten quite large, what with separate firmware for 3 different SCSI and 3 different Fibre Channel cards) On Thu, 4 Oct 2001, Alexander Langer wrote: Thus spake Jordan Hubbard ([EMAIL PROTECTED]): Sure, I just don't have time to work on this right now. Didn't someone recently submit a patch to sysinstall for kernel modules shipped on a third floppy? Most exotic hardware in GENERIC could then be migrated to klds. Alex 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: uucp user shell and home directory
There are many other points - some examples I know of: The /var/spool/uucppublic which is writeable by everyone. Usually you don't want this. Just like with anonymous FTP, don't make it world writable if you don't want the world writing to it. Ever received a mail with an envelope like foo bar@company.com? It's legal and sendmail accepts them - but rmail doesn't like the space I use rsmtp to forward mail, so that's not a problem. uux forwarding to a site with exact 8 letters in size doesn't work. Yes - tranditional sites are limited to 7 letters but users don't care. But you'll know on a per-site basis if it's going to work or not. If it doesn't, you work around it. Bugs in _other_ UUCP implementations are not grounds for ditching ours. There is a port and thus packages will be build and you can install it whenever you need it. jot, lam, colldef, lkbib, xstr, bikeshed. If you don't need it - which is the by far most common case - you don't want to see such a critical and unmaintained software installed. How can it be both unneeded and critical? I'll agree it's unmaintained; the fix for that is to find a maintainer. --lyndon Learn from the mistakes of others; you'll never live long enough to make them all yourself. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: log(9) bug? or feature?
In rev 1.67 and later, the message goes to the log buffer only if a process is reading the log buffer. If no process is reading, the message goes to the console ONLY, and it is not put into the log buffer. This behavior is inconsistent with the above comment. Is this a bug introduced in rev 1.67, or is it the intended new behavior and the comment is out of date? Actually, I think this is consistent, since console messages is now also put in the buffer, but I am not 100% sure... You are talking about printf(9) printing messages to /dev/console AND the log buffer. I was asking about subr_prf.c:log(9). 1) log() in subr_prf.c rev 1.66 or earlier 1a) if a process is reading the log buffer... log() --- the log buffer ONLY 1b) if no process is reading the log buffer... log() +-- the log buffer | +-- /dev/console 2) log() in rev 1.67 or later log() --- the log buffer ONLY The comment in subr_prf.c documents the behavior 1). But the current version has the behavior 2). If the behavior 2) is what we want, the comment should be updated as such. If the behavior 1) is the correct one, log() should be fixed. I favour the behavior 1), because log() output will be lost if log() is called before syslogd starts, and we have no way of recovering it afterwards. As for printf(9) printing both to /dev/console and to the log buffer, I don't care much. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: log(9) bug? or feature?
Sorry, 2) log() in rev 1.67 or later log() --- the log buffer ONLY This should be 2) log() in rev 1.67 or later log() --- the log buffer ONLY, if a process is reading it log() --- /dev/console ONLY, if no process is reading the log buffer Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
