Re: [RELEASE] lastdown(8) -- A utility to show you whom was logged on when a system went down
Nice utility! Best regards Konrad Heuer GWDG, Am Fassberg, 37077 Goettingen, Germany, kheu...@gwdg.de On Tue, 28 Jun 2011, Devin Teske wrote: I've written a new script. It's called lastdown. What it does is pretty simple, but yet oh-so valuable to us for administering large clusters. 1. Use sysctl(8) to get the ``kern.boottime'' MIB 2. Parse the `sec' value from the above 3. Make optional adjustments 4. Pass value to date(1) to format it in CCYYddmmHHMM.SS format 5. Pass formatted date string to last(8)'s `-d' argument to... wait for it... List the users that were on that system during that time. At first, I just wrote this to see if last(8)'s manual was accurate. That is, I wanted to see what exactly it would have to say if I gave it a value. Well, after playing with it -- and then not -- I realized one of the more practical applications of it might be to list the state of the UTMP(5) log from just-before the system booted. Running this on a cluster is fun. You get to see all the people that (pardon my [non-]French, but) got screwed when last the system took a long walk in the desert (looking for it's horse no doubt *chuckles*). I just wanted to clean this up, release it under the BSD License for all, and then sleep on how to implement the next iteration (you'll notice it's internal version in the header states it's at 2.0 -- there was an uglier predecessor). If you head on over to http://druidbsd.sourceforge.net/ you'll see examples where the UTMP(5) log (that's the wtmp file) begins on a date that is after the boottime and you'll have to specific -f /var/log/wtmp.1 for example to query a log that knows about the state of the machine at boot time. I'm going to dream up ways to automatically when I should go back. The code can be had at: http://druidbsd.sourceforge.net/download/lastdown.txt or http://druidbsd.sourceforge.net/ -- Cheers, Devin Teske - LEGAL DISCLAIMER - This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. - FUN STUFF - -BEGIN GEEK CODE BLOCK- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E- W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ DI+ D+(++) G++ e h r+++ z+++ --END GEEK CODE BLOCK-- http://www.geekcode.com/ - END TRANSMISSION - _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to invalidate NFS read cache?
On Fri, 15 May 2009, Konrad Heuer wrote: (...) The problem I observe happens with FreeBSD 6.4-R and 7.0-R with nfsv3. The fstab entry I use is: server:/Volume /local/dir nfs bg,rw,intr,-T,-r32768,-w16384 0 0 The server runs on Mac OSX 10.5. In the meantime, I had the chance to examine a failure a little bit closer. As far as I can see in the moment a file modified on a Linux NFS client gets a new modification time on the NFS server but the FreeBSD client still sees the old timestamp. This obviously happens sporadically only under some circumstances I do not know further. I'll do some further testing the next days. Could you imagine a kind of directory or metadata caching on FreeBSD NFS clients that may cause this behaviour? I forgot to mention one detail: File modification happens with emacs; thus the modified file is indeed a new one with a new inode number whereas the old version keeps its inode and gets renamed. Best regards Konrad Konrad Heuer GWDG, Am Fassberg, 37077 Goettingen, Germany, kheu...@gwdg.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to invalidate NFS read cache?
On Tue, 12 May 2009, Robert Watson wrote: On Fri, 8 May 2009, Konrad Heuer wrote: sporadically, I observe a strange but serious problem in our large NFS environment. NFS servers are Linux and OS X with StorNext/Xsan cluster filesystems, NFS clients Linux and FreeBSD. NFS client A changes a file, but nfs client B (running on FreeBSD) does still see the old version. On the NFS server itself, everything looks fine. Afaik the FreeBSD kernel invalidates the NFS read cache if file modification time on the server changed which should happen here but doesn't. Can I force FreeBSD (e.g. by sysctl setting) to read file buffers again unconditionally after vfs.nfs.access_cache_timeout seconds have passed? Hi Konrad: Normally, NFS clients implement open-to-close consistency, which dictates that when a close() occurs on client A, all pending writes on the file should be issued to the server before close() returns, so that a signal to client B to open() the file can validate its cache before open() returns. This raises the following question: is client A closing the file, and is client B then opening it? If not: relying on writes being visible on the client B before the close() on A and a fresh open() on B is not guaranteed to work, although we can discuss ways to improve behavior with respect to expectation. Try modifying your application and see if it gets the desired behavior, and then we can discuss ways to improve what you're seeing. If you are: this is probably a bug in our caching and or issuing of NFS RPCs. We cache both attribute and access data -- perhaps there is an open() path where we issue neither RPC? In the case of open, we likely should test for a valid access cache entry, and if there is one, issue an attribute read, and otherwise just issue an access check which will piggyback fresh attribute data on the reply. Perhaps there is a bug here somewhere. A few other misc questions: - Could you confirm you're using NFSv3 on all clients. Are there any special mount options in use? - What version of FreeBSD are you running with? In FreeBSD 8.x, we now have DTrace probes for all of the above events -- VOPs, attribute cache hit/miss/load/flush, access cache hit/miss/load/flush, RPCs, etc, which we can use to debug the problem. I haven't yet MFC'd these to 7.x, but if you're able to run a very fresh 7-STABLE, I can probably produce a patch to add it for you in a few days. Hello, Robert, thank you very much for your reply! The problem I observe happens with FreeBSD 6.4-R and 7.0-R with nfsv3. The fstab entry I use is: server:/Volume /local/dir nfs bg,rw,intr,-T,-r32768,-w16384 0 0 The server runs on Mac OSX 10.5. In the meantime, I had the chance to examine a failure a little bit closer. As far as I can see in the moment a file modified on a Linux NFS client gets a new modification time on the NFS server but the FreeBSD client still sees the old timestamp. This obviously happens sporadically only under some circumstances I do not know further. I'll do some further testing the next days. Could you imagine a kind of directory or metadata caching on FreeBSD NFS clients that may cause this behaviour? Best regards Konrad Konrad Heuer GWDG, Am Fassberg, 37077 Goettingen, Germany, kheu...@gwdg.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
How to invalidate NFS read cache?
Hello, sporadically, I observe a strange but serious problem in our large NFS environment. NFS servers are Linux and OS X with StorNext/Xsan cluster filesystems, NFS clients Linux and FreeBSD. NFS client A changes a file, but nfs client B (running on FreeBSD) does still see the old version. On the NFS server itself, everything looks fine. Afaik the FreeBSD kernel invalidates the NFS read cache if file modification time on the server changed which should happen here but doesn't. Can I force FreeBSD (e.g. by sysctl setting) to read file buffers again unconditionally after vfs.nfs.access_cache_timeout seconds have passed? Best regards Konrad Heuer GWDG, Am Fassberg, 37077 Goettingen, Germany, kheu...@gwdg.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Problem: FreeBSD 7.x ssh v2 nss_ldap
I see a problem on two systems running FreeBSD 7.0 or 7.1 which are configured as OpenLDAP clients using the nss_ldap module. When someone logs on using ssh protocol version 2 the session will not be initialized correctly. The user will only get his primary group affiliation but no affiliation to other groups (memberUid attribute in LDAP group entries). On 7.1 the ssh login process hangs forever with open ldap queries, on 7.0 the group list is incomplete. On several 6.x systems, all works correctly. I have used the configuration for years now. There are some workarounds I found: a) use ssh protocol version 1 b) set UseLogin to yes in sshd_config c) avoid ssl encryption in communication to ldap server (ldap://... uri instead of ldaps://... in ldap.conf) Does anybody see similar problems? Does anybody have an idea what may couse the problem? Best regards Konrad Heuer GWDG, Am Fassberg, 37077 Goettingen, Germany, kheu...@gwdg.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
6.1 SMP PERC 3 on PE 2650
Hello everyone, after upgrading from 4.11 to 6.1 on two Dell PE 2650 each with PERC/3 RAID controllers and two Xeon cpus there happen spontaneous reboots on both machines, from time to time a few per day. That's anything else but nice. Disabling SMP seems to help, but that's no solution. Are there any problems known? Best regards and thanks for any reply Konrad Heuer GWDG, Am Fassberg, 37077 Goettingen, Germany, [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Source code for user utilities
On Tue, 16 Jan 2007, Pranav Sawargaonkar wrote: Can any one tell me from where i can get source code of user level utilities (eg. ls, top etc.) Does FreeBSD also uses coreutils for these user utilities like linux does ? The source code is part of the FreeBSD distribution; you can find it (e.g.) in: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/src/ FreeBSD does not use coreutils. FreeBSD source code is based on the 4.4BSD-Lite2 source code developed at the university of California in Berkeley. Best regards Konrad Heuer GWDG, Am Fassberg, 37077 Goettingen, Germany, [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
nfs send error 32
Hi all, I've an NFS-mounted filesystem (server runs deadrat linux) on a lot of my FreeBSD systems (4.11R), mount options are bg,rw,intr,-T,-r32768,-w32768. Using TCP and 32k buffers does enhance performance notably. But I've a couple of error messages in /var/log/messages of my clients each day like: date client /kernel: nfs send error 32 for server deadrat:/fs When looking into /usr/src/sys/nfs/nfsproto.h, I don't find anything about error code 32. Any idea or explanation would be very very welcome! BTW: NFS server has to run deadrat linux, and more nfs file systems have to be mounted in future from the same or similar machines. Thanks Konrad Heuer GWDG, Am Fassberg, 37077 Goettingen, Germany, [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Critical mmap failure?
On Wed, 7 Apr 2004, Andrew MacIntyre wrote: On Tue, 6 Apr 2004, Konrad Heuer wrote: * The machines in question are all DELL PowerEdge 2650, three with RAID controllers, one without. The main difference in hardware is that the system on wich the error occurs has 4 GB of memory, the others 2 GB. There are no significant differences in the kernel configuration files except driver entries for RAID or not. I think you are running into issues associated with the kernel autosizing various data structures and running low on VM address space. If you can, try reducing the problematic machine to 2GB of memory and see whether the problems persist. If they don't, then it is this issue and you're going to have to fiddle with the kernel config. I've seen posts in freebsd-stable about trying to tune i386 systems with 4GB of memory - you should search the list archives. Thank you both for your similar answers. I learned a lot by studying the mailing list archives and experimenting. After a lot of trials, I found the solution: On the 4 GB machine, I compiled the kernel with MAXDSIZ=(2048*1024*1024) to achieve a max data segment size of 2 GB. This seems to cause the problems, maybe by a signed int overflow? Reducing MAXDSIZ helps. Best regards Konrad Heuer ([EMAIL PROTECTED]) ___ ___ GWDG / __/__ ___ / _ )/ __/ _ \ Am Fassberg / _// __/ -_) -_) _ |\ \/ // / 37077 Goettingen /_/ /_/ \__/\__//___// Germany ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Critical mmap failure?
I've a couple of systems running FreeBSD 4.9; they all share /usr and anything below by nfs. There are (at less) two applications that do not run or do not run correctly on one distinguished system, but correctly on each other machine. One application is mozilla; it stops shortly after invocation with the following error message: INTERNAL ERROR on Browser End: JavaPluginFactory5 init - no agent? System error?:: Cannot allocate memory Analyzing the problem with truss shows an error while mozilla calls mmap: mmap(0xbfaef000,65536,0x3,0x400,-1,0x0) ERR#12 'Cannot allocate memory' mmap(0xbfade000,65536,0x3,0x400,-1,0x0) ERR#12 'Cannot allocate memory' On the other systems, there are no errors: mmap(0xbfaef000,65536,0x3,0x400,-1,0x0) = -1079054336 (0xbfaef000) mmap(0xbfade000,65536,0x3,0x400,-1,0x0) = -1079123968 (0xbfade000) * Other mmap calls that do not require MAP_STACK (0x400) do not lead to errors anywhere. * All kernels are compiled with -DVM_STACK since this is default on i386. * The value of the variable vm.max_proc_mmap is not higher on any of the systems which do well than on the problematic one. * The same holds for resource limits. * The machines in question are all DELL PowerEdge 2650, three with RAID controllers, one without. The main difference in hardware is that the system on wich the error occurs has 4 GB of memory, the others 2 GB. There are no significant differences in the kernel configuration files except driver entries for RAID or not. Any idea that may help is very welcome, since the other application that fails is a commercial linux binary calling linux mmap frequently and producing wrong data (possibly the return code of mmap isn't checked). This application is very important for us, and does not do anything than reading and writing data and calling mmap. Best regards Konrad Heuer ([EMAIL PROTECTED]) ___ ___ GWDG / __/__ ___ / _ )/ __/ _ \ Am Fassberg / _// __/ -_) -_) _ |\ \/ // / 37077 Goettingen /_/ /_/ \__/\__//___// Germany ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Critical mmap failure?
I've a couple of systems running FreeBSD 4.9; they all share /usr and anything below by nfs. There are (at less) two applications that do not run or do not run correctly on one distinguished system, but correctly on each other machine. One application is mozilla; it stops shortly after invocation with the following error message: INTERNAL ERROR on Browser End: JavaPluginFactory5 init - no agent? System error?:: Cannot allocate memory Analyzing the problem with truss shows an error while mozilla calls mmap: mmap(0xbfaef000,65536,0x3,0x400,-1,0x0) ERR#12 'Cannot allocate memory' mmap(0xbfade000,65536,0x3,0x400,-1,0x0) ERR#12 'Cannot allocate memory' On the other systems, there are no errors: mmap(0xbfaef000,65536,0x3,0x400,-1,0x0) = -1079054336 (0xbfaef000) mmap(0xbfade000,65536,0x3,0x400,-1,0x0) = -1079123968 (0xbfade000) * Other mmap calls that do not require MAP_STACK (0x400) do not lead to errors anywhere. * All kernels are compiled with -DVM_STACK since this is default on i386. * The value of the variable vm.max_proc_mmap is not higher on any of the systems which do well than on the problematic one. * The same holds for resource limits. * The machines in question are all DELL PowerEdge 2650, three with RAID controllers, one without. The main difference in hardware is that the system on wich the error occurs has 4 GB of memory, the others 2 GB. There are no significant differences in the kernel configuration files except driver entries for RAID or not. Any idea that may help is very welcome, since the other application that fails is a commercial linux binary calling linux mmap frequently and producing wrong data (possibly the return code of mmap isn't checked). This application is very important for us, and does not do anything than reading and writing data and calling mmap. Best regards Konrad Heuer ([EMAIL PROTECTED]) ___ ___ GWDG / __/__ ___ / _ )/ __/ _ \ Am Fassberg / _// __/ -_) -_) _ |\ \/ // / 37077 Goettingen /_/ /_/ \__/\__//___// Germany ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Swapping performance
On Thu, 7 Mar 2002, Dimitar Peikov wrote: I start some performance tests on -stable and on SuSE 7.1 / 2.4.17. I don't comment about 'bzero' performance, but when RAM is over, Linux is much faster. I have no idea what is the algorithm of swapping but it seems that the granularity of swapping pieces is the key or the importance of swapping memory blocks of certain task. Ooo I forgot to say that the both machines have the same hardware, IBM 300PL, 256 RAM and no other tasks running. I had to run these tests to choose the fastest platform for building our software indexes, which requires a lot of math and memory operations. --- with bzero --- Linux$ time ./malloc_test *# real0m37.640s user0m1.370s sys 0m2.950s Linux$ FreeBSD$ time ./malloc_test *# real0m46.640s user0m2.280s sys 0m2.550s FreeBSD$ --- without bzero --- Linux$ time ./malloc_test *# real0m6.371s user0m0.450s sys 0m1.510s Linux$ FreeBSD$ time ./malloc_test *# real0m11.571s user0m1.150s sys 0m1.830s FreeBSD$ Just to make sure: What about disk layout and paging space location? Both systems will behave best when paging space location is near to the beginning of the disks. My measurements in this area are some years old; at that time FreeBSD did a much better job when klow on free memory. Best regards Konrad Konrad HeuerPersonal Bookmarks: Gesellschaft für wissenschaftliche Datenverarbeitung mbH GÖttingen http://www.freebsd.org Am Faßberg, D-37077 GÖttingen http://www.daemonnews.org Deutschland (Germany) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: lpd filter stderr log files
On Fri, 15 Feb 2002, Garance A Drosihn wrote:
At 3:16 PM +0100 2/15/02, Konrad Heuer wrote:
Unfortunately, some changes in the lpd code that happened last year
(as far as I remember) are very disadvantageous for the operation
of our (heavily loaded) printer server which is based on FreeBSD
for years now.
Well, I'm willing to see what we can do to help you out.
Thank you very much for your reply and all your efforts. Please excuse my
delayed reply but I didn't read my mail yesterday and the day before.
Prior to the changes, we could observe the progress of print jobs
by a `tail -f /var/log/lpd-err/queue_log_file'. Now, all information
written by the filter programs to stderr gets catched by temporary
log files the names of which are created randomly. After a print
job has completed, the contents of the temporary file is appended
to the queue log file.
Hmm. I suspect that any change there is more than a year old. We
did change how the temporary-files were generated, but I think lpd
has used temporary files for stderr for a long time.
I didn't look into earlier versions of the code, I've to admit.
Nevertheless, the tail -f did work. Hmm, sounds strange.
For our purposes, that's often too late. Why have these changes
been made? And can the old behaviour be restored?
I think the reason it's done this way (with the temporary files) is
so multiple queues could point to a single log file, and so all the
lines for any one job would be added onto that log file in one shot.
I think there's a number of other reasons too. A quick look at
the history for lpd/printjob.c seems to indicate that it has
always behaved this way (or at least, it was always the *intention*
that it behave this way, perhaps there were some bugs fixed).
This may be. On the other hand, on a system with a large number of printer
queues (about 120 in our case) I'd never get the idea to use a single log
file ;-).
We really would like to see what happens during printing a job
(imagine a 300 mb postscript print job which may a lot of time
to execute completely).
Well, here we see 1-gig postscript files going to our plotters, so
it's pretty easy for me to imagine a 300-meg one... :-)
I see and I'm pleased you understand me!
It's obvious that you just changed to a new version of lpr. Did
you also change any of your scripts? In some of my scripts, what
I do is:
exec 2$LPD_LOG_dir/$pname/log
This causes the *script* to redirect stderr to where I want it.
Would that work in your situation?
I got this idea this morning in bathroom, too. I hope it will work in our
situation.
By the way, may I suggest some other modifications to the lpd code? I know
my suggestions might introduce problems with existing input filters, but I
apply these changes to printjob.c for years now and I'm very happy with
them:
*** /usr/src/usr.sbin/lpr/lpd/printjob.cFri Feb 15 14:42:18 2002
--- /usr/src/usr.sbin/lpr/lpd/printjob.c.orgThu Dec 20 05:14:26 2001
***
*** 600,606
register char *prog;
int fi, fo;
FILE *fp;
! char *av[20], buf[BUFSIZ]; /* GWDG: size of av increased */
int pid, p[2], stopped;
union wait status;
struct stat stb;
--- 600,606
register char *prog;
int fi, fo;
FILE *fp;
! char *av[15], buf[BUFSIZ];
int pid, p[2], stopped;
union wait status;
struct stat stb;
***
*** 757,763
pp-printer, format);
return(ERROR);
}
- prog = pp-filters[LPF_INPUT]; /* GWDG: quick dirty: always use if */
if (prog == NULL) {
(void) close(fi);
syslog(LOG_ERR,
--- 757,762
***
*** 772,782
av[n++] = -n;
av[n++] = logname;
av[n++] = -h;
! av[n++] = class; /* GWDG: use traditional class instead of origin_host */
! av[n++] = -f;
! av[n++] = origin_host; /* GWDG: pass origin_host to filter additionally */
! av[n++] = -j;
! av[n++] = jobname; /* GWDG: pass jobname to filter additionally */
av[n++] = pp-acct_file;
av[n] = 0;
fo = pfd;
--- 771,777
av[n++] = -n;
av[n++] = logname;
av[n++] = -h;
! av[n++] = origin_host;
av[n++] = pp-acct_file;
av[n] = 0;
fo = pfd;
We need the traditional possibility for users to enter a class
specification by the `-C' flag of lpr which is then passed to the filter
script. But we need a reliable information about the origin of a print job
in the script, too. Furthermore, it's very nice to know the name of the
job within the filter script not only for logging, but also for PostScript
header page generation. The quickdirty hack to force execution of the
input filter helps us since people tend to use lpr flags like `-d' or `-v'
accidently. Maybe one could turn this qd hack into an lpd command line
flag
lpd filter stderr log files
Unfortunately, some changes in the lpd code that happened last year (as far as I remember) are very disadvantageous for the operation of our (heavily loaded) printer server which is based on FreeBSD for years now. My input filter programs are designed to write useful debugging information to stderr while processing print jobs. Prior to the changes, we could observe the progress of print jobs by a `tail -f /var/log/lpd-err/queue_log_file'. Now, all information written by the filter programs to stderr gets catched by temporary log files the names of which are created randomly. After a print job has completed, the contents of the temporary file is appended to the queue log file. For our purposes, that's often too late. Why have these changes been made? And can the old behaviour be restored? We really would like to see what happens during printing a job (imagine a 300 mb postscript print job which may a lot of time to execute completely). I already looked a the source code, and probably I could change a lot by myself, but this seems to be a bad idea since the next cvs update will happen, of course. I don't know who is responsible for the lpd code in the FreeBSD developers team, so please forward this mail to him/her if he/she doesn't read freebsd-hackers. And please think about my request - the old behaviour helped us a lot. Best regards Konrad HeuerPersonal Bookmarks: Gesellschaft für wissenschaftliche Datenverarbeitung mbH GÖttingen http://www.freebsd.org Am Faßberg, D-37077 GÖttingen http://www.daemonnews.org Deutschland (Germany) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New feutures...........
On Fri, 14 Dec 2001, Jordan Hubbard wrote:
{.. snip ..}
2. I hope that in the furture the FreeBSD developers
will rewrite the system in C++.
God, I certainly hope NOT.
Jordan, I do agree absolutely and hope your hopes will come true ... :-)
Konrad
Konrad HeuerPersonal Bookmarks:
Gesellschaft für wissenschaftliche
Datenverarbeitung mbH GÖttingen http://www.freebsd.org
Am Faßberg, D-37077 GÖttingen http://www.daemonnews.org
Deutschland (Germany)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: gigabit card drivers
On Fri, 20 Jul 2001, MJL wrote: Does 4.3 version support 3com or d-link's gigabit ethernet card? Yes, I've a system running perfectly with a 3Com 3c985-SX gigabit card. Regards Konrad Konrad HeuerPersonal Bookmarks: Gesellschaft für wissenschaftliche Datenverarbeitung mbH GÖttingen http://www.freebsd.org Am Faßberg, D-37077 GÖttingen http://www.daemonnews.org Deutschland (Germany) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ALS4000 Sound Chip
I just bought a PCI sound card based on an ALS4000 chip. It seems to be sound blaster compatible (port 0x220 irq 5 drq 1). Do I have a chance to get the card working when modifying /usr/src/sys/dev/sound/isa/sbc.c in such a way that the chip will be recognized in sound blaster mode during pci bus scan? Thanks for any reply or hint! Konrad Konrad HeuerPersonal Bookmarks: Gesellschaft für wissenschaftliche Datenverarbeitung mbH GÖttingen http://www.freebsd.org Am Faßberg, D-37077 GÖttingen http://www.daemonnews.org Deutschland (Germany) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Why does lpd cause a lot of DNS traffic?
While solving some special remote printing problems I saw (4.2-STABLE) that lpd verifies printer access from a remote host by a lot of name resolution requests (my /etc/hosts.lpd has more than 300 entries). When verifying a host lpd scans hosts.lpd from the first line to the first matching line *not* by string comparison (hostname) but by requesting a name resolution for each entry (line by line) and comparing the INET address. For a heavily loaded printer server (as mine is) this seems not be a good idea ... but maybe there's a good reason to to this? Regards Konrad HeuerPersonal Bookmarks: Gesellschaft für wissenschaftliche Datenverarbeitung mbH GÖttingen http://www.freebsd.org Am Faßberg, D-37077 GÖttingen http://www.daemonnews.org Deutschland (Germany) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCPDUMP patch v1.1 and AppleTalk
On Tue, 7 Nov 2000, Kris Kennaway wrote: On Tue, Nov 07, 2000 at 01:56:21PM +0100, Konrad Heuer wrote: After patching and installing, tcpdump can't be used anymore since it puts very heavy load onto the network via xl0 and AppleTalk broadcast messages (one message each 0.2 ms). Sorry, in the moment I don't know more details ... tcpdump shouldn't be sending any appletalk packets, I thought (I may be wrong, never used it on an appletalk network). Are you sure this is the problem? Kris Well, I don't know exactly what happens but I seems to be more complex than I thought first. It doesn't happen each time I start tcpdump but when some circumstances meet which I don't know my FreeBSD host begins to flood the network with AppelTalk broadcast requests as long as tcpdump keeps running. Killing tcpdump kills this flooding, too. I've never observed such a situation before I applied the last patch, and I use tcpdump frequently to analyze the one or other problem. On the other hand, our network environment isn't static, of course, and I can't be sure about other things that may have been changed from day to day. Konrad To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
TCPDUMP patch v1.1 and AppleTalk
This morning I applied the tcpdump v1.1 patch for 4.x-R on a 4.1-R system with following configuration: ti0 Gigabit-LinkIPv4 interface xl0 Fast Ethernet AppleTalk interface options NETATALK is included in the kernel config since the host uses the netatalk package exports the home directories for MAC users (the system does a good job since August). After patching and installing, tcpdump can't be used anymore since it puts very heavy load onto the network via xl0 and AppleTalk broadcast messages (one message each 0.2 ms). Sorry, in the moment I don't know more details ... Konrad HeuerPersonal Bookmarks: Gesellschaft für wissenschaftliche Datenverarbeitung mbH GÖttingen http://www.freebsd.org Am Faßberg, D-37077 GÖttingen http://www.daemonnews.org Deutschland (Germany) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Connect to lpd on insecure port
Today I did some testing concerning lpd and I was very astonished to see that lpd accepts jobs also from insecure ports (violating RFC 1179). It does not accept such jobs on 2.1.6-RELEASE (yes, I still have some old 386 system out there with 2.1.6) but it does on 3.x (and as far as I've seen from the code) and 4.x and also on 2.2.6. Why and when has the behaviour of lpd been changed? I'd like lpd only to accept connections from secure ports (do you remember the famous error message `Malformed from address'? ;-) ) Thanks for any reply! Konrad HeuerPersonal Bookmarks: Gesellschaft für wissenschaftliche Datenverarbeitung mbH GÖttingen http://www.freebsd.org Am Faßberg, D-37077 GÖttingen http://www.daemonnews.org Deutschland (Germany) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: lpr: order of print requests
On Tue, 2 May 2000, Lorenzo Iania wrote: Warren Losh wrote: LPR queues up the reuqests and prints them in order smallest to largest to reduce the average wait time for a job at the expense of having a larger standard deviation in the wait times for jobs. Maybe this is what you are running into. I don't know if there's a way to disable this behavior or not. At least that's what I recall lpd doing years ago when I ran a unix lab in school. I didn't go check the code to see if it still did that or not. Warner I think you're right, because the process that generates the requests is only one. It consecutively opens pipes to lpr and then closes them. In effect it builds invoices from delivery documents and the printed numbers of invoices is effectively out of order, while the requests are ordered by number of invoice. Each pipe is opened and closed: so the processes are not concurrent: one begins after the other has finished. So, is there a way to disable this strange behavior? Hmm, I've never seen such a strange behaviour. Lpd should do FIFO. Could you give some more infos about your environment (os release, input filter program, printer type)? Regards Konrad HeuerPersonal Bookmarks: Gesellschaft für wissenschaftliche Datenverarbeitung mbH GÖttingen http://www.freebsd.org Am Faßberg, D-37077 GÖttingen http://www.daemonnews.org Deutschland (Germany) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
