On Sat, Mar 23, 2024 at 12:22:15PM -0400, Haines Brown via Dng wrote:
> On Fri, Mar 22, 2024 at 09:37:29AM +1100, Ralph Ronnquist via Dng wrote:
>

> > Firstly re ~/.xinitrc:
> > 2) you could insert a line at the top, below the 5th '#' line:
> >         pgrep -a Xorg >&2
> >    and also, just above that "exec startfluxbox line", insert the two lines:
> >         sleep 2
> >     pgrep -a Xorg >&2

>
> That I did with ~/.xinitrc. However I now discover
> /etc/X11/xinit/xinitrc. That is exactly like my ~/.xinitrc except now
> I've modifed the latter. The sole operative lines in file were:
>

>   if [ -d /etc/X11/xinit/xinitrc.d ]; then
>     for f in /etc/X11/xinit/xinitrc.d/*; do
>       [ -x "$f" ] && . "$f"
>     done
>     unset f
>   fi

>
> exec startfluxbox

Yes, afaiui "/etc/X11/xinit/xinitrc" is the "driving script" for
xinit, and it should normally only have a single line except for
comments, to source "/etc/X1/session". I'm not sure what it means if
yours is different; maybe you have an earlier xinit version; but it
should be fine whatever it is, because as pre lines below ...

>
>

> > Those lines (assuming you have pgrep installed) will/should print the
> > running Xorg command line, and normally look something like:
> >     1815 /usr/lib/xorg/Xorg :0 vt7 -nolisten tcp -auth ...

> >
> > That output will/should appear in the terminal where you run startx.
> >
> > In your case there might be a) no output, b) one line of output or c)
> > 2 lines of output.
>
> Actually there were many lines of output.
>
> (DB) [libseat/backend/logind.c: 184] Coult not stat fs 22079
> xf86EnalbkeIO: failed to enable port 0000-03ff (operation not
> permitted)

The above line is actually two wanrning messages from Xorg. (I assume
the token xf86EnableIO: got garbled by your copy paste in some way,
and technically the second warning is also a single line that has been
word wrapped on the way the here)

I'm not immediately sure whether or not those lines point at the
problem cause because the next line (shown as two due to wrapping) is
the first "pgrep" result.

> 18300 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth
> /tmp/serverauth.c XuJbWBof

It indicates that Xorg is started on vt1 but there's something fishy
with the "-auth" parameter "/tmp/serverauth.c XuJbWBof" which has a
space in it. It's possible that space causes grief but probably not.

> xinit: connection to X server lost

The lack of second "pgrep" report indicates that either the script
code between the "pgrep" commands makes truoble, or that Xorg takes a
little while from the very first log lines before it terminates
prematurely. Since you don't "have anything" between the "pgrep"
commands it's more likely it's Xorg taking a while.

>
> > If (a), it means that Xorg has exited even before the script is run,
> > and then your issue is firmly isolated to the Xorg startup. Perhaps
> > something with the graphics (as tempforever noted), perhaps something
> > with that barcode reader you seem to have connected, and perhaps
> > something else. It may also be Xorg itself dropping dead before the
> > script is run. (If (a) is the result then you will need to go one step
> > deeper into the Xorg startup scripting to extract the start command)
>
> Since there was a return I presume the script runs
>
> > If (b), it suggests there is something with some script snippet in
> > /etc/X11/xinit/xinitrc.d causing Xorg to drop dead.
>
> I don't know what the {DB) symbol refers to. No idea what fs 22079
> refers to. Dos this indicate that authoritzation was successful?
> Indeed there is a /tmp/serverauth.Xdt2KNkHmp. It holds a
> MAGIC-COOKIE, so I suppose the process got this far. At what point in
> the process is authorization sought?
>
> > If (c), it suggests firmly that there is something with the fluxbox
> > startup. Either that something causes Xorg to exit first or that
> > fluxbox terminates (which also results in Xorg terminating [but
> > usually not silently]).
>
> I removed and reinstalled fluxbox with no luck. Maybe I should do that
> with xorg.
>
> > The reason for viewing the Xorg command line is so you can try that
> > directly as command and then its stderr output, if any, will come
> > directly into that shell rather than being captured by startx and
> > whatnot.
>
> Does not seem to be what happened. I got a return much more.
>
> I look at ~/.local/share/xorg/Xorg.log and see tne line
>

>     (II) seatd_libseat opened graphics: /dev/dri/card0 (13:13)

>
> does this indicate the display was accessed?

Yes. Xorg opens /dev/dri/card0 early in it startup. Or more precisely,
it requests the seat handling to open that device and return the
reulting file descriptor (13 in this case). The opening is mediated by
the elogind daemon (that is running as root) through a series of dbus
interactions, unless you are using seatd which then performs that
mediation via a socket handshake.

That same mediation happens for all input devices.

> The end of the file reads
>

>     [488803.808] (II) modeset(0): using drv /dev/dri/card0
>     [488803.808] (WW) Falling back to old probe method for fbdev
>     [488803.808] (II) Loading sub module "fbdevhw"
>     [488803.808] (II) LoadModule: "fbdevhw"

>
> So the frame butter is loaded. Is this to be expected? Thing stop at
> this point. $ lsmod does not see fbdev*

Yes, that's all fine. My understanding of the graphics particulars is
rather hazy but it's a normal log.

However, the VT juggling requires Xorg to have access to /dev/tty1 and
my first guess would be that the user doesn't have that access.
However, if the user logged in to VT1 then the user should be the
owner of /dev/tty1, so that's probably not it.

Now, by with having the Xorg command line:

/usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/whatever

you can run that in the shell and thus see all stderr output from
Xorg. Doing so will also tell whether or not it's Xorg terminating by
itself while possibly giving more and better lead to why that happens.

Ralph.

>
> --
>

>      Haines Brown 
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng