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;
Re: ahci(4) Intel RAID mode pci ids diff.
Date: Tue, 6 Apr 2010 21:39:48 -0500
From: Marco Peereboom sl...@peereboom.us
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 enter 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 enter 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 enter 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: 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 sl...@peereboom.us
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 enter' rather than just 'p enter' 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 enter 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 err.h
#include errno.h
#include fcntl.h
-#include pwd.h
+#include readpassphrase.h
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
#include util.h
-#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/mount_vnd/pkcs5_pbkdf2.c,v
retrieving revision 1.5
diff -N -u -p pkcs5_pbkdf2.c
---
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.
