Switch TTY on Boot?

jrt03

Member

Reaction score: 1
Messages: 21

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 :)
 

fonz

Son of Beastie

Reaction score: 370
Messages: 2,560

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
 
OP
J

jrt03

Member

Reaction score: 1
Messages: 21

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).
 

fonz

Son of Beastie

Reaction score: 370
Messages: 2,560

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.
 

Zare

Well-Known Member

Reaction score: 56
Messages: 386

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.
 

fonz

Son of Beastie

Reaction score: 370
Messages: 2,560

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.
 
OP
J

jrt03

Member

Reaction score: 1
Messages: 21

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?
 

Zare

Well-Known Member

Reaction score: 56
Messages: 386

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.
 
OP
J

jrt03

Member

Reaction score: 1
Messages: 21

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!
 

Zare

Well-Known Member

Reaction score: 56
Messages: 386

How about instead starting it from /etc/ttys then?

We think alike. There are a few caveats, however. Posting results soon.
 

fonz

Son of Beastie

Reaction score: 370
Messages: 2,560

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?
 
OP
J

jrt03

Member

Reaction score: 1
Messages: 21

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!
 

Zare

Well-Known Member

Reaction score: 56
Messages: 386

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.
 
OP
J

jrt03

Member

Reaction score: 1
Messages: 21

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 ;)
 

Zare

Well-Known Member

Reaction score: 56
Messages: 386

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 ;)
 

fonz

Son of Beastie

Reaction score: 370
Messages: 2,560

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
 

Zare

Well-Known Member

Reaction score: 56
Messages: 386

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.
 
OP
J

jrt03

Member

Reaction score: 1
Messages: 21

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!
 

Zare

Well-Known Member

Reaction score: 56
Messages: 386

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.
 
OP
J

jrt03

Member

Reaction score: 1
Messages: 21

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.
 

debguy

Active Member

Reaction score: 11
Messages: 139

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.
 

debguy

Active Member

Reaction score: 11
Messages: 139

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.
 

wblock@

Beastie Himself
Developer

Reaction score: 3,695
Messages: 13,851

debguy said:
WAIT WAIT. you can use chvt(1) and openvt(1) todo vt things.

Not on FreeBSD:

Code:
% which chvt openvt
chvt: Command not found.
openvt: Command not found.
 

DutchDaemon

Administrator
Staff member
Administrator
Moderator
Developer

Reaction score: 2,986
Messages: 11,357

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.
 
Top