Re: Reducing syslogd output bloat (was: cvs commit: src/sys/conf Makefile.i386)
On Sunday 25 November 2001 01:49, Dima Dorfman wrote:
> Peter Wemm <[EMAIL PROTECTED]> wrote:
> > Bruce Evans wrote:
> > > - syslogd: the name of the kernel file is used as a
> > > prefix. If I kept kernels in the standard place, then I
> > > would have complained about the bloatage of syslogd output
> > > caused by renaming the kernel from /kernel to
> > > /boot/${NAME_OF_MY_KERNEL}/kernel
> >
> > It used to print "kernel" always, even when the kernel was
> > /vmunix and on other systems when it is /bsd or /netbsd.
> > I'd much rather that we went back.
> >
> > When syslogd starts up, it could log the value of
> > kern.bootfile and kern.module_path once in the kernel log
> > and just use "kernel:" for identifying kernel originated
> > messages.
>
> The attached patch implements something like this:
>
> Make the default kernel prefix "kernel:" instead of the boot
> file, with the old behavior available via the -o option (it
> might still be useful if one has many kernels and cares which
> messages came from which). If the boot file is not used as
> the prefix, it is still logged once at startup.
>
> This change is prompted by the fact that the boot file is now
> much longer ("/boot/kernel/kernel" vs. "/kernel"), which
> significanlty bloats the syslogd output.
>
> Please review and comment.
>
[snip patch]
I think this is a good idea. Go for it.
--
Gary Jennejohn [EMAIL PROTECTED] [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Reducing syslogd output bloat (was: cvs commit: src/sys/conf Makefile.i386)
On Sun, Nov 25, 2001 at 12:49:16AM +, Dima Dorfman wrote:
> The attached patch implements something like this:
>
> Make the default kernel prefix "kernel:" instead of the boot file,
> with the old behavior available via the -o option (it might still be
> useful if one has many kernels and cares which messages came from
> which). If the boot file is not used as the prefix, it is still
> logged once at startup.
>
> This change is prompted by the fact that the boot file is now much
> longer ("/boot/kernel/kernel" vs. "/kernel"), which significanlty
> bloats the syslogd output.
>
> Please review and comment.
Nice work; just a couple of comments..
> @@ -181,6 +181,12 @@
> messages; the default is 20 minutes.
> .It Fl n
> Disable dns query for every request.
> +.It Fl o
> +Prefix kernel messages with the full kernel boot file as determined by
> +.Xr getbootfile 3 .
> +Without this,
> +the kernel message prefix is always
Do these two really need to be on separate lines?
> Index: syslogd.c
> ===
> RCS file: /ref/cvsf/src/usr.sbin/syslogd/syslogd.c,v
> retrieving revision 1.92
> diff -u -r1.92 syslogd.c
> --- syslogd.c 2001/11/14 09:20:24 1.92
> +++ syslogd.c 2001/11/25 00:42:26
> @@ -273,6 +273,7 @@
> int family = PF_INET; /* protocol family (IPv4 only) */
> #endif
> int send_to_all = 0;/* send message to all IPv4/IPv6 addresses */
> +int use_bootfile = 0; /* log entire bootfile for every kern msg */
I think 'boot filename' would be more appropriate at least in the comment.
> @@ -1525,6 +1531,16 @@
> oldLocalHostName, LocalHostName);
> logmsg(LOG_SYSLOG|LOG_INFO, hostMsg, LocalHostName, ADDDATE);
> dprintf("%s\n", hostMsg);
> + }
> + /*
> + * Log the kernel boot file if we aren't going to use it as
> + * the prefix, and if this is *not* a restart.
> + */
> + if (signo == 0 && !use_bootfile) {
> + (void)snprintf(bootfileMsg, sizeof(bootfileMsg),
> + "syslogd: kernel boot file is %s", bootfile);
Maybe something like 'boot(ed) kernel file name'?
Other than those minor issues, I like this patch a lot.
G'luck,
Peter
--
If I had finished this sentence,
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
size
Greetings. I got this email address out of the FreeBSD Newsletter, issue#1. I'm not sure if you're the right guys to address such a query to so if this seems out of place I apologize, but perhaps you can direct it to the right folks. I've got an old P1 135 (I think, may be 125, can't remember), 1.7G HD, 32M RAM...in short, a dinosaur. I want to experiment with FreeBSD and would like to do so on a machine that is non-critical so I have time to learn it without being under the gun. I was reading in the newsletter that Dave Filo was using BSD on an old (probably wasn't old back in '97, haha!) P100, 32M RAM machine and that the release number for BSD then was 2.2 STABLE (what is "stable", or was that an aside by the author?). I've seen FreeBSD releases in the somewhat recent past at 3.4 I believe, and it has me wondering: will an older machine like mine will be large enough to handle the newer releases? Thanks much for taking time out to consider this email. 'Hope you guys had a great Thanksgiving and will have a great holiday season. Regards, Paul Adams
[no subject]
Wow, that was fast! Thanks for the rapid response. I'll direct future questions to the appropriate address. Thanks again.
Re: jail.c.patch (allowing to use hostnames when invoking jail(8))
On Saturday, November 24, 2001, Igor M Podlesny wrote:
> i = inet_aton(argv[3], &in);
> - if (!i)
> - errx(1, "Couldn't make sense of ip-number\n");
> + if (!i) {
> + /* check if it is resolveable */
> + struct hostent *hp;
> + hp = gethostbyname(argv[3]);
> + if (hp == NULL) {
> + errx(1, "Couldn't make sense of the jail address\n");
> + }
> + else {
> + char **p = hp->h_addr_list;
> + if (p[1] != NULL) {
> + errx(1, "Jail should have only one ip-address
>associated with!\n");
> + }
> + else {
> + memcpy(&in.s_addr, p[0], sizeof(in.s_addr));
> + }
> + }
> + }
I'd rewrite the above (`i = inet_aton' all the way down) as
hp = gethostbyname(argv[3]);
if (hp == NULL) {
errx(1, "%s: %s", argv[3], hstrerror(h_errno));
}
in = *(struct in_addr *)hp->h_addr_list[0];
This makes the call to inet_aton() unnecessary (and really
shortens the code!).
--
+---+--+
| Chris Costello| It is easier to change the specification |
| [EMAIL PROTECTED] | to fit the program than vice versa. |
+---+--+
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: jail patch
Gregory Neil Shapiro writes:
> evms> I wrote this a while ago, but, if anyone is interested, please
> evms> take a look: this module implements a system call that takes
> evms> a u_int_32t. This system call, named killjail, kills all processes
> evms> which belong to the jail which uses that particular IP address.
>
> evms> I included it in a tar with a makefile and with a program
> evms> that uses it. (Eg: ./killjail 1.2.3.4)
>
> evms> http://www.sekt7.org/kjs.tar
>
> evms> Works on 4.4 but can be easily ported to 5.0.
>
> This can be done in userland without kernel interaction:
>
> #!/bin/sh
>
> EX_OK=0
> EX_USAGE=64
>
> if [ "$1" = "" ]
> then
> echo "Usage: $0 jailname"
> exit ${EX_USAGE}
> fi
>
> pids=`grep -l " $1\$" /proc/*/status | awk -F/ '{print $3}'`
> if [ "$pids" != "" ]
> then
> kill -15 $pids 2> /dev/null
> fi
> exit ${EX_OK}
This programm selects process by jail host name
instead of by jail itself.
For example I have about 40 jails with
the same host name and IP address
(they occupy different ports).
--
@BABOLO http://links.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
stuff - check it :-)
peace
Interesting website i found :-)
peace
Re: size
On Sun, Nov 25, 2001 at 11:07:58AM -0500, we'uns wrote: > Greetings. I got this email address out of the FreeBSD Newsletter, > issue#1. I'm not sure if you're the right guys to address such a > query to so if this seems out of place I apologize, but perhaps > you can direct it to the right folks. These sorts of things should go to [EMAIL PROTECTED] > I've got an old P1 135 (I think, may be 125, can't remember), > 1.7G HD, 32M RAM...in short, a dinosaur. I want to experiment with > FreeBSD and would like to do so on a machine that is non-critical > so I have time to learn it without being under the gun. I was > reading in the newsletter that Dave Filo was using BSD on an old > (probably wasn't old back in '97, haha!) P100, 32M RAM machine and > that the release number for BSD then was 2.2 STABLE (what is > "stable", or was that an aside by the author?). I've seen FreeBSD > releases in the somewhat recent past at 3.4 I believe, and it has > me wondering: will an older machine like mine will be large enough > to handle the newer releases? FreeBSD will run on your machine. The only problems you may have is if you try to run some very large software packages it may be excessively slow. For more information please see the "FreeBSD Handbook" at www.freebsd.org. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
subscribe
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Infrared emitters under FreeBSD
Has anyone out there played with controlling an infrared emitter from a FreeBSD box? Ideally I'd love to be able to control my satellite receiver from a remote location, streaming the video out at the same time :) So far I've only found a TekRam IRMate, but its only available in germany :(. Anyone out there have any luck with a project like this? -Crh Charles Henrich Eon Entertainment [EMAIL PROTECTED] http://www.sigbus.com:81/~henrich To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: jail patch
On Sun, 25 Nov 2001, Gregory Neil Shapiro wrote:
> evms> I wrote this a while ago, but, if anyone is interested, please
> evms> take a look: this module implements a system call that takes
> evms> a u_int_32t. This system call, named killjail, kills all processes
> evms> which belong to the jail which uses that particular IP address.
>
> evms> I included it in a tar with a makefile and with a program
> evms> that uses it. (Eg: ./killjail 1.2.3.4)
>
> evms> http://www.sekt7.org/kjs.tar
>
> evms> Works on 4.4 but can be easily ported to 5.0.
>
> This can be done in userland without kernel interaction:
>
> #!/bin/sh
>
> EX_OK=0
> EX_USAGE=64
>
> if [ "$1" = "" ]
> then
> echo "Usage: $0 jailname"
> exit ${EX_USAGE}
> fi
>
> pids=`grep -l " $1\$" /proc/*/status | awk -F/ '{print $3}'`
> if [ "$pids" != "" ]
> then
> kill -15 $pids 2> /dev/null
> fi
> exit ${EX_OK}
Note that there are a couple of caveats:
(1) This only works well if jail.set_hostname_allowed is set to '0', or
jails can rename themselves to avoid being killed, including to
unfortunate names such as '-'.
(2) This can be raced, unlike a kill(-1, 15) from within the jail (I
believe).
In the jailng code, I allow jails to be identified using a name (other
than the hostname) when they are created, and that can later be used as a
handle for signalling. Two of the concepts that are useful in jailng are
(1) the ability to identify jails and manage them from the outside more
easily, and (2) jailinit, which permits a jail to maintain a runlevel,
meaning that you don't have to be 'in' a jail in order to start an orderly
shutdown (as you can signal jailinit), not to mention introducing the
notion of an orderly shutdown :-).
Introducing a jailkill() based on a u_int32_t argument seems somewhat
hackish to me; on the other hand, it does address a real need. I suspect
a jailkill script of this sort is the answer for -STABLE, and that in
-CURRENT, a more comprehensive solution would be better.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
jail patch
Hello, I wrote this a while ago, but, if anyone is interested, please take a look: this module implements a system call that takes a u_int_32t. This system call, named killjail, kills all processes which belong to the jail which uses that particular IP address. I included it in a tar with a makefile and with a program that uses it. (Eg: ./killjail 1.2.3.4) http://www.sekt7.org/kjs.tar Works on 4.4 but can be easily ported to 5.0. - Evan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: jail patch
evms> I wrote this a while ago, but, if anyone is interested, please
evms> take a look: this module implements a system call that takes
evms> a u_int_32t. This system call, named killjail, kills all processes
evms> which belong to the jail which uses that particular IP address.
evms> I included it in a tar with a makefile and with a program
evms> that uses it. (Eg: ./killjail 1.2.3.4)
evms> http://www.sekt7.org/kjs.tar
evms> Works on 4.4 but can be easily ported to 5.0.
This can be done in userland without kernel interaction:
#!/bin/sh
EX_OK=0
EX_USAGE=64
if [ "$1" = "" ]
then
echo "Usage: $0 jailname"
exit ${EX_USAGE}
fi
pids=`grep -l " $1\$" /proc/*/status | awk -F/ '{print $3}'`
if [ "$pids" != "" ]
then
kill -15 $pids 2> /dev/null
fi
exit ${EX_OK}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
