From owner-freebsd-questions@FreeBSD.ORG Tue Aug 17 02:29:41 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71C9A106566C for ; Tue, 17 Aug 2010 02:29:41 +0000 (UTC) (envelope-from bounce@paleogene.net) Received: from frodo.paleogene.net (frodo.paleogene.net [206.125.175.178]) by mx1.freebsd.org (Postfix) with ESMTP id 3AF8D8FC0A for ; Tue, 17 Aug 2010 02:29:40 +0000 (UTC) Received: from auth-client.paleogene.net (auth-client.paleogene.net [206.125.175.178]) (Authenticated sender: hidden) by frodo.paleogene.net (Postfix) with ESMTPSA id 0618E3F427 ; Mon, 16 Aug 2010 22:13:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=markshroyer.com; s=default; t=1282011189; bh=z6Mtr5DYksYEnX6kdAHYUNfzc9w72vdUMBSsvmcB/UQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=YCi2ZW+ZYM4uHeguiG3Ky4z0Kb0cN4MkNzAjSUML3zJk3/77OA5rju1b4g1txLQun FpaiNLsded37YGGhzwz/2umS4s1CTWNzH31FVOvIKE3W+nRjAaOO8OcSMzhCHtRAFT otxS4IHntC+mO6IRuQDz9g302bxY6Z1MVnIh3amE= From: Mark Shroyer To: freebsd-questions@freebsd.org Cc: References: <4C69D13F.9080404@dannysplace.net> <20100817032327.0349772b.freebsd@edvax.de> Date: Mon, 16 Aug 2010 22:13:06 -0400 In-Reply-To: <20100817032327.0349772b.freebsd@edvax.de> (Polytropon's message of "Tue, 17 Aug 2010 03:23:27 +0200") Message-ID: <84y6c6rnpp.fsf@shroyer.name> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Upgrading ports while processes are running. X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 02:29:41 -0000 On Tue, 17 Aug 2010 03:23:27 +0200, Polytropon wrote: > At least, the step that wants to write will fail, and this will > mostly be (finally) signaled by a make error. This is sort of pedantic for me to bring up, but I wouldn't count on the install failing. Because Unix makes a distinction between unlinking and file deletion, you can generally unlink the binary of a running executable without any problem; the filesystem won't actually delete it at least until the process in question stops running and the inode's reference count drops to zero. See Advanced Programming in the Unix Environment for details. Here's a quick example on FreeBSD: $ cat hello.c #include int main(int argc, char* argv[]) { while (1) { printf("Hello\n"); sleep(1); } return 0; } $ cc -o hello hello.c $ ./hello This simple program will start printing "Hello" repeatedly. Now if I switch to another terminal, I can delete the hello binary: $ rm hello But switching back to the first terminal, I see the program is still running just fine. Running programs can be unlinked. And this is what the install program used by FreeBSD ports appears to do; from /usr/src/usr.bin/xinstall/install.c: create_newfile(const char *path, int target, struct stat *sbp) { char backup[MAXPATHLEN]; int saved_errno = 0; int newfd; if (target) { /* * Unlink now... avoid ETXTBSY errors later. Try to turn * off the append/immutable bits -- if we fail, go ahead, * it might work. */ if (sbp->st_flags & NOCHANGEBITS) (void)chflags(path, sbp->st_flags & ~NOCHANGEBITS); if (dobackup) { if ((size_t)snprintf(backup, MAXPATHLEN, "%s%s", path, suffix) != strlen(path) + strlen(suffix)) errx(EX_OSERR, "%s: backup filename too long", path); (void)snprintf(backup, MAXPATHLEN, "%s%s", path, suffix); if (verbose) (void)printf("install: %s -> %s\n", path, backup); if (rename(path, backup) < 0) err(EX_OSERR, "rename: %s to %s", path, backup); } else if (unlink(path) < 0) saved_errno = errno; } newfd = open(path, O_CREAT | O_RDWR | O_TRUNC, S_IRUSR | S_IWUSR); if (newfd < 0 && saved_errno != 0) errno = saved_errno; return newfd; } That isn't to say you won't see any negative consequences from overwriting a running port with a newer version. Hypothetically, you might install a new Python including a new standard library, and if your running (old) Python process tries to load one of its deleted modules from disk something could break. Or not; I'm no expert on the ports system, they might have some way of working around this. But as for a pragmatic answer to your question, I err on the side of caution with this stuff :) -- Mark Shroyer http://markshroyer.com/contact/