diskless dhclient
Hi all, I've tried to get my freebsd diskless system to get hold of some of the dhcp-options. E.g. my dhcp-server will always be the nfs-server as well. So I was hoping to create the /etc/fstab with the the dhcpd's ip as the nfs server. Thus not needing to have the hard coded nfsroot:/conf/'ip-address'/etc. Instead i'm looking for having almost all necessary files in the nfsroot:/conf/base/etc directory. I've tried to set ifconfig_ETHDEV=DHCP in /etc/rc.conf and creating a bourne shell script /etc/dhclient_enter_hooks, but as far as I can detect the script is never run. I guess since the kernel already got the ip-address during pxeboot it does not care about renewing the ip-address, or?? I'm running a legacy FreeBSD 6.4. So - not really a specific question, more like a cry for guidance - anyone? /Mats ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
unsubcribe
Hello ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
compat libs in FreeBSD 7.0
Hi What happened to the compatibility libraries in FreeBSD 7.0 release Need to run some FreeBSD-5.4 binaries on a 7.0 System. Can't find the libs any longer Mats ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: purging old mail
Jonathan McKeown [EMAIL PROTECTED] wrote on 2007-06-01 14:31:48: On Friday 01 June 2007 14:11, Steve Bertrand wrote: [EMAIL PROTECTED] wrote: Hi all, I'm setting up a FreeBSD 5.4 system that need to run unattended for a year or more. I've noticed that the /var/mail/root file grows a bit over time. Do I need to configure the system in some way to prevent this file from growing indefinately, filling up the /var partition? Are you actually interested in reading root mail? Are you running sendmail? If so, in the /etc/mail/aliases file, change the root alias to an email address that someone actually POP's. If you don't want to read the email at all, change the root alias to point to /dev/null. What I've been caught by a couple of times is the periodic(8) routines, which quickly fill roots mailbox with daily, weekly and monthly status reports. If you're not going to forward these to a real user but still want to keep (some of) them available, put daily_output=/var/log/daily.log weekly_output=/var/log/weekly.log monthly_output=/var/log/monthly.log in /etc/periodic.conf. The relevant reports will be logged into the respective files, and newsyslog already knows to rotate these if they exist, so they won't grow endlessly (by default, /etc/newsyslog.conf keeps a week of dailys, 5 weeks of weeklys and a year of monthlys). Jonathan Thanks guys This was really usefuk ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Please note that in order to protect the security of our information systems an AntiSPAM solution is in use and will browse through incoming emails. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l?usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu?il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Veuillez prendre note qu'une solution antipollupostage (AntiSPAM) est utilisée afin d'assurer la sécurité de nos systems d'information et qu'elle furètera les courriels entrant. Merci. _ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
purging old mail
Hi all, I'm setting up a FreeBSD 5.4 system that need to run unattended for a year or more. I've noticed that the /var/mail/root file grows a bit over time. Do I need to configure the system in some way to prevent this file from growing indefinately, filling up the /var partition? If so - how? Mats Lindberg ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Please note that in order to protect the security of our information systems an AntiSPAM solution is in use and will browse through incoming emails. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l?usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu?il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Veuillez prendre note qu'une solution antipollupostage (AntiSPAM) est utilisée afin d'assurer la sécurité de nos systems d'information et qu'elle furètera les courriels entrant. Merci. _ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
sysinstall
How can I have an interactively invoked sysinstall to load a config-file from something else than a floppy e.g. a CD-ROM? ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l’usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu’il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l’avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Merci. _ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
corefiles
Hi All
When I try to catch SIGTERM and generate a core file the call stack is
corrupted on FreeBSD.
Yes I know that I do not have to catch the signal, a core is generated by
default. But the reason is that I need to do more at SIGTERM.
Example 1
In gdb backtrace, why is monitorSignalHandlerBUS listed? it is never called!
test1.c
- cut here ---
#include stdio.h
#include signal.h
static void
monitorSignalHandlerBUS(int signo)
{
printf(monitorSignalHandlerBUS\n);
fflush(stdout);
}
static void
monitorSignalHandlerTERM(int signo)
{
printf(monitorSignalHandlerTERM\n);
fflush(stdout);
abort();
}
int
main(int argc, char **argv)
{
signal(SIGBUS, monitorSignalHandlerBUS);
signal(SIGTERM, monitorSignalHandlerTERM);
kill(getpid(), SIGTERM);
}
- cut here ---
is compiled on FreeBSD
cc -g test1.c -o test1
./test1
monitorSignalHandlerTERM
Abort (core dumped)
gdb test1 test1.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
Core was generated by `test1'.
Program terminated with signal 6, Aborted.
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x280c237b in kill () from /lib/libc.so.5
(gdb) bt
#0 0x280c237b in kill () from /lib/libc.so.5
#1 0x280b7422 in raise () from /lib/libc.so.5
#2 0x28129c1b in abort () from /lib/libc.so.5
#3 0x080486a8 in monitorSignalHandlerTERM (signo=15) at test1.c:15
#4 0xbfbfff94 in ?? ()
#5 0x000f in ?? ()
#6 0x in ?? ()
#7 0xbfbfe9d0 in ?? ()
#8 0x0002 in ?? ()
#9 0x0804867c in monitorSignalHandlerBUS () at test1.c:9
#10 0x080485a5 in _start ()
#11 0x0001 in ?? ()
(gdb)
Example 2
In gdb backtrace, what is frame_dummy ?
test2.c
- cut here ---
#include signal.h
static void
SignalHandler(int signo)
{
abort();
}
int
main(int argc, char **argv)
{
signal(SIGTERM, SignalHandler);
kill(getpid(), SIGTERM);
}
- cut here ---
is compiled on FreeBSD
cc -g test2.c -o test2
./test2
Abort (core dumped)
gdb test2 test2.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
Core was generated by `test2'.
Program terminated with signal 6, Aborted.
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x280c237b in kill () from /lib/libc.so.5
(gdb) bt
#0 0x280c237b in kill () from /lib/libc.so.5
#1 0x280b7422 in raise () from /lib/libc.so.5
#2 0x28129c1b in abort () from /lib/libc.so.5
#3 0x080485cf in SignalHandler (signo=15) at test2.c:6
#4 0xbfbfff94 in ?? ()
#5 0x000f in ?? ()
#6 0x in ?? ()
#7 0xbfbfe9d0 in ?? ()
#8 0x0002 in ?? ()
#9 0x080485c4 in frame_dummy ()
#10 0x08048519 in _start ()
#11 0x0001 in ?? ()
(gdb)
___
This e-mail communication (and any attachment/s) may contain confidential or
privileged information and is intended only for the individual(s) or
entity named above and to others who have been specifically authorized to
receive it. If you are not the intended recipient, please do not read, copy,
use or disclose the contents of this communication to others. Please notify
the sender that you have received this e-mail in error by reply e-mail,
and delete the e-mail subsequently.
Thank you.
_
Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir
des renseignements confidentiels ou protégés et est destiné à l’usage
exclusif du destinataire ci-dessus. Toute autre personne est par les présentes
avisée qu’il est strictement interdit de le diffuser, le distribuer ou
le reproduire. Si vous l’avez reçu par inadvertance, veuillez nous en aviser et
détruire ce message.
Merci.
_
___
freebsd-questions@freebsd.org mailing list
Re: Generating coredump's from within a signal handler.
Giorgos Keramidas [EMAIL PROTECTED] wrote on 2005-06-22 18:16:37: On 2005-06-22 16:00, [EMAIL PROTECTED] wrote: I'm writing a program that when receiving a SIGTERM shall generate a coredump of itself and exit. This coredump shall be analysed later on using gdb. I've tried to raise(SIGABRT) when handling SIGTERM, this generates a coredump, but the stack seems messed up when examining it with gdb. The stack *is* ``messed up'' when a program runs within a signal handler (where ``messed up'' means signal handlers are not called as normal C functions, but are entered on exit from a system call using special stack magic). What do you see in the gdb backtrace that seems ``messed up''? This is it #0 0x281a337b in kill () from /lib/libc.so.5 #1 0x28198422 in raise () from /lib/libc.so.5 #2 0x080d912a in externalSignals (signo=15) at monitor.c:122 #3 0x080d91c9 in monitorSignalHandler (signo=15) at monitor.c:167 #4 0xbfbfff94 in ?? () #5 0x000f in ?? () #6 0x in ?? () #7 0xbfbfea50 in ?? () #8 0x0002 in ?? () #9 0x080d91ae in internalError (signo=136130464) at monitor.c:156 #10 0x080cb12b in doCycleControl () at mngrA.c:707 #11 0x080ca9d4 in mngrA () at mngrA.c:313 #12 0x080bc4c3 in main () at proc0A.c:147 at line 707 there is a call to a regular c-func 'p_time_wait()' this is not visible in the traceback monitorSignalHandler(int signo) is setup to handle signal(SIGSEGV, monitorSignalHandler); signal(SIGBUS, monitorSignalHandler); signal(SIGTERM, monitorSignalHandler); signal(SIGQUIT, monitorSignalHandler); signal(SIGHUP, monitorSignalHandler); in monitorSignalHandler() internalError(int signo) is a fallback handler for unknown signals. in monitorSignalHandler() a SIGTERM issues a raise(SIGABRT); So the traceback is messed up as I can understand it; The process is given a SIGTERM when, probably, in function p_time_wait(). p_time_wait is not visible in the traceback. Instead internalError is shown with a very strange signo. The traceback from #3 and up(or down) to zero makes sense. But the most interesting thing - the whereabouts of the process when it received SIGTERM is hidden to me. ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l’usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu’il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l’avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Merci. _ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Generating coredump's from within a signal handler.
Hi all! I'm writing a program that when receiving a SIGTERM shall generate a coredump of itself and exit. This coredump shall be analysed later on using gdb. I've tried to raise(SIGABRT) when handling SIGTERM, this generates a coredump, but the stack seems messed up when examining it with gdb. Sending SIGABRT directly instead of SIGTERM to the process gives a readable coredump but this is not a solution to my problem. Mats ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l’usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu’il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l’avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Merci. _ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
building FreeBSD distro
Hi, I need to make some minor modifications to the FreeBSD-5.4 release - changing some config files (e.g. /etc/hosts /etc/rc) - editing the kernel conf-file and recompile/install the kernel and then make a new personal set of installation CD's Which is the smartest way to go about it? Do I need to use the /usr/src make build and /usr/release make release scheme? If so can I use the 5.4 distro CD's as the CVS repository somehow? Or do I really need the cvs checkout via internet - I'm having problems with this (company rules conc internet access). If not so how do I do? Mats ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protgs et est destin lusage exclusif du destinataire ci-dessus. Toute autre personne est par les prsentes avise quil est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous lavez reu par inadvertance, veuillez nous en aviser et dtruire ce message. Merci. _ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
console printout at diskless boot
Hi! I am using freebsd in a diskless configuration with etherboot as the bootloader. Now I want to use this setting in a newly bought PC, but it does not boot. I'm using the same kernel as in my working system and the ethernet nic is the same. A major problem for me is that I cannot see when/where my kernel fails. I can see etherboot dowloading the image, but then after a few secs the system reboots. No printouts on the screen :-( On my old computer the there are no printouts either. But after a while the login prompt appears :-) Is the lack of printouts a problem with etherboot config? Or is this some kernel config setting? Mats ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l?usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu?il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Merci. _ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel preemption
I've compiled the kernel with options PREEMTION I've tried rtprio I've tried sched_setscheduler(...scheduler=FIFO, priority=31...); Swapping is turned off. I still get 250ms pausing in the tcp comm. Maybe it is the stack?! Is it losing frames perhaps? Any good ideas what to look for - someone. Regarding the HZ - My application never uses the cpu for more than 1ms or so before it blocks. So that should not be tha case. There are not many other processes and I have none of them running at an elevated priority/scheduler scheme. ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l?usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu?il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Merci. _ ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l?usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu?il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Merci. _ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel preemption
Hello, I'm interested in using freebsd in a 'not so realtime, but...' software project. In our running environment there are a 3 processes that need high priority. The processes never need much cpu but they should be able to respond to network (tcp) activity within 10-20ms. I have a testprogram in C that sends ~24kB tcp-messages via a switched ethernet. Sometimes there is a ~250ms delay in receiving (or sending). This could happen after an hour or so. I've tried building a 5.3 system with PREEMPTION and the 4BSD Scheduler. It did not help. I've tried building a 6.0 current system with PREEMPTION and the ULE scheduler. It did not boot. I've tried this on a linux preemptive kernel and it works fine. Is the PREEMPTION option applicable for my problem? Should PREEMPTION work for the 4BSD scheduler? Mats ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l?usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu?il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Merci. _ ___ This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Thank you. _ Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut contenir des renseignements confidentiels ou protégés et est destiné à l?usage exclusif du destinataire ci-dessus. Toute autre personne est par les présentes avisée qu?il est strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous l?avez reçu par inadvertance, veuillez nous en aviser et détruire ce message. Merci. _ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
