Xref: utzoo comp.unix.wizards:22387 comp.bugs.4bsd:1567 Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!mimsy!mojo!mojo!djm From: djm@eng.umd.edu (David J. MacKenzie) Newsgroups: comp.unix.wizards,comp.bugs.4bsd Subject: Re: more BSD strangeness -- syslogd.c Message-ID: Date: 9 Jun 90 06:46:17 GMT References: <1990Jun8.070904.7466@athena.mit.edu> <36447@sequent.UUCP> Sender: news@eng.umd.edu (The News System) Organization: University of Maryland Lines: 24 In-Reply-To: keany@sequent.UUCP's message of 8 Jun 90 21:21:00 GMT In article <36447@sequent.UUCP> keany@sequent.UUCP (Bernard Keany) writes: >> (void) open("/", 0); >> (void) dup2(0, 1); >> (void) dup2(0, 2); >>OK, so why is it opening "/"? Is this a poor man's equivalent to >>/dev/null, and if so, why doesn't it just open /dev/null? > "Change the working directory to /. Each process has a current working > directory, and the kernel holds this directory file open during the life > of the process. If a process has a current directory in a mounted file > system, the file system is "in use" and cannot be dismounted by the > administrator without first finding and killing the offending process. Almost. That's an *open*, not a *chdir*! But the principle is the same: syslog wants to make sure that it doesn't hold open any files on stdin, stdout, or stderr that would tie up a filesystem. I presume that after that it makes no references to stdin, stdout, and stderr. Not that /dev/null is going to be on a different filesystem, but "/" is guaranteed to exist, so why not use it? -- David J. MacKenzie