This problem is driving me crazy!

I use "/etc/ttys" on FreeBSD to configure the commands that are executed when getty is executed.

This is the relevant line of my config file /etc/ttys:

ttyv8   "/usr/local/bin/startx" xterm on secure

My problem is that, on boot, the current console switches to ttyv8 (working as expected), then my VirtualBox window resizes (which normally indicates that the X Server is taking control over the graphics output), but then the X server immediately closes. FreeBSD tries again 5 times, waits 30 seconds and tries again 5 times, waits 30 seconds, and so on. This is driving me crazy!

However, after logging in on a text console and running startx from there, it works completely fine without any problems. I don't have a ~/.xinitrc but modified the default xinit file in /usr/local/etc/X11/xinit .

When I tried debugging the whole stuff adding a pipe to my tty command:

ttyv8   "/usr/local/bin/startx > /tmp/startx.log" xterm on secure

the startx.log did not exist. It simply did not work. However, the standard Xorg.0.log gets updated with every try getty makes to start the x server. The Xorg.0.log simply says nothing. Just that it ended successfully after drivers etc. were loaded. It's like my xinitrc would not have been read at all.

Please notice, that I don't want to use a login manager and that I don't want any auto login mechanism.

Thank you in advance.

2 Answers 2

ttyv8   "/usr/local/bin/startx" xterm on secure

Close, but wrong.

The manual for ttys gives an example of how to do exactly this. You need to specify your actual X server with a window= setting and specify the initial X client to run in the second field of the record:

# terminal emulate/window system
ttyv0   "/usr/local/bin/xterm -display :0"      xterm   on window="/usr/local/bin/X :0"

Personally, I recommend against using this mechanism of ttys, for three reasons:

  • The restart behaviour is not pretty, as you have discovered. In fact, there's almost zero configurability of this as compared to a proper service manager, where one can fairly simply do things like configure environment variables for the X client and server and enable/disable services.
  • This isn't really how one does this once one has a desktop manager in the mix. The FreeBSD Handbook shows how to run the various destkop managers via their respective Mewburn rc scripts, enabled/disabled by settings in rc.conf. TrueOS replaces this with PCDM, invoked by an OpenRC script. No ttys database entries are involved in either.
  • This isn't how one does this under nosh service management, which has service bundles for PCDM and the various desktop managers, and for which one would similarly use a service bundle to start a plain X server and client, both enabled and disabled in the normal way for such service bundles. No ttys database entries involved.

I recommend that you write a Mewburn rc script, an OpenRC script, or even a nosh service bundle to run your X server and client.

Further reading


I'm using the following way:

  1. On ttyv0 my user automatically log in.
  2. My ~/.login checks the tty. If it's ttyv0 will run startx.
  3. After end of startx (close the xorg session) asks about halt/reboot.


1. Automatically login: to /etc/ttys:

ttyv0   "/usr/libexec/getty autologin" xterm   on  secure

and to /etc/gettytab:


2. & 3. Relevant content of ~/.login. I'm using tcsh but the idea works on sh too:

if ($tty == "ttyv0") then
  echo Starting Xorg...
  echo "Halt (h) Reboot (r) Nothing (n) ?"
  set answer = $<
  if ($answer == "h") then
    /sbin/shutdown -p now
  else if ($answer == "r") then
    /sbin/shutdown -r now
  • The questioner said that xe did not want an automatic login way of doing this. Xe is trying to get ttys to do this, as the manual page for ttys says that it can be done.
    – JdeBP
    Commented May 14, 2018 at 19:37
  • Maybe you've right. I thought xe doesn't wants autologin with DM.
    – uzsolt
    Commented May 15, 2018 at 4:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .