Date: Wed, 07 Apr 1999 14:29:36 +0800 From: Peter Wemm <peter@netplex.com.au> To: Bruce Evans <bde@zeta.org.au> Cc: brian@Awfulhak.org, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/cron/cron popen.c Message-ID: <199904070629.OAA09658@spinner.netplex.com.au> In-Reply-To: Your message of "Wed, 07 Apr 1999 15:58:31 %2B1000." <199904070558.PAA18555@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904070629.OAA09658>