From owner-freebsd-current Tue Jul 3 5:26:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id B558237B401 for ; Tue, 3 Jul 2001 05:26:19 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f63CPOU44707; Tue, 3 Jul 2001 15:25:24 +0300 (EEST) (envelope-from ru) Date: Tue, 3 Jul 2001 15:25:24 +0300 From: Ruslan Ermilov To: Bruce Evans Cc: Alfred Perlstein , current@FreeBSD.ORG Subject: Re: TIOCSCTTY Message-ID: <20010703152523.C39090@sunbay.com> Mail-Followup-To: Bruce Evans , Alfred Perlstein , current@FreeBSD.ORG References: <20010702111904.O84523@sneakerz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Tue, Jul 03, 2001 at 07:53:08PM +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jul 03, 2001 at 07:53:08PM +1000, Bruce Evans wrote: > On Mon, 2 Jul 2001, Alfred Perlstein wrote: > > > * Ruslan Ermilov [010702 10:51] wrote: > > > Hi! > > > > > > Could someone please explain why the following code snippet > > > does not work anymore with the "/dev/console" argument? > > > > > > # ./tiocsctty /dev/console > > > tiocsctty: ioctl(/dev/console, TIOCSCTTY): Operation not permitted > > This still works here. Perhaps another process has aquired /dev/console > as its controlling terminal. > Weird. I figured out what causes this, it's moused(8). I have inserted some debug code into it to see what's going on: This is the "ps axjww" and "pstat -t" output before moused(8) calls daemon(3): USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND root 0 0 0 241c60 0 DLs ?? 0:00.00 (swapper) root 1 0 1 b14840 0 SLs ?? 0:00.00 /sbin/init -- root 2 0 0 241c60 0 DL ?? 0:00.00 (pagedaemon) root 3 0 0 241c60 0 DL ?? 0:00.00 (vmdaemon) root 4 0 0 241c60 0 DL ?? 0:00.00 (bufdaemon) root 5 0 0 241c60 0 DL ?? 0:00.00 (syncer) root 26 1 26 b75fc0 0 Ss ?? 0:00.00 adjkerntz -i root 128 1 128 b75340 0 Ss ?? 0:00.00 /sbin/natd -n rl0 root 149 1 149 b753c0 0 Ss ?? 0:00.03 syslogd -s daemon 156 1 156 b801c0 0 Ss ?? 0:00.00 /usr/sbin/portmap root 162 1 162 b92940 0 Ss ?? 0:00.01 amd -p -a /.amd_mnt -l syslog /host /etc/amd.map root 179 1 179 b92200 0 Ss ?? 0:00.01 /usr/sbin/cron root 182 1 182 bf8ec0 0 Ss ?? 0:00.96 /usr/sbin/sshd root 6 1 6 b14700 0 Ss+ con 0:00.13 sh /etc/rc autoboot root 214 6 6 b14700 0 S+ con 0:00.01 moused -3 -p /dev/cuaa1 -t auto root 218 214 6 b14700 0 S+ con 0:00.00 sh -c (ps axjww; pstat -t) >>/1 root 219 218 6 b14700 0 S+ con 0:00.00 sh -c (ps axjww; pstat -t) >>/1 root 220 219 6 b14700 0 R+ con 0:00.00 ps axjww LINE RAW CAN OUT IHIWT ILOWT OHWT LWT COL STATE SESS PGID DISC cuaa1 0 0 0 512 448 216 60 0 OCcl 0 0 term consolectl 0 0 0 512 448 1296 256 98 OCc c0b14700 6 term 0 0 0 0 0 0 0 0 0 - 0 0 term ttyp0 0 0 0 0 0 0 0 0 - 0 0 term ttyv0 0 0 0 512 448 1296 256 0 - 0 0 term As you can see, process 6 (sh /etc/rc autoboot) is the session leader with /dev/console as the controlling terminal, and the same session is referenced from the `tty' structure for the consolectl device. Next, this is after moused(8) calls daemon(3): USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND root 0 0 0 241c60 0 DLs ?? 0:00.00 (swapper) root 1 0 1 b14840 0 SLs ?? 0:00.00 /sbin/init -- root 2 0 0 241c60 0 DL ?? 0:00.00 (pagedaemon) root 3 0 0 241c60 0 DL ?? 0:00.00 (vmdaemon) root 4 0 0 241c60 0 DL ?? 0:00.00 (bufdaemon) root 5 0 0 241c60 0 DL ?? 0:00.00 (syncer) root 26 1 26 b75fc0 0 Ss ?? 0:00.00 adjkerntz -i root 128 1 128 b75340 0 Ss ?? 0:00.00 /sbin/natd -n rl0 root 149 1 149 b753c0 0 Ss ?? 0:00.03 syslogd -s daemon 156 1 156 b801c0 0 Ss ?? 0:00.00 /usr/sbin/portmap root 162 1 162 b92940 0 Ss ?? 0:00.01 amd -p -a /.amd_mnt -l syslog /host /etc/amd.map root 179 1 179 b92200 0 Ss ?? 0:00.01 /usr/sbin/cron root 182 1 182 bf8ec0 0 Ss ?? 0:00.96 /usr/sbin/sshd root 221 1 221 bf8280 0 Ss ?? 0:00.00 moused -3 -p /dev/cuaa1 -t auto root 223 221 221 bf8280 0 S ?? 0:00.00 sh -c (ps axjww; pstat -t) >>/1 root 225 223 221 bf8280 0 S ?? 0:00.00 sh -c (ps axjww; pstat -t) >>/1 root 227 225 221 bf8280 0 R ?? 0:00.00 ps axjww root 6 1 6 b14700 0 Ss+ con 0:00.14 sh /etc/rc autoboot root 228 6 6 b14700 0 R+ con 0:00.00 sh /etc/rc autoboot LINE RAW CAN OUT IHIWT ILOWT OHWT LWT COL STATE SESS PGID DISC cuaa1 0 0 0 512 448 216 60 0 OCcl 0 0 term consolectl 0 0 0 512 448 1296 256 109 OCc c0b14700 6 term 0 0 0 0 0 0 0 0 0 - 0 0 term ttyp0 0 0 0 0 0 0 0 0 - 0 0 term ttyv0 0 0 0 512 448 1296 256 0 - 0 0 term Nothing has changed re: consolectl. It still has session c0b14700 (with the session leader PID = 6) bound to it. moused(8) becomes a session leader for a new session with address c0bf8280 (note that MSB of the session address is not shown in the ps(1) output). Next, this is the output after the system has booted into multi-user: USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND root 0 0 0 241c60 0 DLs ?? 0:00.00 (swapper) root 1 0 1 b14840 0 ILs ?? 0:00.01 /sbin/init -- root 2 0 0 241c60 0 DL ?? 0:00.00 (pagedaemon) root 3 0 0 241c60 0 DL ?? 0:00.00 (vmdaemon) root 4 0 0 241c60 0 DL ?? 0:00.00 (bufdaemon) root 5 0 0 241c60 0 DL ?? 0:00.01 (syncer) root 26 1 26 b75fc0 0 Is ?? 0:00.00 adjkerntz -i root 128 1 128 b75340 0 Ss ?? 0:00.00 /sbin/natd -n rl0 root 149 1 149 b753c0 0 Ss ?? 0:00.03 syslogd -s daemon 156 1 156 b801c0 0 Is ?? 0:00.00 /usr/sbin/portmap root 162 1 162 b92940 0 Ss ?? 0:00.01 amd -p -a /.amd_mnt -l syslog /host /etc/amd.map root 179 1 179 b92200 0 Is ?? 0:00.01 /usr/sbin/cron root 182 1 182 bf8ec0 0 Is ?? 0:00.96 /usr/sbin/sshd root 221 1 221 bf8280 0 Ss ?? 0:00.08 moused -3 -p /dev/cuaa1 -t auto root 253 1 253 c02bc0 0 Is+ v0 0:00.01 /usr/libexec/getty Pc ttyv0 root 254 1 254 c02b00 0 Is v1 0:00.06 -csh (csh) root 265 254 265 c02b00 1 S v1 0:00.07 deco root 276 265 276 c02b00 1 S+ v1 0:00.00 sh -c ps axjww >> 11 root 277 276 276 c02b00 1 R+ v1 0:00.00 ps axjww root 255 1 255 c02a40 0 Is+ v2 0:00.01 /usr/libexec/getty Pc ttyv2 root 256 1 256 c02980 0 Is+ v3 0:00.01 /usr/libexec/getty Pc ttyv3 root 257 1 257 c02940 0 Is+ v4 0:00.01 /usr/libexec/getty Pc ttyv4 root 258 1 258 c02900 0 Is+ v5 0:00.01 /usr/libexec/getty Pc ttyv5 root 259 1 259 c028c0 0 Is+ v6 0:00.01 /usr/libexec/getty Pc ttyv6 root 260 1 260 c02800 0 Is+ v7 0:00.01 /usr/libexec/getty Pc ttyv7 root 261 1 261 c02e00 0 Is+ v8 0:00.01 /usr/libexec/getty Pc ttyv8 root 262 1 262 c02d40 0 Is+ v9 0:00.01 /usr/libexec/getty Pc ttyv9 root 263 1 263 c02c80 0 Is+ va 0:00.01 /usr/libexec/getty Pc ttyva The session c0b14700 has disappeared from the ps(1) output, but it is still referenced from the `tty' structure: LINE RAW CAN OUT IHIWT ILOWT OHWT LWT COL STATE SESS PGID DISC ttyvb 0 0 0 512 448 1296 256 0 - 0 0 term ttyva 0 0 0 512 448 2052 256 7 OCc c0c02c80 263 term ttyv9 0 0 0 512 448 2052 256 7 OCc c0c02d40 262 term ttyv8 0 0 0 512 448 2052 256 7 OCc c0c02e00 261 term ttyv7 0 0 0 512 448 2052 256 7 OCc c0c02800 260 term ttyv6 0 0 0 512 448 2052 256 7 OCc c0c028c0 259 term ttyv5 0 0 0 512 448 2052 256 7 OCc c0c02900 258 term ttyv4 0 0 0 512 448 2052 256 7 OCc c0c02940 257 term ttyv3 0 0 0 512 448 2052 256 7 OCc c0c02980 256 term ttyv2 0 0 0 512 448 2052 256 7 OCc c0c02a40 255 term ttyv1 0 0 0 512 448 2052 256 0 OCc c0c02b00 279 term cuaa1 0 0 0 512 448 216 60 0 OCcl 0 0 term consolectl 0 0 0 512 448 1296 256 0 OCc c0b14700 0 term 0 0 0 0 0 0 0 0 0 - 0 0 term ttyp0 0 0 0 0 0 0 0 0 - 0 0 term ttyv0 0 0 0 512 448 2052 256 7 OCc c0c02bc0 253 term If I then kill moused(8), tty's t_session pointer is reset, and the next TIOCSCTTY call to /dev/console succeeds. The problem could also be demonstrated by running the following small program from /etc/rc.local. It emulates actions performed by moused(8), except moused(8) opens /dev/consolectl before a call to daemon(3), and this one opens /dev/consolectl only in a new session. What I can't understand is how opening a /dev/consolectl in a new session doesn't allow the t_session tty pointer to be reset that points to another (not existing) session. (This is probably somehow relates to the fact that the device's close() routine is called only on a last reference drop, but I'm not sure.) Run this from /etc/rc.local: #include #include #include #include #include int main(void) { int fd; if (daemon(0, 0) == -1) err(1, "daemon"); if ((fd = open("/dev/consolectl", O_RDWR)) == -1) err(1, "open /dev/consolectl"); for (;;) sleep(1000); exit(0); } Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message