Re: issues with stretch, issue 2 from many
On Fri 30 Nov 2018 at 16:20:15 (+0100), Ionel Mugurel Ciobîcă wrote:
> On 27-11-2018, at 13h 52'25", Ionel Mugurel Ciobîcă wrote about "issues with stretch, issue 2 from many"
> > I have issues with stretch, to many to count...
> > This one will focus on the window manager startup.
> > [...]
> > Question 2.1: Why .xsession is not read and .xsessionrc is read?
> > Question 2.2: Who starts the second call of fvwm? If I comment out the
> > fvwm call in .xsession(rc) then the fvwm doesn't use the ssh-agent
> > (for example). At the moment I simply deleted x-window-manager, so
> > when I logout from fvwm I get a error/warning instead of a new fvwm
> > session.
>
> @ David, before login in the first time as user, after installation, I
> check if the executable fvwm2 exists. See this:
>
> ~> ls -ltr /usr/bin/fvwm2 /usr/bin/fvwm /etc/alternatives/fvwm
> -rwxr-xr-x 1 root root 908056 ian 16 2017 /usr/bin/fvwm2
> lrwxrwxrwx 1 root root 22 oct 18 09:35 /usr/bin/fvwm -> /etc/alternatives/fvwm
> lrwxrwxrwx 1 root root 14 oct 18 09:35 /etc/alternatives/fvwm -> /usr/bin/fvwm2
>
> So, yes, the executable is fvwm2. It was always fvwm2.
I probably didn't make my point clearly.
Back in the 20th century, we had to make modifications to our X
startups to get fvwm2 to run instead of fvwm1, including running
the binary specifically as fvwm2 instead of just using the name
"fvwm".
In going through nine releases since then, I've "cleaned up" these
startup files so that they follow closely the Debian recommendations.
I only run X through startx, so this is relatively straightforward.
Anyone who's used a DM or DE through these nine upgrades could
likely have accumulated modifications and tweaks across a more
complex set of files. Hence my point about cruft.
> If your call to fvwm2 is first in .xsession, how do you get the rest
> to be executed?
The call looks like this:
if [ -x /usr/bin/fvwm ] ; then
mv -f "$HOME/.fvwm/fvwm-log" "$HOME/.fvwm/fvwm-log~"
exec /usr/bin/fvwm > "$HOME/.fvwm/fvwm-log" 2>&1 & Wmpid=$!
elif [ -x /usr/bin/foo ] ; then
mv -f "$HOME/.foo-log" "$HOME/.foo-log~"
exec /usr/bin/foo > "$HOME/.foo-log" 2>&1 & Wmpid=$!
else
printf '%s\n' "Error - no window manager found"
fi
where you could have a string of different WMs to try (twm,
for example, once upon an eon).
Now that the WM is running, all the applications can be mapped
to their correct locations using, for example,
xterm … -xrm "*Page: 3 3" ¹
Obviously this would be impossible without starting the WM first.
Finally, the following code keeps X running.
# wait for the window manager in the background to die
printf '%s\n' "Waiting for PID $Wmpid"
wait $Wmpid
(Printing the PID also aids another method of killing X apart from by
menu and by Ctrl-Alt-BackSpace.)
> Initial x-window-manager was pointing to kde.
I don't understand that statement. If x-window-manager stands for
/etc/alternatives/x-window-manager, it has to point to a WM binary,
doesn't it? I thought KDE was a DE.
> My fvwm2 is started by .xsession. The second instance is started by
> something that died, because the parent is now init. I do not start
> both fvwm2 and x-session-manager. Something (that I try to find out by
> asking the list, see question 2.2) is starting it. I want to stop that
> behaviour. Which is only happening on stretch.
>
> I use xdm.
Too convoluted for me to be much help.
¹ You would need an & here, but the tool being discussed at
https://lists.debian.org/debian-user/2018/10/msg01096.html
https://lists.debian.org/debian-user/2018/09/msg00884.html
(different months break the threading) handles that.
Cheers,
David.
Reply to: