make installworld
Hi, Encountered the following while running make installworld: Installing /usr/libdata/perl/5.00503/mach/auto/POSIX/setgid.al Installing /usr/libdata/perl/5.00503/mach/auto/POSIX/setuid.al Usage: copy(FROM, TO [, BUFFERSIZE]) at /usr/obj/usr/src/gnu/usr.bin/perl/library/POSIX/lib/ExtUtils/Install.pm line 123 *** Error code 2 Stop in /usr/obj/usr/src/gnu/usr.bin/perl/library/POSIX/ext/POSIX. *** Error code 1 Sucessfully completed make buildworld, any suggestions ppl? Thanks, -- Jamie Heckford Chief Network Engineer Psi-Domain - Innovative Linux Solutions. Ask Us How. === email: [EMAIL PROTECTED] web: http://www.psi-domain.co.uk/ tel: +44 (0)1737 789 246 fax: +44 (0)1737 789 245 mobile:+44 (0)7779 646 529 === To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PAM and passwords (Re: Hmm..passwords.)
On Tue, Nov 21, 2000 at 03:31:12PM -0800, David O'Brien wrote: When Kris and I discussed this functionality (before Brian went and did it); we talked about much higher granularity than Brian implemented: MD5 everywhere DES everywhere MD5 locally / DES yp Convert to MD5 Convert to DES Only these last two are candidates for PAM. PAM (specifically pam_unix) doesn't and shouldn't care what crypt() does and what the algorithm it chooses to use is called, it just treats the strings as opaque data which are compared to the master.passwd records. The latter two in your list could be implemented by a "recrypt" function in a pam "password" module, which a) verifies the presented password, and b) generates a new password hash with the same plaintext, which is written out. This would have the effect that the new password would be whichever format is the current passwd_format for that user's login class, so you can transparently migrate users from one algorithm to another without having to expire passwords or mess with them by hand. You likely wouldn't want this to happen every time a user logs in, so there'd have to be some other condition which triggers it for a given account. Kris PGP signature
KGI port
Hi hackers, Hope you've ever heard about KGI... the kernel side of the GGI project. It consists mostly in a basic framework for accessing graphic hardware from userland and is designed to support efficiently the GGI upper library. More info is avalable at http://kgi.sourceforge.net I'm willing to port it to FreeBSD. First, any comments? advices? Then, how could I efficiently reuse the existing stuff of FreeBSD (kbd, fb)? What are resistrictions on the license? Most of the code is governed by: ** Copyright (C) 2000 ** ** This file is distributed under the terms and conditions of the ** MIT/X public license. Please see the file COPYRIGHT.MIT included ** with this software for details of these terms and conditions. ** Alternatively you may distribute this file under the terms and ** conditions of the GNU General Public License. Please see the file ** COPYRIGHT.GPL included with this software for details of these terms ** and conditions. Nicholas -- Nicolas Souchu Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
BSD's random.c dicey on the Alpha
Hi folks, Anyone want to have a look at this? It's from the GNU awk maintainer. Ciao, Sheldon. --- Forwarded Message From: Aharon Robbins [EMAIL PROTECTED] Date: Wed, 22 Nov 2000 11:59:10 +0200 Message-ID: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: BSD random for Alpha? Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Hi. I've switched to the new random.c you sent me for gawk. My Linux/Alpha Guru reports that the code in it assumes that sizeof(long) is always 4, and one particular test doesn't "look" very random on the Alpha. My question is, is there a better version of random that can deal with both 32 and 64 bit systems in the same source code? Would the NetBSD people maybe have such a thing? Thanks, Arnold - -- Aharon (Arnold) Robbins --- Pioneer Consulting Ltd. [EMAIL PROTECTED] P.O. Box 354Home Phone: +972 8 979-0381Fax: +1 603 761-6761 Nof Ayalon Cell Phone: +972 51 297-545(See www.efax.com) D.N. Shimshon 99785 Laundry increases exponentially in the ISRAEL number of children. -- Miriam Robbins --- End of Forwarded Message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fclose vs ferror (from libc/getcap)
Garance A Drosihn wrote:
The point about
(void)fclose(pfp);
if (ferror(pfp)) {
...do stuff...
}
is that it's a silly thing to do deliberately, but if I was
porting some hairy old C code I'd tend to expect it to work.
C is not a language in which you go out of your way to prevent
people making mistakes.
I would not expect it to work. This has nothing to do with
the C language, it has to do with fclose. Fclose gets rid
of the descriptor. In my own code, I usually follow 'fclose(fp)'
with 'fp = NULL', because that stream is GONE. I do realize that
this code does seem to work on several operating systems, but it
also causes dramatic problems with linux. Given the description
of fclose, I'd say it is the code which is wrong.
This has to do with the C language at least in the sense that the
standard library is a part of C. About half the bulk of the original
ANSI/ISO C Standard is taken up with specifying the library.
I don't think I really disagree with the points you make, mostly
not quoted; but I also think the fundamental issue is that you're
not entirely in sympathy with the C way of doing things, and that
you'd prefer to be using something else. (Someone who does the
fp = NULL thing is quite likely deep-down a Modula-3 guy, or an
Oberon guy, or an Ada guy, or something. :-)
The _Rationale_, which was put out by the original ANSI committee
somewhat in defence of the C Standard itself, talks about sticking
to "the spirit of C". And the first of the tenets it mentions is
"Trust the programmer".
It's probably fair to say that the lack of sanity-checking in the
routines of the standard library is one example of that kind of
trust. Though whether it is sensible to trust the programmer not
to make silly mistakes is a different matter altogether, of course.
--
Robert Nordier
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: fclose vs ferror (from libc/getcap)
Daniel C. Sobral wrote: Garance A Drosihn wrote: Undefined behavior means anything goes. On a standard, it means the behaviour is implementation-defined (which may be undefined or not). While not disagreeing with what I think Daniel means: at least in the C Standard itself, "undefined behavior" and "implementation-defined behavior" are kept carefully separate. A quote from X3J11's Rationale document probably addresses the crux of the issue Garance raised, though: Undefined behavior gives the implementor license not to catch certain program errors I am not saying that what freebsd does is wrong. But Robert said that "[that code is a silly thing], but if I was porting some hairy old C code I'd tend to expect it to work." It seems to me that if the behavior is explicitly undefined then you can NOT expect much of anything when porting. He said he would _tend_ to expect it to work. To me, that means the code is dubious, but is likely to work. Garance himself writes, two messages back: The thing with ferror is that it will generally "work" after the fclose, although the value it returns might not be the right (pre-close) value. and I really meant something very similar. Though I'd probably go a bit further and say -- knowing how ferror is likely to be implemented -- the most probable result of invoking it after fclose would be a failure to detect that an I/O error had occurred. For "hairy old C code", that "works" about as much as I'd expect it to. And notice that ferror() is not an access to the stream. In the section I quoted from unix spec, "stream" refers to the variable passed to fclose (though that isn't obvious, because I didn't copy the formatting). ferror certainly does access that variable. MM. That's a dubious interpretation. The variable is a handle to the stream, not the stream itself. Are you sure of the SUS wording? The original ISO standard defines "FILE" as an object capable of recording all the information needed to control a stream [7.9.1] and elsewhere goes on to describe a stream as, for example an ordered sequence of characters [7.9.2] so I think it's fairly clear that a stream is not what (FILE *) points at. I doubt that the SUS would intentionally deviate on such a fundamental point. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SMBus
On Tue, Nov 21, 2000 at 08:05:42PM -0200, Felipe Gustavo de Almeida wrote: thanks for your 'support' ! Nicolas Souchu writes: On Mon, Nov 20, 2000 at 08:38:53PM -0200, Felipe Gustavo de Almeida wrote: Nicolas Souchu writes: On Sat, Nov 18, 2000 at 02:31:48PM -0200, Felipe Gustavo de Almeida wrote: Hi, do you know about someone working on smbus drivers for VIA VT82C686A (the chipset from ASUS K7V MB) ? To bad. I did the driver in the past, but as a very bad programmer did not do any backup :(( Actually it was for the 586B chip :( For which the datasheets are fully available. What do you plan to do with it? I could try out another devel if needed. I was digging driver sources and I think what I really want is a kind of 'intpm' to K7V, ie. a driver to let me get my mobo health data. As far as I could see in the NetBSD driver, the only supported feature is hardware monitoring feature not SMBUS yet. You may ask ACPI specialists on the hackers list for more info on the subject. Nicholas -- Nicolas Souchu Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KGI port
Good ! I recall the kernel related parts can be licensed under a plain (new) BSD license. I don't understand our fb enough but if you know your way through kld's and newbus, the result will be really neat. Pedro. On Wed, 22 Nov 2000, Nicolas Souchu wrote: Hi hackers, Hope you've ever heard about KGI... the kernel side of the GGI project. It consists mostly in a basic framework for accessing graphic hardware from userland and is designed to support efficiently the GGI upper library. More info is avalable at http://kgi.sourceforge.net I'm willing to port it to FreeBSD. First, any comments? advices? Then, how could I efficiently reuse the existing stuff of FreeBSD (kbd, fb)? What are resistrictions on the license? Most of the code is governed by: ** Copyright (C) 2000 ** ** This file is distributed under the terms and conditions of the ** MIT/X public license. Please see the file COPYRIGHT.MIT included ** with this software for details of these terms and conditions. ** Alternatively you may distribute this file under the terms and ** conditions of the GNU General Public License. Please see the file ** COPYRIGHT.GPL included with this software for details of these terms ** and conditions. Nicholas -- Nicolas Souchu Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fwd: Re: still in the woods (tuning for postfix hub)
Sorry, Hackers, but I got no response from the -questions list for 2 days. Somebody here must know who is Mr. Hub Admin, no? tia, Len == Can somebody tell me who admins FreeBSD/postifx mail hubs? I need some help opening up FreeBSD for postfix and 200K msgs/day. Thanks, Len == Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Subject: Re: still in the woods To: [EMAIL PROTECTED] (Postfix users) Reply-To: [EMAIL PROTECTED] (Postfix users) X-Time-Zone: USA EST, 6 hours behind central European time Date: Tue, 21 Nov 2000 16:31:50 -0500 (EST) From: [EMAIL PROTECTED] (Wietse Venema) Sender: [EMAIL PROTECTED] X-RCPT-TO: [EMAIL PROTECTED] The FreeBSD mailing list server runs 500+ Postfix SMTP clients and it does not hurt the machine. Perhaps you need to ask the people who run that machine. Wietse Len Conrad: Got a faily busy postfix relay hub, about 200K msgs / day. FreeBSD IMGate1.xxx.net 4.1.1-RELEASE FreeBSD 4.1.1-RELEASE #0: Tue Sep 26 00:46:59 GMT 2000 # postconf mail_version mail_version = Snapshot-20001030 ast pid: 67847; load averages: 0.19, 0.37, 0.47 up 7+00:47:48 16:07:03 320 processes: 1 running, 319 sleeping CPU states: 3.5% user, 0.0% nice, 3.8% system, 0.8% interrupt, 91.9% idle Mem: 78M Active, 103M Inact, 29M Wired, 6524K Cache, 35M Buf, 32M Free Swap: 47M Total, 1464K Used, 46M Free, 3% Inuse We had these "too many files" pb's are initial install, and the FreeBSD-hackers gave me some things to change that seem to stop the but they're back even with these settings( an rebootin): /boot/rc.loader with set kern.ipc.maxsockets=4000 (from default of 1000, I think) and /etc/sysctl.conf with kern.maxfiles = 4096 kern.maxfilesperproc = 4096 A section of "sysctl -a" shows: ITEMSIZE LIMITUSEDFREE REQUESTS PIPE:160,0, 2,100,63091 unpcb:64,0, 6,122, 607 ripcb:96, 1064, 0, 84, 68 tcpcb: 288, 1064, 10, 32, 2428 udpcb:96, 1064, 11, 73, 2637 unpcb:64,0, 0, 0,0 socket: 160, 1064, 27, 48, 5752 AIOLIO: 704,0, 0, 0,0 AIOL: 64,0, 0, 0,0 AIOCB: 128,0, 0, 0,0 AIOP: 32,0, 0, 0,0 AIO: 96,0, 0, 0,0 NFSNODE: 288,0, 0, 0,0 NFSMOUNT:544,0, 0, 0,0 VNODE: 192,0, 3801,121, 3764 NAMEI: 1024,0, 0, 24, 3391019 VMSPACE: 192,0, 20, 44,50568 PROC:352,0, 23, 35,50571 DP fakepg:64,0, 0, 0,0 PV ENTRY: 28, 139130, 3868, 12497, 7249523 MAP ENTRY:40,0,351,491, 802213 KMAP ENTRY: 40, 3996, 61,169,13057 MAP: 100,0, 7, 3,7 VM OBJECT: 124,0,532, 2133, 604523 But the client is still getting these: Fatal Errors bounce 1 open file defer 63A8B51811: Too many open files in system 1 open file defer 954FF516E4: Too many open files in system 1 open file defer 21333516EF: Too many open files in system 1 open file defer B7675516C8: Too many open files in system 1 open file defer B6A3E51605: Too many open files in system 1 open file defer 33E0B518AE: Too many open files in system 1 open file defer 9521D51766: Too many open files in system 1 open file defer 6848A5171E: Too many open files in system 1 open file defer B5B285178E: Too many open files in system 1 open file defer 300B45164D: Too many open files in system 1 open file defer 624495172D: Too many open files in system 1 open file defer B18F351765: Too many open files in system 1 open file defer B2688516B4: Too many open files in system 1 open file defer 2717951750: Too many open files in system cleanup 26 accept connection: Too many open files in system qmgr 10 socket: Too many open files in system 1 open active 7123851A0C: Too many open files in system 1 open active 2B05B517B4: Too many open files in system 1 open active 495C551796: Too many open files in system 1 open active 79A17517F8: Too many open files in system 1 open active 6690651964: Too many open
Re: fclose vs ferror (from libc/getcap)
When you look at the fclose()/ferror() problem you have to look at it in its historical context. Historically some versions of UNIX had very odd semantics. For example, many programmers depended on free()'d data being left intact at least until the next free(). It was even documented to have that behavior at one time (though I forget where, this was a long time ago). Similarly, close() didn't always return an integer... it used to be a void function on many systems, or return garbage (i.e. be mis-implemented) and thus undependable. And fclose() also used to be a void function on many systems or have an undependable return value. Enough confusion occured from these differences that some programmers often took liberties way back then that are obivously illegal today.. for example, calling ferror() after fclose() (because fclose() didn't used to return the final flush status), rather then using the more portable fflush/ferror/fclose combination. Another example is freopen()ing an fclose()'d file, especially in regards to stdin, stdout, and stderr. This confusion is further exasperated by shortcuts taken inside libc itself... for example, libc declares stdin, stdout and stderr as static structures and the exit code just assumes those pointers point to good memory, even if the streams have been closed. Many programmers use library code as a basis for learning the APIs and mistakenly come to believe that they can make similar assumptions externally that the library makes internally. In today's world the standard is: When you free() something, that's it.. it's gone. When you fclose() something or otherwise terminate a structure, it's gone. Anything else is illegal. *internally* our libc assumes that ferror() is legal after an fclose() because, well, it's true... but only for internal library functions. Nobody outside the library can legally make that assumption and it could also be argued that even within the library those types of assumptions should not be made unless absolutely necessary. There isn't much we can do about the issue except fix the instances of mis-programming as they show up. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: find, -delete, and relative paths
On Tue, Nov 21, 2000 at 12:08:56PM +1030, Daniel O'Connor wrote: On 20-Nov-00 Brian Reichert wrote: I didn't find anything after an admittedly quick look intp PRs and the mail list archives: Under FreeBSD 3.4-RELEASE, we are running a simple log file scrubber: 15 3 * * * find /usr/local/logs/lsp \! -ctime 1 -delete I pointedly am using an absolute path, yes I get this warning repeatedly: find: -delete: /usr/local/logs/lsp: relative path potentially not safe How can I suppress this warning? Is it a bug in find, or did I misunderstand the manpage? I don't know why, but I think find prints those messages when you attempt to delete a directory. If you do - 15 3 * * * find /usr/local/logs/lsp -type f -a \! -ctime 1 -delete it should work.. To wrap up, the above suggestion does shush up 'find' WRT absolute vs. realtive pathnames, at least in my case... --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fclose vs ferror (from libc/getcap)
At 2:25 PM +0200 11/22/00, Robert Nordier wrote: Daniel C. Sobral wrote: Garance A Drosihn wrote: In the section I quoted from unix spec, "stream" refers to the variable passed to fclose (though that isn't obvious, because I didn't copy the formatting). ferror certainly does access that variable. MM. That's a dubious interpretation. The variable is a handle to the stream, not the stream itself. Are you sure of the SUS wording? The original ISO standard defines "FILE" as an object capable of recording all the information needed to control a stream [7.9.1] [...skipping...] I doubt that the SUS would intentionally deviate on such a fundamental point. I've replied to both Robert and Daniel with (I think) the exact section of SUS that I was quoting. I didn't want to send a message with all those formatting characters to the mailing list, because I really don't know how well that would work out... For others who might be curious, I was not saying that "the concept of a stream" refers to the variable sent to fclose. I meant that in the exact section I was quoting, that word 'stream' is in italics, and thus it refers to the variable 'stream' which SUS used in the synopsis of fclose. Eg: #include stdio.h int fclose(FILE *stream); -- (the underlined 'stream' was written in italics), and: After the call to fclose(), any use of stream -- -- causes undefined behaviour. (where both fclose and stream are in italics in the section I was quoting from). Their description for fclose does also use the phrase 'a stream' (with no italics) in the same way everyone else has been using it. - - - - - - Also for the curious, here is the "resolution" of my bug report as it was sent to redhat: + libc is allowed to start nethack, format your disks, + whatever it wants in this case. + + The fact that it magically works on some other system + means nothing, the results of such operation are undefined. + glibc in ferror has to acquire lock of the stream in + question first (thus writes into memory). Perhaps other + systems either don't care about multiple threads (and do + no locking) or slow each operation down (by checking + if the file descriptor is valid at the start of every + single routine). + + You can turn some of such checks by recompiling glibc + with IO_DEBUG, but as such checks just catch some cases + and can pass even on invalid FILE descriptors and also + slow things down, they are not enabled by default. + + So think about ferror on fclosed FILE as if you put + random garbage into that memory area yourself. It is interesting that they talk about acquiring a lock for the stream in question first. As freebsd does more with SMP and threads, will freebsd need to do similar locking? They are also trumpeting the fact that the behavior in this case is "undefined", and thus they feel there is no problem with the fact that the call to ferror trashes random locations in memory and will trigger very obscure bugs which are no where near the "real bug" (ie, the ferror). All very well. Everyone gets to use the term "undefined behavior" to justify that no changes should be made to there version fclose or ferror. All I'm saying is that this leaves the person porting "hairy old C code" in a mighty unpleasant position. This fclose/ferror combination is a fairly easy mistake to miss (particularly since it does work on freebsd), but it might be lethal on other platforms. And if it is lethal, you will get no sympathy once you do track it down. Here I lost 30 hours tracking down a bug in code I did not write in the first place, and everyone's attitude seems to be that it's my fault for wanting to port some C code to multiple platforms. So, for those hackers who do port C code, put this combination on the list of things you should lookout for. -- --- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: find, -delete, and relative paths
Cyrille Lefevre writes: "Daniel O'Connor" [EMAIL PROTECTED] writes: On 20-Nov-00 Brian Reichert wrote: I didn't find anything after an admittedly quick look intp PRs and the mail list archives: Under FreeBSD 3.4-RELEASE, we are running a simple log file scrubber: 15 3 * * * find /usr/local/logs/lsp \! -ctime 1 -delete I pointedly am using an absolute path, yes I get this warning repeatedly: find: -delete: /usr/local/logs/lsp: relative path potentially not safe How can I suppress this warning? Is it a bug in find, or did I misunderstand the manpage? I don't know why, but I think find prints those messages when you attempt to delete a directory. If you do - 15 3 * * * find /usr/local/logs/lsp -type f -a \! -ctime 1 -delete it should work.. 15 3 * * * find /usr/local/logs/lsp -depth \! -ctime 1 -delete could be better, deletes file entries before directory ones. PS : -a is not necessary, it's always implied except if -o of course. Look at ports/sysutils/deleted daemon that deletes old files, directories and other -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fclose vs ferror (from libc/getcap)
At 9:36 AM -0800 11/22/00, Matt Dillon wrote: [...] When you fclose() something or otherwise terminate a structure, it's gone. Anything else is illegal. *internally* our libc assumes that ferror() is legal after an fclose() because, well, it's true... but only for internal library functions. Nobody outside the library can legally make that assumption and it could also be argued that even within the library those types of assumptions should not be made unless absolutely necessary. Hmm. That does bring up an important point. The code with the fclose/ferror combination *is* something I was taking directly out of libc. So, it would have more right than most code to make explicit assumptions about the implementation of other libc routines. I had not thought of it in that way, mainly because I pulled it out of libc at least five years ago, and it didn't cause me any trouble until this month. There isn't much we can do about the issue except fix the instances of mis-programming as they show up. Yep. Oh well. On to the next tempest, please pass the tea. -- --- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
HDD crashes, S.M.A.R.T and relocation tables.
Hello, All! How are you? Now here is no `bad144' utility. Everybody say ``modern HDDs could do hardware remaps of bad blocks, and if here is visible bad blocks, it means HDD will die soon, so buy new HDD ASAP and throw bad one away''. Ok. I agree with it. IDE HDDs are cheap now, and information is expensive. But here is one problem: sometimes ASAP means two days or even two weeks (especially, in Russia). Sometimes we need wait salary, need bank transfer from firm to shop or something like this. But HERE IS BAD SECTORS RIGHT NOW! We understand, we need to buy new HDD when we see ``hard read error''! And we need to live with bad HDD for days! I see god solution: monitor HDD health by downloading relocation table and S.M.A.R.T. information from it daily (in cron job). When script detect, that relocation table is near to be full or here is 1000 new relocations in one day, it sends mail to root, and we have some time to buy new HDD. But I could not find any utility for FreeBSD, which could get S.M.A.R.T. information and relocation table from HDD... So, we need such utility. Does anybody know -- is such utility exists? Lev Serebryakov /---\ | FIDONet: 2:5030/661.0 | | E-Mail: [EMAIL PROTECTED] | | Page:http://lev.serebyrakov.spb.ru/ | | ICQ UIN: 3670018 | | Phone: You know, if you have world nodelist | \===/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HDD crashes, S.M.A.R.T and relocation tables.
It seems Lev Serebryakov wrote: I see god solution: monitor HDD health by downloading relocation table and S.M.A.R.T. information from it daily (in cron job). When script detect, that relocation table is near to be full or here is 1000 new relocations in one day, it sends mail to root, and we have some time to buy new HDD. But I could not find any utility for FreeBSD, which could get S.M.A.R.T. information and relocation table from HDD... So, we need such utility. Does anybody know -- is such utility exists? I'm working on it, but its not available to the public yet... I'll announce it when I have it ready for general consumption... BTW not all ATA drives supports this... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: BSD's random.c dicey on the Alpha
On Wed, Nov 22, 2000 at 03:18:27PM +0200, Sheldon Hearn wrote: Hi folks, Anyone want to have a look at this? It's from the GNU awk maintainer. Without knowing which random.c it was, it's hard to judge :-) Also not knowing what the intended use is, it's hard to recommend something. Kris PGP signature
porting a Linux app
Please respond to me directly (and the mailing list if you so choose) I am attempting to port an application from Linux to FreeBSD (source code). I have been told that I need to compile the source against a different set of /include and /lib files. When compiled against the system libs it works fine but when I try to compile against our proprietary libs it doesn't seem to do what I ask. The code does compile and run. Problem is my gcc options do not seem to produce the results I'd like. I have attempted gcc -static -I /pathto/new/include -L /pathto/new/lib sourcefile.c but it always seems to compile against the /usr/include and /usr/lib files. I know this because I produced an ELF binary (sans the -static arg) and ran "ldd program-name" and it returned lgcc.2 = /usr/lib/libgcc.x and some other = /usr/lib/xx's. I have also tried renaming all "#include stdio.h" to "#include "/pathto/new/include/stdio.h" and so on How do I force this source to compile using the /pathto/new/include and /pathto/new/lib ??? -- Andrew Otwell [EMAIL PROTECTED] www.NetworkComputerz.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: porting a Linux app
Andrew Otwell wrote: gcc -static -I /pathto/new/include -L /pathto/new/lib sourcefile.c -nostdlib -nostdinc -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "All right, Lieutenant, let's see what you do know. Whatever it is, it's not enough, but at least you haven't done anything stupid yet." "I've hardly had time, sir." "There's a naive statement." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RFC: /dev/console - /var/log/messages idea/patch
In local.freebsd-current you write:
On Wed, 22 Nov 2000 22:22:39 +0100, Poul-Henning Kamp [EMAIL PROTECTED] said:
Another particular thing I remember was that some syslog-challenged
daemons whine on /dev/console long after /etc/rc has finished.
They can try, but by the time they do the console has already been
revoke()d, so they no longer have access to the real console.
I've thought about writing daemon(8) which will put these turkeys in
their place. Just a Small Matter of Programming
Do you mean something like this?
$.02,
/Mikko
---8-
/*
* Description:
* Utility to start a program as a daemon.
* Closes stdin/out/err and execs the program.
* Program is located using PATH.
*
* Usage:
* daemon [options] program [ args to program ]
*
* Options:
* -c Do not close stdin/out/err
* -d Do not chdir("/")
* -o file Append stdout/err to file
* -p file Write pid to file
* -u user User to run program as
*/
#include stdio.h
#include unistd.h
#include string.h
#include errno.h
#include stdlib.h
#include fcntl.h
#include pwd.h
#include err.h
#include sys/stat.h
#define PROGNAME "daemon"
#define USAGE "Usage: " PROGNAME \
" [-c] [-o output] [-p pidfile] [-u user] program [args ...]"
int
main(int argc, char **argv)
{
int fd, c, noclose, nochdir;
char *outfile, *prog, *s, *pidfile;
FILE *pf;
struct passwd *pw;
char *user;
noclose = 0;
nochdir = 0;
outfile = NULL;
pidfile = NULL;
user = NULL;
fd = -1;
pf = NULL;
pw = NULL;
while ((c = getopt(argc, argv, "cdo:p:u:")) != -1) {
switch (c) {
case 'c':
noclose++;
break;
case 'd':
nochdir++;
break;
case 'o':
outfile = optarg;
noclose++;
break;
case 'p':
pidfile = optarg;
break;
case 'u':
user = optarg;
break;
default:
errx(2, USAGE);
}
}
if (optind == argc)
errx(2, USAGE);
if (user != NULL (pw = getpwnam(user)) == NULL)
errx(EXIT_FAILURE, "user unknown: \"%s\"", user);
if (pidfile != NULL ((pf = fopen(pidfile, "w")) == NULL))
err(EXIT_FAILURE, "cannot create \"%s\"", pidfile);
if (outfile != NULL) {
if ((fd = open(outfile, O_WRONLY | O_APPEND | O_CREAT, 0644)) 0) {
err(EXIT_FAILURE, "cannot create \"%s\"", outfile);
}
}
if (pw != NULL) {
initgroups(pw-pw_name, pw-pw_gid);
if (setuid(pw-pw_uid) 0)
err(EXIT_FAILURE, "setuid(%d)", pw-pw_uid);
}
if (daemon(nochdir, noclose) 0)
err(EXIT_FAILURE, "daemon");
if (pidfile != NULL) {
fprintf(pf, "%u\n", (unsigned)getpid());
fclose(pf);
}
if (fd != -1) {
dup2(fd, STDOUT_FILENO);
dup2(fd, STDERR_FILENO);
close(fd);
}
prog = argv[optind];
if ((s = strrchr(argv[optind], '/')) != 0) {
argv[optind] = s+1;
}
execvp(prog, argv + optind);
err(EXIT_FAILURE, "cannot exec %s", prog);
if (pidfile != NULL) {
unlink(pidfile);
}
exit(EXIT_FAILURE);
}
--
Mikko Työläjä[EMAIL PROTECTED]
RSA Security
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: still in the woods (tuning for postfix hub)
In article [EMAIL PROTECTED] you write: Somebody here must know who is Mr. Hub Admin, no? [EMAIL PROTECTED] I guess? Can somebody tell me who admins FreeBSD/postifx mail hubs? I need some help opening up FreeBSD for postfix and 200K msgs/day. Below is an old posting of Peter Wemm to the postfix mailing list about the FreeBSD mailing list server. It gives you some of the information you are asking for. Arjan -- Arjan de Vet, Eindhoven, The Netherlands [EMAIL PROTECTED] URL: http://www.iae.nl/users/devet/ for PGP key: finger [EMAIL PROTECTED] From: [EMAIL PROTECTED] (Peter Wemm) Subject: Re: huge mailout tuning? Date: 9 Jul 1999 07:16:38 +0200 Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] "Dunstan, Andrew" wrote: -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] 2M deliveries in 12 hours is almost 50 a second. Now that is going to hit your disk really hard. Each queue file involves synchronous disk accesses for creating, writing the message to file and for unlinking. Remember, the issue is disk seeks, not I/O bandwidth. [Andrew] Yes. Would using some sort of raid striping help? If you are prepared to loose mail on a crash, run the filesystem with the queue directory async, or something like the BSD softupdates code to safely avoid directory sync writes. (safely from the perspective of filesystem recovery, not safety from lost mail). If it's a bulk mailout then perhaps this is a acceptable. Given that SMTP is a somewhat chatty protocol (unlike HTTP), you will need to run hundreds of deliveries in parallel. Postfix uses select(), and by default is limited to 1024 open files. In order to increase the limit, recompile with a larger size for FD_SETSIZE in util/sys_defs.hm at the start of the #ifdef SUNOS5 section. [Andrew] How do I run "hundreds of deliveries in parallel"? (and where does postfix multiplex io?) On the freebsd.org machines, we recompiled postfix with FD_SETSIZE set to (overkill) 4096 (freebsd's kernel implementation has variable sized fd_sets). We currently run with 250 delivery smtp processes, and have used higher limits in the past. We manage to fit the entire /var/spool/postfix queue in memory on that machine and with softupdates, a good amount of writes are entirely avoided. (ie: an incoming queue entry gets created, processed (fed to majordomo), then deleted. Under async writes, this data gets written back. Under softupdates it's entirely cancelled out (I believe. :-)) since it was deleted so quickly and never even partially existed on disk before it was unlinked. Again, those machines are not processing critical or sensitive mail so lost mail is unfortunate but tolerable. I *think* we've peaked sustained delivery at about 60/sec for short periods in some circumstances - but we have a *LOT* of slow and/or congested remote sites. I'm pretty sure I've seen transient delivery rate spikes go quite beyond that though but that's probably more luck and timing than anything. Again, *from memory*, the mailing list traffic runs about 1/2 million recipients per day and there is loads of spare capacity as a good deal of this happens in bursts at peak times when a lot of folks read and post to the lists at about the same time of day. I realise that a distributed solution might be necessary, but I want to know what we can achieve with our current platform. How can we best tune postfix to maximise delivery rate? Are there issues with queue directories becoming huge? You can configure postfix to hash queues. By default, only the directory for deferred logfiles is hashed. See the hash_queue_names parameter. Examples in conf/* [Andrew] I set have hashing on for incoming, deferred and defer. Is that right? What is the penalty for increasing the hashing levels? (2 levels for 2m files would still give me around 10,000 per directory (ouch)). So I'd prefer to go to 3 or even 4 levels if this doesn't involve a big performance hit. Also, if you can get the machines, I'd suggest a small cluster of outgoing sender machines. Set up a round-robin DNS entry, say mail-outgoing.you.com where mail-outgoing has 5 or 10 IP addresses or MX records. Then use mail-outgoing for your outbound host. Your core box will send envelopes to the outbound boxes for relaying in a fairly distributed way. We use this technique for freebsd.org mail delivery for some geographical mail exploder relays. For example, mail-relay.de.freebsd.org points to 4 machines, and *.de is exploded via them with a transports entry. Two servers are primary and share the load evenly and the other two are fallbacks on different networks with different international links. eg: [5:06am]~/Mail-251 host mail-relay.de.freebsd.org mail-relay.de.freebsd.org mail is handled (pri=100) by mail.rz.tu-clausthal.de mail-relay.de.freebsd.org mail is handled (pri=100) by
Shell script
I have such script.
# more trafdump
#!/bin/sh -
# trafdumpCopyright (c)1993 CAD lab
#
# dump all records to /var/tmp/trafd.$iface
#
# usage: trafdump interfaces...
#
PATH=/usr/local/bin
WHERE_PID=/var/run/trafd.ed0
LOG_FILE=/var/log/traffic.log
if [ $# = 0 ]; then
echo trafdump - dump tcp/udp network data traffic
echo usage: trafdump interfaces...
exit 1
fi
for iface in $*; do
PID_FILE=$WHERE_PID$iface
if [ -f $PID_FILE ]; then
kill -HUP `cat $PID_FILE`
if [ $? = 0 ]; then
echo `date +"%b %e %H:%M:%S"` `hostname -s`
trafdump: \
'('$iface')' signaling to dump $LOG_FILE
fi
else
echo error: $PID_FILE not found | tee -a $LOG_FILE
fi
done
#
but when I try to start
# ./trafdump -ied0
I receive three errors
I can't understand whereis the errors.
[: not found
[: not found
tee: not found
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Shell script
On Thu, Nov 23, 2000 at 02:30:54AM +0200, petro wrote: I have such script. PATH=/usr/local/bin [...] if [ $# = 0 ]; then [...] if [ -f $PID_FILE ]; then [...] if [ $? = 0 ]; then [...] echo error: $PID_FILE not found | tee -a $LOG_FILE I receive three errors I can't understand whereis the errors. [: not found [: not found tee: not found $ which [ /bin/[ $ which tee /usr/bin/tee Fix your PATH and all will be well. And next time, post your question to [EMAIL PROTECTED] -- Ben 220 go.ahead.make.my.day ESMTP Postfix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shell script
Your PATH variable (line 8) needs to include /bin, where both tee and [
are located.
Tony.
On Thu, 23 Nov 2000, petro wrote:
I have such script.
# more trafdump
#!/bin/sh -
# trafdumpCopyright (c)1993 CAD lab
#
# dump all records to /var/tmp/trafd.$iface
#
# usage: trafdump interfaces...
#
PATH=/usr/local/bin
WHERE_PID=/var/run/trafd.ed0
LOG_FILE=/var/log/traffic.log
if [ $# = 0 ]; then
echo trafdump - dump tcp/udp network data traffic
echo usage: trafdump interfaces...
exit 1
fi
for iface in $*; do
PID_FILE=$WHERE_PID$iface
if [ -f $PID_FILE ]; then
kill -HUP `cat $PID_FILE`
if [ $? = 0 ]; then
echo `date +"%b %e %H:%M:%S"` `hostname -s`
trafdump: \
'('$iface')' signaling to dump $LOG_FILE
fi
else
echo error: $PID_FILE not found | tee -a $LOG_FILE
fi
done
#
but when I try to start
# ./trafdump -ied0
I receive three errors
I can't understand whereis the errors.
[: not found
[: not found
tee: not found
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
2 pci , 1 isa, same type NIC makes freebsd seems to be confused
I have FreeBSd 4.1 with 2 PCI NIC and 1 ISA NIC all of them detected as ed0, ed1. ed2 at kernel, I put ISA NIC as ed0. the problem is: the box seems not stable, almost every 2 hours i must restart the box, when i try to remove all the nic and put back only one, the box going smooth. Any suggestion what i must do ? oh btw I already check the intrupt, none of them were use twince for NIC Best regards, Thomas Wahyudi UIN 535778 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RFC: /dev/console - /var/log/messages idea/patch
On Wed, 22 Nov 2000 15:20:13 -0800 (PST), Mikko Tyolajarvi [EMAIL PROTECTED] said: Do you mean something like this? Yes, exactly like that! -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 2 pci , 1 isa, same type NIC makes freebsd seems to be confused
At Thu, 23 Nov 2000 09:57:44 +0700, Thomas Wahyudi [EMAIL PROTECTED] wrote: I have FreeBSd 4.1 with 2 PCI NIC and 1 ISA NIC all of them detected as ed0, ed1. ed2 at kernel, I put ISA NIC as ed0. Currently, many of NIC drivers can not handle this situation. Many drivers shoud be used on single bus. These are occured from miss-using of devclass. For example, 'ed', In /sys/dev/ed/if_ed_isa.c: static devclass_t ed_isa_devclass; And in /sys/dev/ed/if_ed_pci.c: static devclass_t ed_devclass; These separated devclass leads to confusable situation. Drivers which have same name (such like 'ed') should share one devclass, or multiple 'ed0' appear on the host. Sadly, this type of mistakes are widely spreaded on the tree. The 'snc' driver (which I ported) does right things on this point. /sys/dev/snc/if_sncvar.hextern declaration /sys/dev/snc/if_snc.c real declaration /sys/dev/snc/if_snc_cbus.c use devclass in DRIVER_MODULE /sys/dev/snc/if_snc_pccard.cuse devclass in DRIVER_MODULE -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Accept credit cards on-line THE EASY WAY!
No set up fees No monthly interest No minimum transaction fees The only charge is a small percentage of the cost of the transaction. You can not lose money! You only pay fees if you sell your product. Get in the act and launch your online bussiness which will work for you 24hrs a day, seven days a week and it is worldwide. Want to find out more? Go to: http://www.cyberturf.com/creditcard If this Email has reached you by mistake, we apologize. To remove your Email from the mailing list please send: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
