tmux patch to ignore SIGCHLD in client
Howdy,
I noticed that starting tmux initially, where the client
would fork() the server, would leave a zombie process[0]
around until detaching from session.
This patch[1] sets SIGCHLD handler to SIG_IGN, which solves
the zombied process issue.
I'm not sure if this is the best place to put this code,
or if there is a better way to fix this issue. I'm sure
more qualified folks will chime in with a better diff.
Thanks,
--patrick
[0] Pre-patch:
$ tmux
$ ps auxw | grep tmux
sidster 20630 0.0 0.2 884 1612 ?? Rs12:01AM0:00.07 tmux: server
(/tmp/tmux-1000/default) (tmux)
sidster 3663 0.0 0.0 0 0 p2 Z+- 0:00.00 (tmux)
sidster 11892 0.0 0.2 768 1276 p2 S+12:01AM0:00.03 tmux: client
(/tmp/tmux-1000/default) (tmux)
[1] tmux_zombie.diff
Index: tmux.c
===
RCS file: /cvs/obsd/src/usr.bin/tmux/tmux.c,v
retrieving revision 1.73
diff -u -p tmux.c
--- tmux.c 22 Feb 2010 20:41:16 - 1.73
+++ tmux.c 7 Apr 2010 07:55:23 -
@@ -244,6 +244,16 @@ main(int argc, char **argv)
size_t len;
int opt, flags, quiet = 0, cmdflags = 0;
shortevents;
+ struct sigactionsigact;
+
+ /*
+* For when we fork() the server, it doesn't zombie around.
+*/
+ memset(&sigact, 0, sizeof sigact);
+ sigemptyset(&sigact.sa_mask);
+ sigact.sa_handler = SIG_IGN;
+ if (sigaction(SIGCHLD, &sigact, NULL) != 0)
+ fatal("sigaction failed");
#ifdef DEBUG
malloc_options = (char *) "AFGJPX";
dhclient-script patch to preserve resolv.conf.save
Hello,
At home I use static IPs, but when I take my laptop to work I
end up using DHCP. Typically there are no issues, however, at
work, if the link goes down, when it comes back up, the saved
resolv.conf file gets clubbered with previous DHCP-ed version
and leaves me to reconstruct my resolv.conf when I return
home and discover things in a broken state.
I believe there is no good reason for dhclient-script to
override an already existing /etc/resolv.conf.save file.
If I'm correct, the following patch[0] solves this issue.
I don't have a way to test the IPv6 edition, but I have been
running a pre 1.16 revision of this script with my patch for
a couple of weeks now.
Open to suggestions and corrections.
Thanks,
--patrick
[0]
Index: dhclient-script
===
RCS file: /cvs/obsd/src/sbin/dhclient/dhclient-script,v
retrieving revision 1.16
diff -u -p dhclient-script
--- dhclient-script 4 Apr 2010 22:53:50 - 1.16
+++ dhclient-script 7 Apr 2010 08:17:07 -
@@ -131,8 +131,10 @@ add_new_resolv_conf() {
# In case (e.g. during OpenBSD installs) /etc/resolv.conf
# is a symbolic link, take care to preserve the link and write
# the new data in the correct location.
+ # However, don't override an already existing
+ # /etc/resolv.conf.save file.
- if [ -f /etc/resolv.conf ]; then
+ if [ -f /etc/resolv.conf -a ! -e /etc/resolv.conf.save ]; then
cat /etc/resolv.conf > /etc/resolv.conf.save
fi
cat /etc/resolv.conf.std > /etc/resolv.conf
@@ -172,8 +174,10 @@ ip6_add_new_resolv_conf() {
# In case (e.g. during OpenBSD installs) /etc/resolv.conf
# is a symbolic link, take care to preserve the link and write
# the new data in the correct location.
+ # However, don't override an already existing
+ # /etc/resolv.conf.save file.
- if [ -f /etc/resolv.conf ]; then
+ if [ -f /etc/resolv.conf -a ! -e /etc/resolv.conf.save ]; then
cat /etc/resolv.conf > /etc/resolv.conf.save
fi
cat /etc/resolv.conf.std6 > /etc/resolv.conf
Re: ahci(4) Intel RAID mode pci ids diff.
> Date: Tue, 6 Apr 2010 21:39:48 -0500
> From: Marco Peereboom
>
> Why?
>
> RAID mode is NOT a valid ID for ahci.
Actually, it is. The hardware works exactly the same way if the
controller is in RAID mode or in AHCI. The different PCI ID acts
simply as a flag to indicate that the disks behind the controller
might contain metadata for one of the propriatery Intel software RAID
solutions. I guess it makes sure that Windows loads a different
driver that understands that metadata format instead of loading the
generic AHCI driver that would overwrite the metadata and destroy any
RAID volumes behind it. Oh, and the BIOS probably knows how to boot
from these RAID volumes as well. Note that I say *might* contain
metadata here; only when you actually create a RAID volume (through
the BIOS or other tools) the metadata will be actually there. I don't
know how Windows treats blank disks behind such a controller in RAID
mode.
Now to the question how OpenBSD should treat these controllers in RAID
mode. Ideally softraid would understand the Intel metadata format and
do the right thing. For that to work, these RAID ID's will have to be
added to the ahci(4) driver, otherwise softraid will not have access
to the disks that form the RAID volume and can't do its thing.
Perhaps some infrastructure is needed to communicate the fact that
disks are in RAID mode with softraid, such that softraid doesn't have
to check for a zillion of metadata formats. I can imagine though that
adding support for the Intel metdata format to softraid is not a
terribly high priority. Doing so really only makes sense if you want
to share the volume with Windows, otherwise you're probably much
better off using plain softraid on these disks (assuming booting from
plain softraid works).
Meanwhile, we probably should not add these RAID IDs to the ahci(4)
driver (and remove the ones that are already there). That makes sure
that there is no risk we accidentally overwrite the Intel-specific
metadata on these disks. People simply have to flip the controller
back in AHCI mode to access their disks (taking the hopefully
conscious decision to destroy any existing RAID volumes).
> On Tue, Apr 06, 2010 at 09:09:47PM -0400, Brad wrote:
> > On Mon, Mar 15, 2010 at 10:19:18PM -0400, Brad wrote:
> > > The following diff adds the remaining PCI ids for the Intel AHCI
> > > controllers with a RAID mode to the existing ICH8 / ICH10 PCI ids.
> > >
> > >
> > > Add the Intel ICH7 (82801GHM / GR), ICH9 (82801I) and ICH10 (82801JD),
> > > 6321ESB and PCH (3400) RAID mode PCI ids.
> >
> > Updated for the latest rev of ahci.c.
> >
> >
> > Index: ahci.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/ahci.c,v
> > retrieving revision 1.161
> > diff -u -p -r1.161 ahci.c
> > --- ahci.c 6 Apr 2010 13:59:37 - 1.161
> > +++ ahci.c 7 Apr 2010 00:40:18 -
> > @@ -440,11 +440,25 @@ static const struct ahci_device ahci_dev
> > { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SBX00_SATA_1,
> > NULL, ahci_ati_sb600_attach },
> >
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_RAID_1,
> > + NULL, NULL },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_RAID_2,
> > + NULL, NULL },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6321ESB_RAID_1,
> > + NULL, NULL },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6321ESB_RAID_2,
> > + NULL, NULL },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801GHM_RAID,
> > + NULL, NULL },
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801GR_RAID,
> > NULL, NULL },
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801H_RAID,
> > NULL, NULL },
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801HBM_RAID,
> > + NULL, NULL },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801I_RAID,
> > + NULL, NULL },
> > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801JD_RAID,
> > NULL, NULL },
> > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801JI_RAID,
> > NULL, NULL },
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
disklabel - 'P' option
I press 'p' then after everything I do in disklabel.
'P' automatically prints out the equivalent of 'p' after each command and saves
on finger wear and tear.
like/dislike?
-mark
Index: editor.c
===
RCS file: /cvs/src/sbin/disklabel/editor.c,v
retrieving revision 1.231
diff -u -p -r1.231 editor.c
--- editor.c4 Apr 2010 14:12:12 - 1.231
+++ editor.c6 Apr 2010 06:06:14 -
@@ -150,6 +150,7 @@ static u_int64_t starting_sector;
static u_int64_t ending_sector;
static int expert;
static int overlap;
+static int print_mode = 0;
/*
* Simple partition editor.
@@ -164,7 +165,7 @@ editor(struct disklabel *lp, int f)
char buf[BUFSIZ], *cmd, *arg;
char **omountpoints = NULL;
char **origmountpoints = NULL, **tmpmountpoints = NULL;
- int i, error = 0;
+ int i, error = 0, print_info;
/* Alloc and init mount point info */
if (!(omountpoints = calloc(MAXPARTITIONS, sizeof(char *))) ||
@@ -305,8 +306,12 @@ editor(struct disklabel *lp, int f)
editor_name(&label, arg);
break;
+ case 'P':
+ print_mode = !print_mode;
+ break;
+
case 'p':
- display_edit(&label, arg ? *arg : 0,
editor_countfree(&label));
+ print_info = 1;
break;
case 'l':
@@ -475,6 +480,14 @@ editor(struct disklabel *lp, int f)
break;
}
+ if (print_info || print_mode) {
+ if (print_mode)
+ printf("--" \
+ "--\n");
+ display_edit(&label, arg ? *arg : 0,
editor_countfree(&label));
+ print_info = 0;
+ }
+
/*
* If no changes were made to label or mountpoints, then
* restore undo info.
Re: disklabel - 'P' option
On Wed, Apr 07, 2010 at 11:21:49AM +, Mark Lumsden wrote: > I press 'p' then after everything I do in disklabel. > > 'P' automatically prints out the equivalent of 'p' after each command and > saves on finger wear and tear. > > like/dislike? Neat! Dani -- LIVAI Daniel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: disklabel - 'P' option
On 2010/04/07 11:21, Mark Lumsden wrote: > I press 'p' then after everything I do in disklabel. > > 'P' automatically prints out the equivalent of 'p' after each command and > saves on finger wear and tear. > > like/dislike? hmm..not sure. I might find it useful if it allowed setting the unit too, but I doubt I'd remember it exists when actually using disklabel. in any event, to be a complete diff it also needs - helptext entry - manpage entry details of which install media have had a test-build would be useful too..
Re: disklabel - 'P' option
> On 2010/04/07 11:21, Mark Lumsden wrote: >> I press 'p' then after everything I do in disklabel. >> >> 'P' automatically prints out the equivalent of 'p' after each command >> and saves on finger wear and tear. >> >> like/dislike? > > hmm..not sure. I might find it useful if it allowed setting the unit > too, but I doubt I'd remember it exists when actually using disklabel. > > in any event, to be a complete diff it also needs > > - helptext entry > - manpage entry > > details of which install media have had a test-build would be useful too.. > This was just a "is anyone interested" diff. If there is interest, then I'd look into progressing it, as you describe above. I realise the limitations on install media so I am not expecting too much. However, it is a beautiful option once you get used to it :) I'm sure you would not forget it ;) However, code is like marmite i find. -mark
Re: ahci(4) Intel RAID mode pci ids diff.
On Wed, Apr 07, 2010 at 11:50:51AM +0200, Mark Kettenis wrote:
> > Date: Tue, 6 Apr 2010 21:39:48 -0500
> > From: Marco Peereboom
> >
> > Why?
> >
> > RAID mode is NOT a valid ID for ahci.
>
> Actually, it is. The hardware works exactly the same way if the
> controller is in RAID mode or in AHCI. The different PCI ID acts
> simply as a flag to indicate that the disks behind the controller
> might contain metadata for one of the propriatery Intel software RAID
> solutions. I guess it makes sure that Windows loads a different
> driver that understands that metadata format instead of loading the
> generic AHCI driver that would overwrite the metadata and destroy any
> RAID volumes behind it. Oh, and the BIOS probably knows how to boot
> from these RAID volumes as well. Note that I say *might* contain
> metadata here; only when you actually create a RAID volume (through
> the BIOS or other tools) the metadata will be actually there. I don't
> know how Windows treats blank disks behind such a controller in RAID
> mode.
>
> Now to the question how OpenBSD should treat these controllers in RAID
> mode. Ideally softraid would understand the Intel metadata format and
> do the right thing. For that to work, these RAID ID's will have to be
> added to the ahci(4) driver, otherwise softraid will not have access
> to the disks that form the RAID volume and can't do its thing.
> Perhaps some infrastructure is needed to communicate the fact that
> disks are in RAID mode with softraid, such that softraid doesn't have
> to check for a zillion of metadata formats. I can imagine though that
> adding support for the Intel metdata format to softraid is not a
> terribly high priority. Doing so really only makes sense if you want
> to share the volume with Windows, otherwise you're probably much
> better off using plain softraid on these disks (assuming booting from
> plain softraid works).
>
> Meanwhile, we probably should not add these RAID IDs to the ahci(4)
> driver (and remove the ones that are already there). That makes sure
> that there is no risk we accidentally overwrite the Intel-specific
> metadata on these disks. People simply have to flip the controller
> back in AHCI mode to access their disks (taking the hopefully
> conscious decision to destroy any existing RAID volumes).
You said it in many more words but this reflects exactly my sentiment.
Until we can ignore disks in RAID mode in ahci we should not add them.
>
> > On Tue, Apr 06, 2010 at 09:09:47PM -0400, Brad wrote:
> > > On Mon, Mar 15, 2010 at 10:19:18PM -0400, Brad wrote:
> > > > The following diff adds the remaining PCI ids for the Intel AHCI
> > > > controllers with a RAID mode to the existing ICH8 / ICH10 PCI ids.
> > > >
> > > >
> > > > Add the Intel ICH7 (82801GHM / GR), ICH9 (82801I) and ICH10 (82801JD),
> > > > 6321ESB and PCH (3400) RAID mode PCI ids.
> > >
> > > Updated for the latest rev of ahci.c.
> > >
> > >
> > > Index: ahci.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/pci/ahci.c,v
> > > retrieving revision 1.161
> > > diff -u -p -r1.161 ahci.c
> > > --- ahci.c6 Apr 2010 13:59:37 - 1.161
> > > +++ ahci.c7 Apr 2010 00:40:18 -
> > > @@ -440,11 +440,25 @@ static const struct ahci_device ahci_dev
> > > { PCI_VENDOR_ATI, PCI_PRODUCT_ATI_SBX00_SATA_1,
> > > NULL, ahci_ati_sb600_attach },
> > >
> > > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_RAID_1,
> > > + NULL, NULL },
> > > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_3400_RAID_2,
> > > + NULL, NULL },
> > > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6321ESB_RAID_1,
> > > + NULL, NULL },
> > > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6321ESB_RAID_2,
> > > + NULL, NULL },
> > > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801GHM_RAID,
> > > + NULL, NULL },
> > > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801GR_RAID,
> > > NULL, NULL },
> > > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801H_RAID,
> > > NULL, NULL },
> > > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801HBM_RAID,
> > > + NULL, NULL },
> > > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801I_RAID,
> > > + NULL, NULL },
> > > + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801JD_RAID,
> > > NULL, NULL },
> > > { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801JI_RAID,
> > > NULL, NULL },
> > >
> > > --
> > > This message has been scanned for viruses and
> > > dangerous content by MailScanner, and is
> > > believed to be clean.
isakmpd: tiny patch
Hello,
while playing with isakmpd, I found that it would be nice to have a
complement for the "isakmpd: exiting" log entry.
Index: isakmpd.c
===
RCS file: /cvs/src/sbin/isakmpd/isakmpd.c,v
retrieving revision 1.97
diff -u -r1.97 isakmpd.c
--- isakmpd.c 12 May 2008 19:15:02 - 1.97
+++ isakmpd.c 7 Apr 2010 17:16:47 -
@@ -398,6 +398,7 @@
log_to(stderr);
parse_args(argc, argv);
log_init(debug);
+ log_print("isakmpd: starting");
/* Open protocols and services databases. */
setprotoent(1);
Kind regards,
--Toni++
Re: disklabel - 'P' option
When I use Disklabel, I have been in the habit of issuing 'p m ' rather than just 'p ' Since I do it for disk / usb thumb setups, and so forth, I find the 'megabyte-able' printing more consistent to my liking. I'd say leave it out, since CHS information may get scrolled off the screen if it was relevant. (Or am I thinking fdisk...?) As it is, both 'p' and 'm' keys have less wear than 'e' 't' and 's' and make for good finger dexterity... -sean > Date: Wed, 7 Apr 2010 13:41:25 +0100 > Subject: Re: disklabel - 'P' option > > On 2010/04/07 11:21, Mark Lumsden wrote: > > I press 'p' then after everything I do in disklabel. > > 'P' automatically prints out the equivalent of 'p' after each command and saves on finger wear and tear. > > like/dislike? > > hmm..not sure. I might find it useful if it allowed setting the unit > too, but I doubt I'd remember it exists when actually using disklabel. _ Live connected. Get Hotmail & Messenger on your phone. http://go.microsoft.com/?linkid=9724462
Re: remove a libcrypto dependancy in mount_vnd(8)
hey,
this was ok'ed by djm, somebody should commit it!
On Thu, Feb 04, 2010 at 19:25 +0300, Mike Belopuhov wrote:
> hey,
>
> while looking thru bioctl stuff, i've accidentaly stumbled upon
> pbkdf2 thing and found out that mount_vnd still uses local
> pkcs5_pbkdf2.c from NetBSD and links against libcrypto (although
> it's a static binary). reduction in size is about 2.5 times
> (from 353K to 145K), so it's a win, right? :)
>
> i've tested compatibility between old and new versions and
> everything looks.. er.. compatible.
>
> so sending this out that it won't be lost.
>
> Index: Makefile
> ===
> RCS file: /cvs/src/sbin/mount_vnd/Makefile,v
> retrieving revision 1.6
> diff -N -u -p Makefile
> --- Makefile 14 Jun 2008 01:47:27 - 1.6
> +++ Makefile 4 Feb 2010 16:10:01 -
> @@ -1,8 +1,11 @@
> # $OpenBSD: Makefile,v 1.6 2008/06/14 01:47:27 grunk Exp $
>
> +.PATH: ${.CURDIR}/../bioctl
> +CFLAGS+=-I${.CURDIR}/../bioctl
> +
> PROG=mount_vnd
> -SRCS=mount_vnd.c pkcs5_pbkdf2.c
> -LDADD= -lutil -lcrypto
> +SRCS=mount_vnd.c pbkdf2.c
> +LDADD= -lutil
> DPADD= ${LIBUTIL}
>
> CDIAGFLAGS+= -Wall
> Index: mount_vnd.c
> ===
> RCS file: /cvs/src/sbin/mount_vnd/mount_vnd.c,v
> retrieving revision 1.8
> diff -N -u -p mount_vnd.c
> --- mount_vnd.c 3 Sep 2008 23:24:25 - 1.8
> +++ mount_vnd.c 4 Feb 2010 16:10:01 -
> @@ -49,14 +49,14 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> #include
> #include
>
> -#include "pkcs5_pbkdf2.h"
> +#include "pbkdf2.h"
>
> #define DEFAULT_VND "svnd0"
>
> @@ -180,19 +180,20 @@ main(int argc, char **argv)
> char *
> get_pkcs_key(char *arg, char *saltopt)
> {
> - char keybuf[128], saltbuf[128], saltfilebuf[PATH_MAX];
> - char*saltfile;
> + char passphrase[128];
> + char saltbuf[128], saltfilebuf[PATH_MAX];
> char*key = NULL;
> + char*saltfile;
> const char *errstr;
> int rounds;
>
> rounds = strtonum(arg, 1000, INT_MAX, &errstr);
> if (errstr)
> err(1, "rounds: %s", errstr);
> - key = getpass("Encryption key: ");
> - if (!key || strlen(key) == 0)
> - errx(1, "Need an encryption key");
> - strncpy(keybuf, key, sizeof(keybuf));
> + bzero(passphrase, sizeof(passphrase));
> + if (readpassphrase("Encryption key: ", passphrase, sizeof(passphrase),
> + RPP_REQUIRE_TTY) == NULL)
> + errx(1, "Unable to read passphrase");
> if (saltopt)
> saltfile = saltopt;
> else {
> @@ -212,7 +213,8 @@ get_pkcs_key(char *arg, char *saltopt)
> if (fd == -1) {
> int *s;
>
> - fprintf(stderr, "Salt file not found, attempting to
> create one\n");
> + fprintf(stderr, "Salt file not found, attempting to "
> + "create one\n");
> fd = open(saltfile, O_RDWR|O_CREAT|O_EXCL, 0600);
> if (fd == -1)
> err(1, "Unable to create salt file: '%s'",
> @@ -222,18 +224,24 @@ get_pkcs_key(char *arg, char *saltopt)
> *s = arc4random();
> if (write(fd, saltbuf, sizeof(saltbuf))
> != sizeof(saltbuf))
> - err(1, "Unable to write salt file: '%s'",
> saltfile);
> - fprintf(stderr, "Salt file created as '%s'\n",
> saltfile);
> + err(1, "Unable to write salt file: '%s'",
> + saltfile);
> + fprintf(stderr, "Salt file created as '%s'\n",
> + saltfile);
> } else {
> if (read(fd, saltbuf, sizeof(saltbuf))
> != sizeof(saltbuf))
> - err(1, "Unable to read salt file: '%s'",
> saltfile);
> + err(1, "Unable to read salt file: '%s'",
> + saltfile);
> }
> close(fd);
> }
> - if (pkcs5_pbkdf2((u_int8_t**)&key, BLF_MAXUTILIZED, keybuf,
> - sizeof(keybuf), saltbuf, sizeof(saltbuf), rounds, 0))
> + if ((key = calloc(1, BLF_MAXUTILIZED)) == NULL)
> + err(1, NULL);
> + if (pkcs5_pbkdf2(passphrase, sizeof(passphrase), saltbuf,
> + sizeof (saltbuf), key, BLF_MAXUTILIZED, rounds))
> errx(1, "pkcs5_pbkdf2 failed");
> + memset(passphrase, 0, sizeof(passphrase));
>
> return (key);
> }
> Index: pkcs5_pbkdf2.c
> ===
> RCS file: /cvs/src/sbin/
Re: ahci(4) Intel RAID mode pci ids diff.
On Wednesday 07 April 2010 05:50:51 Mark Kettenis wrote: > Meanwhile, we probably should not add these RAID IDs to the ahci(4) > driver (and remove the ones that are already there). That makes sure > that there is no risk we accidentally overwrite the Intel-specific > metadata on these disks. People simply have to flip the controller > back in AHCI mode to access their disks (taking the hopefully > conscious decision to destroy any existing RAID volumes). I have no issue which way this goes as long as there is consistency. Either add all of the ids or add none of them. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: isakmpd: tiny patch
The behaviour your diff introduces isn't without precedence. Some daemons
do this when starting, some don't. Eh, not sure what to say really... Its
kind of a moot point for me.
-mark
===
Hello,
while playing with isakmpd, I found that it would be nice to have a
complement for the "isakmpd: exiting" log entry.
Index: isakmpd.c
===
RCS file: /cvs/src/sbin/isakmpd/isakmpd.c,v
retrieving revision 1.97
diff -u -r1.97 isakmpd.c
--- isakmpd.c 12 May 2008 19:15:02 - 1.97
+++ isakmpd.c 7 Apr 2010 17:16:47 -
@@ -398,6 +398,7 @@
log_to(stderr);
parse_args(argc, argv);
log_init(debug);
+ log_print("isakmpd: starting");
/* Open protocols and services databases. */
setprotoent(1);
