Automatic startx doesn't work

[Shadowigor]

I appended the following to my ~/.config/fish/config.fish as suggested here https://wiki.archlinux.org/index.php/Start_X_at_login:

# Start X at login
if status --is-login
  if test -z "$DISPLAY" -a $XDG_VTNR = 1
    exec startx
  end
end

Unfortunately, this doesn't work. It just hangs and after a while I get kicked out and see the login prompt again. If I omit the 'exec'. It also hangs and I get to a shell after a while. If I manually enter 'startx', everything works fine. Is there a fix for that? I already saw Issue #1281 and that's not the problem. My '/usr/bin/startx' has the '#!/bin/sh' line as the very fist line.

[zanchey]

I gave this a shot, and it worked ok for me (although I'm running Debian, not Arch, so I don't have XDG_VTNR set and had to change the script to remove that test).

It might be worth changing the startx shebang from #!/bin/sh to #!/bin/sh -x temporarily, so that you can work out exactly what the script is hanging on.

[necrophcodr]

After checking this out on my Funtoo installation, I cannot confirm any XDG_VTNR variable to exist. I suggest omitting it, since DISPLAY will be set as long as the X server is started (and a display is connected).

[zanchey]

http://unix.stackexchange.com/questions/62722/start-x-after-automatic-login might be related.

[siteshwar]

Does startx work if you are not using fish as default shell ?

[fargledaer]

I installed fish (2.1.1) on my Arch system (3.18.2-2-ARCH #1 SMP PREEMPT Fri Jan 9 07:37:51 CET 2015 x86_64 GNU/Linux) today and ran into the same issue.

My ~/.config/fish/config.fish is identical to the one in the initial post. When I login on tty1, nothing happens, and eventually I fall back to a login prompt. If I comment out the exec startx line, login works, and so does startx when I run it manually from the fish prompt. Additionally, if I switch my login shell to bash and add exec startx to ~/.bash_profile, it works as expected.

I investigated a bit further by adding some debug echoes to /usr/bin/startx, and found that it was hanging on this command:
xinit /home/<username>/.xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -auth /tmp/serverauth.wgAjQEOgOx

I tried switching window managers in my ~/.xinitrc (from i3 to openbox) to rule out any window-manager-specific interactions. Same behavior.

Here's what journalctl --follow shows during a login attempt (asterisks added by me):

   Jan 19 02:24:14 <hostname> systemd[1]: Started Getty on tty1.
   Jan 19 02:24:35 <hostname> login[5422]: pam_unix(login:session): session opened for user <username> by LOGIN(uid=0)
   Jan 19 02:24:35 <hostname> systemd[1]: Starting Session c36 of user <username>.
   Jan 19 02:24:35 <hostname> systemd-logind[264]: New session c36 of user <username>.
   Jan 19 02:24:35 <hostname> systemd[1]: Started Session c36 of user <username>.
   Jan 19 02:24:35 <hostname> login[5422]: LOGIN ON tty1 BY <username>
   ***Jan 19 02:24:35 <hostname> systemd-coredump[5500]: Process 5499 (Xorg.bin) of user 1000 dumped core.***
   Jan 19 02:24:55 <hostname> login[5422]: pam_unix(login:session): session closed for user <username>
   Jan 19 02:24:55 <hostname> systemd[1]: getty@tty1.service has no holdoff time, scheduling restart.
   Jan 19 02:24:55 <hostname> systemd-logind[264]: Removed session c36.
   Jan 19 02:24:55 <hostname> systemd[1]: Stopping Getty on tty1...
   Jan 19 02:24:55 <hostname> systemd[1]: Starting Getty on tty1...
   Jan 19 02:24:55 <hostname> systemd[1]: Started Getty on tty1.

I added ulimit -c unlimited to startx right before the xinit line, hoping that I would get a core file in my home directory, but I didn't.

I'm not sure how to debug any further. Please let me know if any additional information would be helpful.

Edit:
I found the core file with coredumpctl. I don't have builds with symbols installed, so the backtrace is of limited use, but here it is in case it helps:

~> coredumpctl gdb
           PID: 6806 (Xorg.bin)
           UID: 1000 (<username>)
           GID: 1000 (<username>)
        Signal: 6 (ABRT)
     Timestamp: Mon 2015-01-19 03:00:22 EST (2h 32min ago)
  Command Line: /usr/bin/Xorg.bin -nolisten tcp :0 vt1 -auth /tmp/serverauth.O2DK2l0OYx vt1
    Executable: /usr/bin/Xorg.bin
 Control Group: /user.slice/user-1000.slice/session-c42.scope
          Unit: session-c42.scope
         Slice: user-1000.slice
       Session: c42
     Owner UID: 1000 (<username>)
       Boot ID: a4befec8fac64eecb209137ca5a7a7dc
    Machine ID: c47e0a2b0bee4e7eb9967f998efdfc94
      Hostname: <hostname>
      Coredump: /var/lib/systemd/coredump/core.Xorg\x2ebin.1000.a4befec8fac64eecb209137ca5a7a7dc.6806.1421654422000000.lz4
       Message: Process 6806 (Xorg.bin) of user 1000 dumped core.

GNU gdb (GDB) 7.8.2
<...snip copyright, etc...>

Reading symbols from /usr/bin/Xorg.bin...(no debugging symbols found)...done.
[New LWP 6806]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/bin/Xorg.bin -nolisten tcp :0 vt1 -auth /tmp/serverauth.O2DK2l0OYx vt1'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f99f622fa97 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007f99f622fa97 in raise () from /usr/lib/libc.so.6
#1  0x00007f99f6230e6a in abort () from /usr/lib/libc.so.6
#2  0x000000000059aace in OsAbort ()
#3  0x00000000005a1367 in FatalError ()
#4  0x000000000049dbd1 in ?? ()
#5  0x000000000049e4f3 in xf86CloseConsole ()
#6  0x00000000004786a5 in ddxGiveUp ()
#7  0x00000000005a0532 in ?? ()
#8  0x00000000005a139d in FatalError ()
#9  0x000000000049dbd1 in ?? ()
#10 0x000000000049de69 in xf86OpenConsole ()
#11 0x000000000047a47f in InitOutput ()
#12 0x000000000043b7ba in ?? ()
#13 0x00007f99f621c040 in __libc_start_main () from /usr/lib/libc.so.6
#14 0x0000000000425dce in _start ()

[zanchey]

It might be worth using something like exec strace -f startx -o ~/startx.strace.log instead of plain exec startx and then posting the log that it produces (startx.strace.log), although that will produce a LOT of output.

[0X1A]

Any update on what exactly is causing this? I'm still having this exact issue with 2.1.1

[ridiculousfish]

Possibly related to #367?

[zanchey]

Using strace may not work after all due to X being setuid :-(

[ghost]

I have the same issue on my machine (oh-my-fish and arch linux).

[mrak]

I seem to have found the issue. Newer versions of xorg in Arch Linux run with user privileges and redirection will break the session. The key for me was using the -keeptty flag with startx:

# Start X at login
if status --is-login
  if test -z "$DISPLAY" -a $XDG_VTNR = 1
    exec startx -- -keeptty >~/.xorg.log ^&1
  end
end

You can use whichever file you want for the log; it doesn't have to be ~/.xorg.log. This leads me to think that fish somehow deals with output and tty handoff differently than other shells when exec is used?

[ridiculousfish]

Nice work @mrak. I don't know of any differences offhand but there may be one. What causes the symptom - is it the redirection to xorg.log?

[mrak]

@ridiculousfish I just verified that only -keeptty is needed.

# Start X at login
if status --is-login
  if test -z "$DISPLAY" -a $XDG_VTNR = 1
    exec startx -- -keeptty
  end
end

[mrak]

The forum thread I found that described this fix is in Arch Linux Forums / xorg-server 1.16 issues.

The main gist is that X seems to lose track of which tty it's on while using fish in this way unless -keeptty is used.

[sploutchy]

Thanks @mrak :)

[faho]

I can reproduce this, now the question is if this needs a change in fish, one in X or a workaround in documentation.

[badele]

Thank @mrak Effectivelly, it works !

[floam]

@faho Does this still occur? Did @krader1961's tty PR affect this one way or the other?

[faho]

@floam: I can't reproduce this anymore with vanilla 2.3.0.

I'm closing this as fixed there. If anyone still has this problem, please yell at me!

[yash-bansod]

For those who are using fish in interactive mode please use:

# Start X at login
if status --is-interactive
  if test -z "$DISPLAY" -a $XDG_VTNR = 1
    exec startx -- -keeptty
  end
end