[SOLVED] systemd incursion! ( fix X starting on same vt )

Keith Hedger · 04-05-2015, 06:43 AM

I have noticed that starting X using startx runs X on the same vt as where it started from, instead of the usual vt7, also specifying a particular virtual terminal with

Code:

startx :1 vt6

For instance is ignored which is a pain as you can't see any X errors in the vt until you quit X, did a little exploring and found that startx had been patched to accomadate what seems to be a firefox/systemd bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=806491

As I don't ( and hopefully never wil have that systemd rubbish - I wanted to use a stronger word than that - on my system ). found that you can just comment out the relevent bits like so from around line 104 of /usr/bin/startx change

Code:

    # When starting the defaultserver start X on the current tty to avoid
    # the startx session being seen as inactive:
    # "https://bugzilla.redhat.com/show_bug.cgi?id=806491"
    tty=$(tty)
    if expr match "$tty" '^/dev/tty[0-9]\+$' > /dev/null; then
        tty_num=$(echo "$tty" | grep -oE '[0-9]+$')
        vtarg="vt$tty_num"
    fi

To this:

Code:

    # When starting the defaultserver start X on the current tty to avoid
    # the startx session being seen as inactive:
    # "https://bugzilla.redhat.com/show_bug.cgi?id=806491"
#    tty=$(tty)
#    if expr match "$tty" '^/dev/tty[0-9]\+$' > /dev/null; then
#        tty_num=$(echo "$tty" | grep -oE '[0-9]+$')
#        vtarg="vt$tty_num"
#    fi

You can then start X with startx the 'proper' way or specify a specific vt as above.

For a lot of users this is going to go unnoticed but if you do any low level X stuff getting at the error's form X will now be restored.

You will of course have to edit /usr/bin/startx as root, you may also want to make a backup first like so:

Code:

cp /usr/bin/startx /usr/bin/startx.BAK

In case anything goes really wrong.

moonfrog · 04-05-2015, 09:21 PM

Thank You!

That was an easy and instant fix.
IMO X should never take vt1

Interesting that it was a tentacle from redhat's future OS

Maybe you should change the title to include the vt issue,
in this comunity I'm sure alot of people noticed their vt1 was gone.

ReaperX7 · 04-05-2015, 10:03 PM

I wonder if this was the cause of my tty crash with Xfce with running the reboot/shutdown sequences?

Rubbish, trash? Call it what it is Keith... A pile of shit.

moonfrog · 04-05-2015, 10:10 PM

Quote:

Originally Posted by ReaperX7

I wonder if this was the cause of my tty crash with Xfce with running the reboot/shutdown sequences?

It wasn't mine...I don't use Xfce but one machine I built on has Thunar +deps installed and hangs on reboot (but not shutdown) No change there

ReaperX7 · 04-05-2015, 10:46 PM

I did rollback xfce-session to another previous version and it now works, so I suspect xfce-session-logout has some unknown issue. I'm working with xfce-session-4.10.0 and the problems seems to have vanished.

moonfrog · 04-05-2015, 10:59 PM

Quote:

Originally Posted by ReaperX7

I did rollback xfce-session to another previous version and it now works, so I suspect xfce-session-logout has some unknown issue. I'm working with xfce-session-4.10.0 and the problems seems to have vanished.

I can't help verify that cos I didn't install xfce-session

Keith Hedger · 04-06-2015, 04:00 AM

Glad this was useful to other people, changed the title to mention vt.
I wonder how much more systemd creep there is in aparently unrelated software?

ReaperX7 · 04-06-2015, 08:38 AM

No way to tell honestly, but if xinit is showing incursions, chances are it's creeping in everywhere.

If I were you Keith, I'd forward this to the BLFS-Dev mailing list as a patch.

Keith Hedger · 04-07-2015, 07:39 AM

Sorry for the delay - visiting grandchildren.
I'm not signed up for the mailing lists but if anyone else is and wants to forward a patch be my guest.

bitshark · 04-27-2015, 06:18 AM

I can confirm a similar problem on Alpine Linux (non Systemd OpenRC based distro w/ XFCE). XFCE works great, but when I compiled MATE and GTK I was running into some sort of startx / xinit problem.

I think it may be related.

Keith Hedger · 04-27-2015, 06:35 AM

Did this fix fixit for you? if not rollback xfce to 4.10 I have and a number of problems seem to have gone.

bitshark · 04-27-2015, 12:54 PM

Hey Keith... I will check ASAP in the virtual machine. No information for the moment as to whether my problems are linked, and whether you're workaround solves the issue on Alpine Linux.

For anyone using Alpine there is actually a Mate package in testing repo so you don't have to necessarily do it yourself like I did. Again, Alpine is a secure (grsec patched ) kernel distro that uses Gentoo's OpenRC and eudev. Alpine also ditches glibc in favor of musl. The guys who created Alpine have no plans to migrate to systemd, and are actively building around it for the future.

Alpine is a bit like LFS crossed with slackware. It has it's own toolchain etc , OpenRC, supports xfce out of the box.

/dev/random · 04-30-2015, 11:41 AM

Look good? Now we detect if systemd is running if not resume with the default behavior.

Code:

--- startx.orig  2015-04-30 12:12:21.711606325 -0400
+++ startx      2015-04-30 12:59:45.497304617 -0400
@@ -101,6 +101,10 @@
     server=$defaultserver
 
 
+# Detect if we are using systemd or not
+usingsystemd="$(type systemd | sed -e 's/systemd is //g')"
+if [ -f $usingsystemd ]
+  then
     # When starting the defaultserver start X on the current tty to avoid
     # the startx session being seen as inactive:
     # "https://bugzilla.redhat.com/show_bug.cgi?id=806491"
@@ -109,7 +113,9 @@
         tty_num=$(echo "$tty" | grep -oE '[0-9]+$')
         vtarg="vt$tty_num"
     fi
-
+  else
+     echo "No systemd found"
+fi
 
     # For compatibility reasons, only use xserverrc if there were no server command line arguments
     if [ x"$serverargs" = x -a x"$display" = x ]; then

Keith Hedger · 04-30-2015, 02:09 PM

thanks for the patch didn't get around to making one, doing too much other stuff!