Switch TTY on Boot?

I have a custom dialog/console application that opens once the my 8.2 system has finished booting, but there are occasional kernel and system messages that output to tty1 over my dialog application, which makes my application almost undecipherable.

I've been able to silence most of the system messages via syslog modifications, but from what I understand, some kernel and hardware related messages will always output to tty1. Is there a way I can boot into a different tty by default so I can run my application on tty2 and never have to worry about system console messages?

Any other solutions or ideas are greatly appreciated :)
 
jrt03 said:
from what I understand, some kernel and hardware related messages will always output to tty1.
They probably shouldn't, but it's my experience as well that they do.

jrt03 said:
Is there a way I can boot into a different tty by default so I can run my application on tty2 and never have to worry about system console messages?
Would using vidcontrol(1) with the -s option at the end of the boot sequence (e.g. in /etc/rc.local) be an acceptable workaround?

Fonz
 
fonz said:
Would using vidcontrol(1) with the -s option at the end of the boot sequence (e.g. in /etc/rc.local) be an acceptable workaround?

I'll give that a try. A separate issue I've had in 8.2 is that I've noticed switching tty's causes an odd lag time of a 2 seconds or so. I haven't dug into what's causing this, but it seems to freeze the system for those two seconds and some of my heartbeat monitoring daemons start throwing errors when set to a lower threshold (1 second).
 
jrt03 said:
A separate issue I've had in 8.2 is that I've noticed switching tty's causes an odd lag time of a 2 seconds or so.
That does sound like a separate issue indeed and shouldn't normally happen.
 
Would using vidcontrol(1) with the -s option at the end of the boot sequence (e.g. in /etc/rc.local) be an acceptable workaround?

Some daemons start after rc.local. If OP's program is not directly dependent on rc.d invoked daemons, detaching a command inside rc.local (eg. &) would do the trick.

vidcontrol(1)() should be used for interactive vty change.
 
Zare said:
detaching a command inside rc.local (eg. &) would do the trick.
If I understand the OP correctly, an interactive dialog system is started on the console after boot.
 
I quickly tried putting the vidcontrol command in rc.local and even in cron with @reboot, but no luck thus far. My daemon is actually invoked by the rc.d system, but I could move some things around need be.

Anyone know how to delegate a different tty as the "main" tty for console messages or does switching to a different tty on boot seem to be the best solution?
 
If I understand correctly, you want to let system boot, and instead of landing on ttyv(0), it should switch to another console where your program is running?

Please confirm this so I can do a quick test.
 
Zare said:
If I understand correctly, you want to let system boot, and instead of landing on ttyv(0), it should switch to another console where your program is running?

Please confirm this so I can do a quick test.

That is correct. Either that or find a different way to avoid system console messages outputting over my console daemon.

Thanks!
 
jrt03 said:
or find a different way to avoid system console messages outputting over my console daemon.
Just a quick question: does your /etc/syslog.conf file contain any references to /dev/console?
 
fonz said:
Just a quick question: does your /etc/syslog.conf file contain any references to /dev/console?

Nope, I have commented out the default entry to /dev/console and am redirecting messages to a log file. This covers most cases, but not all messages the kernel might produce.

I have also switched my console application over to being controlled by /etc/ttys. Once I figure out how to switch ttys on boot, I'll be set. Thank you guys for your help!
 
getty needs to set up the tty before it's usable. Unfortunately login program cannot be specified via arguments. I can't find a way to configure it, and I also can't find a FreeBSD-compatible replacement.
 
Zare said:
getty needs to set up the tty before it's usable. Unfortunately login program cannot be specified via arguments. I can't find a way to configure it, and I also can't find a FreeBSD-compatible replacement.

I just got my application running on boot in my tty without login by modifying /etc/ttys and /etc/gettytab. I'm still not sure where I should attempt to switch force the tty switch. I'm going to try assigning my console application to ttyv2 and have my console application invoke vidcontrol and see if it can switch focus to itself ;)
 
That or rc.local. Can you paste your /etc/gettytab and /etc/ttys modification? I went on modifying getty's source and succeeded, still need to comment out the login prompt getty reads in, but your solution seems less-of-a-hack so I'll gladly write it down ;)
 
jrt03 said:
I'm going to try assigning my console application to ttyv2 and have my console application invoke vidcontrol and see if it can switch focus to itself ;)
Some testing here suggests that might work. When I do
% sleep 3 && vidcontrol -s 3
and then switch to a different console, it jumps back after 3 seconds.

Fonz
 
If you want to do that in-code (where 'n' is the vty number) :

Code:
ioctl(0, VT_ACTIVATE, n);

However you'll have to build it using BSD's src infrastructure. Check out /usr/src/usr.sbin/vidcontrol/ , the Makefile and included headers, and adapt it to your program.
 
Zare said:
That or rc.local. Can you paste your /etc/gettytab and /etc/ttys modification? I went on modifying getty's source and succeeded, still need to comment out the login prompt getty reads in, but your solution seems less-of-a-hack so I'll gladly write it down ;)

Sure thing! I added the following to my /etc/gettytab:
Code:
ConsoleApp|console|Console Application:\
:ht:np:sp#115200:lo=/usr/local/bin/customconsole.sh:al=root:

My /usr/local/bin/customconsole.sh sets the appropriate env variables (PATH, PYTHONPATH, etc) and then calls
Code:
exec /usr/local/bin/console

My /etc/ttys simply has an entry like so:
Code:
ttyv4 "/usr/libexec/getty console"    cons25  on  secure

Hope this helps!
 
I'd suggest that customsconsole.sh simulates a full user login using su(1)(), eg.

Code:
#!/bin/sh
su -l someuser -c /usr/local/bin/console

...and export env vars via that user's profile. You won't have security issues with running your program as root. Besides, if your program misbehaves during external calls, you can login as that user and run stuff manually to locate the problem.
 
Zare said:
I'd suggest that customsconsole.sh simulates a full user login using su(1)(), eg.

Code:
#!/bin/sh
su -l someuser -c /usr/local/bin/console

...and export env vars via that user's profile. You won't have security issues with running your program as root. Besides, if your program misbehaves during external calls, you can login as that user and run stuff manually to locate the problem.

You are absolutely correct and this should be noted for other people using this solution. There are a few unfortunate things in my situation that prevent me from doing this on this box.
 
You can use chvt(1) and openvt(1) todo vt things.

However: init->getty and syslogd puts the messgages. You want to edit your syslog configuration to put the error messages on an unused tty instead of "all tty". Read about it you'll see.
 
Example:
Code:
# from FILE : /etc/syslogd.conf
# Emergencies are sent console of everybody logged in.
*.crit                          *
*.alert                         *
*.emerg                         *

Do you see that in yours? If so remove it. You can even configure so that all message go to null or all to file and never to TTY or console.
 
Yes, can we stop confusing FreeBSD users with non-existent and/or Linux-only commands, please? This is not the first time you've done this, and it needs to stop. Also make sure you act on the PM you received.
 
Back
Top