From owner-cvs-all Tue Apr 6 23:33:17 1999 Delivered-To: cvs-all@freebsd.org Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (Postfix) with ESMTP id 13F8F1527D; Tue, 6 Apr 1999 23:33:07 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.3/8.9.3/Netplex) with ESMTP id OAA09658; Wed, 7 Apr 1999 14:29:36 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199904070629.OAA09658@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Bruce Evans Cc: brian@Awfulhak.org, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/cron/cron popen.c In-reply-to: Your message of "Wed, 07 Apr 1999 15:58:31 +1000." <199904070558.PAA18555@godzilla.zeta.org.au> Date: Wed, 07 Apr 1999 14:29:36 +0800 From: Peter Wemm Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Bruce Evans wrote: > >What I'd like to know though, is why a fd to /dev/console gets revoked > >when something does a revoke("/dev/ttyv0") - they have different minor/major > >numbers and you can see the difference between the two via ps. I'd have > >thought that fd's to /dev/console should never be revoked... > > /dev/console doesn't get revoked here. My test: > > # cat >/dev/console > 1 > 2 > 3 > 4 > [above shows up correctly on /dev/ttyv0] > ^Z > # revoke /dev/console # use my handy revoke utility > [login on /dev/ttyv0 gets killed correctly] > % > 1 > 2 > 3 > 4 > [above still shows up on /dev/ttyv0] > > A getty directly on /dev/console may cause more mysterious behaviour. > This is simpler for syscons vtys than for serial consoles. The syscons > /dev/console has an extra layer of aliasing (which was once necessary > to avoid problems with revoked consoles but shouldn't be necessary now). I've checked your test here too and get the same result. I suspect something wierd is happening with the fd's obtained during /sbin/init's initial environment and the lifetime of /etc/rc. Well, *something* is revoking it: pwroot@overcee[2:07pm]~ports/databases/mysql322-153# fstat | grep cron root cron 183 root / 2 drwxr-xr-x 1024 r root cron 183 wd /var 3 drwxr-x--- 512 r root cron 183 text /usr 31853 -r-xr-xr-x 26316 r root cron 183 0 - - none - root cron 183 1 - - none - root cron 183 2 - - none - root cron 183 3 /var 28822 -rw-r--r-- 4 rw root cron 183 4* local dgram c6b01f40 <-> c6b00fc0 lsof shows more detail: pwroot@overcee[2:08pm]~ports/databases/mysql322-154# lsof | grep cron cron 183 root cwd VDIR 0,131077 512 3 /var/cron cron 183 root rtd VDIR 0,131072 1024 2 / cron 183 root txt VREG 0,131076 26316 31853 /usr/sbin/cron cron 183 root txt VREG 0,131076 65480 231161 /usr/libexec/ld-elf.so.1 cron 183 root txt VREG 0,131076 31383 72415 /usr/lib/libutil.so.2 cron 183 root txt VREG 0,131076 537944 72391 /usr/lib/libc.so.3 cron 183 root 0u VBAD (revoked) cron 183 root 1u VBAD (revoked) cron 183 root 2u VBAD (revoked) cron 183 root 3uW VREG 0,131077 4 28822 /var/run/cron.pid cron 183 root 4u unix 0xc5fe8f00 0t0 ->0xc5fe7d80 Cron is started from /etc/rc as usual. Also: 311 con- I+ 0:00.08 /usr/local/sbin/radiusd 315 con- I+ 0:00.07 /usr/local/sbin/radiusd 326 con- I+ 0:00.06 /usr/local/sbin/rplayd Nothing wierd in ttys: console none unknown off secure ttyv0 "/usr/libexec/getty Pc" cons25 on secure Other wierd things: If bootup hangs, eg: network disconnected causes dns hang, a ^C on the ttyv0 console kills the process in question. However, if I boot the system from a serial console, a ^C on the console during boot causes "[not a controlling tty]" and nothing will kill it short of breaking into the debugger and forcing a shutdown. This is with a relatively standard /etc/ rc and /sbin/ init setup, there is nothing different to src/etc/* on those machines. (Some machines have vga cards, some don't. some don't have the sc0 driver, some have options COMCONSOLE, some are booted in comconsole mode as a result of a failed keyboard probe, etc. I don't have a single machine that responds to ctrl-C or ctrl-\ during boot on a comconsole). Now that I think about it, I do recall that sometimes some of the systems respond to ^C during /etc/rc execution under some circumstances, I think one is that if I boot -s and go into and out of single user, then I can interrupt the /etc/rc script. I don't recall exactly and I don't have a machine handy that I can test this on, they're all busy... Oh, one one other machine, I had not commented out the /dev/console syslog.conf entry. It shows: syslogd 121 root 15w VBAD (revoked) cron 194 root 0u VBAD (revoked) cron 194 root 1u VBAD (revoked) cron 194 root 2u VBAD (revoked) This is a comconsole machine where the bootblocks detect no keyboard and sio0 has flags 0x10. I think having syslogd loose it's /dev/console log output is a bit of a problem. > Bruce Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message