Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #202823 > unrolled thread

issues with stretch, issue 2 from many

Back to article view | Back to linux.debian.user

Contents

  issues with stretch, issue 2 from many Ionel Mugurel Ciobîcă <I.M.Ciobica@gmail.com> - 2018-11-27 14:10 +0100
    Re: issues with stretch, issue 2 from many David Wright <deblis@lionunicorn.co.uk> - 2018-11-27 17:40 +0100
      Re: issues with stretch, issue 2 from many Greg Wooledge <wooledg@eeg.ccf.org> - 2018-11-27 18:10 +0100
        Re: issues with stretch, issue 2 from many Brian <ad44@cityscape.co.uk> - 2018-11-28 21:40 +0100
          Re: issues with stretch, issue 2 from many Greg Wooledge <wooledg@eeg.ccf.org> - 2018-11-29 21:20 +0100
            Re: issues with stretch, issue 2 from many Brian <ad44@cityscape.co.uk> - 2018-11-29 21:50 +0100
          Re: issues with stretch, issue 2 from many Brian <ad44@cityscape.co.uk> - 2018-11-29 21:20 +0100
    Re: issues with stretch, issue 2 from many Brian <ad44@cityscape.co.uk> - 2018-11-27 20:00 +0100
    Re: issues with stretch, issue 2 from many Greg Wooledge <wooledg@eeg.ccf.org> - 2018-11-30 16:30 +0100
      Re: issues with stretch, issue 2 from many Ionel Mugurel Ciobîcă <I.M.Ciobica@gmail.com> - 2018-11-30 16:50 +0100
        Re: issues with stretch, issue 2 from many Greg Wooledge <wooledg@eeg.ccf.org> - 2018-11-30 17:00 +0100
          Re: issues with stretch, issue 2 from many Mark Fletcher <mark27q1@gmail.com> - 2018-11-30 17:30 +0100
          Re: issues with stretch, issue 2 from many Brian <ad44@cityscape.co.uk> - 2018-11-30 17:40 +0100
    Re: issues with stretch, issue 2 from many Ionel Mugurel Ciobîcă <I.M.Ciobica@gmail.com> - 2018-11-30 16:30 +0100
      Re: issues with stretch, issue 2 from many Brian <ad44@cityscape.co.uk> - 2018-11-30 17:50 +0100
        Re: issues with stretch, issue 2 from many Richard Hector <richard@walnut.gen.nz> - 2018-12-02 21:00 +0100
          Re: issues with stretch, issue 2 from many David Wright <deblis@lionunicorn.co.uk> - 2018-12-06 16:50 +0100
      Re: issues with stretch, issue 2 from many David Wright <deblis@lionunicorn.co.uk> - 2018-12-01 20:50 +0100
    Re: issues with stretch, issue 2 from many Ionel Mugurel Ciobîcă <I.M.Ciobica@gmail.com> - 2018-12-11 14:30 +0100

#202823 — issues with stretch, issue 2 from many

Dear all,

I have issues with stretch, to many to count...
This one will focus on the window manager startup.

I did a fresh install of Debian stretch using net install disk.
I use Debian (and Linux) from 1997. In all this time I used fvwm2 as
windows manager. I also used Unix in 1995-1996 with fvwm2.

So after the installation, I edit the file $HOME/.xsession
and I added as last line fvwm2. I also made the x-window-manager point
to fvwm2. When I login the .xsession is not read, like it was done
before for older releases, but fvwm is started. After many
permutations I found out that if I rename the .xsession into
.xsessionrc then the file is read, but then the fvwm is started twice,
one after each other. In other words after I exit fvwm it will enter
again in fvwm, but the second time without the ssh-agent and other
things.

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.

I tried both kdm and xdm as display managers. It will make no
difference. I use fvwm 2.6.7. I have Linux 4.9.0-8-amd64.

I would appreciate any hint.

Thank you.

Kind regards,
 Ionel

[toc] | [next] | [standalone]

#202831

On Tue 27 Nov 2018 at 13:52:25 (+0100), Ionel Mugurel Ciobîcă wrote:
> I have issues with stretch, to many to count...
> This one will focus on the window manager startup.
> 
> I did a fresh install of Debian stretch using net install disk.
> I use Debian (and Linux) from 1997. In all this time I used fvwm2 as
> windows manager. I also used Unix in 1995-1996 with fvwm2.

Sure. I used fvwm2 explicitly with hamm and slink, maybe even with bo.
But the fact that you still write "2" might indicate that there's
cruft in the system which is doing something unexpected.

> So after the installation, I edit the file $HOME/.xsession
> and I added as last line fvwm2.

I happen not to do it that way; I exec it early in the file so that
it's running while everything else in .xsession comes up. The last
line in .xsession is a wait on the WM's PID.

> I also made the x-window-manager point
> to fvwm2.

I don't understand. Doesn't x-window-manager already point to fvwm2
in /etc/alternatives ?

> When I login the .xsession is not read, like it was done
> before for older releases, but fvwm is started.

Interesting. On my system, ps -ef reveals:

UID     PID  PPID       TIME CMD
david  1495  1297   00:00:00 /bin/sh /usr/bin/X11/startx
david  1517  1495   00:00:00 xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth /tmp/serverauth.lLPH4nRsUP
david  1518  1517   00:00:33 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/serverauth.lLPH4nRsUP
david  1524  1517   00:00:00 /bin/bash /home/david/.xsession
david  1577  1524   00:00:01 /usr/bin/fvwm

so what started yours?

> After many
> permutations I found out that if I rename the .xsession into
> .xsessionrc then the file is read, but then the fvwm is started twice,
> one after each other. In other words after I exit fvwm it will enter
> again in fvwm, but the second time without the ssh-agent and other
> things.

Well, it would if you start both fvwm2 and x-window-manager.

> Question 2.1: Why .xsession is not read and .xsessionrc is read?

Don't know. But you haven't posted how you start X.

> 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.

What sort of error message? I get messages like:

xinit: connection to X server lost
waiting for X server to shut down Server terminated successfully (0). Closing log file.
xinit: unexpected signal 15

but they're expected by me as I either typed Ctrl-Alt-Backspace or shutdown.

> I tried both kdm and xdm as display managers. It will make no
> difference. I use fvwm 2.6.7. I have Linux 4.9.0-8-amd64.

I use startx myself. But AIUI Debian has put a lot of effort into
making it possible for X server sessions to end up in the same
configuration whether they were started from a VC or a DM. Your using
.xsessionrc sounds as if you might be working around some other
"misconfiguration" that's happened to work until now. It might even
have been like that since the "Great X Reorganisation" back in the
days of slink.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#202832

On Tue, Nov 27, 2018 at 10:32:24AM -0600, David Wright wrote:
> > Question 2.1: Why .xsession is not read and .xsessionrc is read?
> 
> Don't know. But you haven't posted how you start X.

He said he used "xdm and kdm", if I recall correctly.  Sounds like he
is switching things around randomly and frequently, instead of focusing
on one setup and describing it in detail.

> I use startx myself.

Same.

> But AIUI Debian has put a lot of effort into
> making it possible for X server sessions to end up in the same
> configuration whether they were started from a VC or a DM. Your using
> .xsessionrc sounds as if you might be working around some other
> "misconfiguration" that's happened to work until now. It might even
> have been like that since the "Great X Reorganisation" back in the
> days of slink.

My understanding is .xsessionrc was created in order to give users a
modicum of control over their own lives if they happen to use GNOME.
Since normally a gdm3/GNOME session will ignore everything in the
user's .xsession file, Debian created this other file that can be used
with GNOME.  Or with sddm/KDE, or lightdm, or xdm, or whatever other
bizarre display managers may appear in the future and screw everything
up even more.

I documented everything I could figure out about .xsessionrc and friends
at <https://wiki.debian.org/Xsession>.  There are definitely holes in my
knowledge when it comes to Desktop Environments (GNOME, KDE, and their
ilk), because I do not use them.  The more I learn about them, the less
I want to be anywhere near one.  Ever.

If the OP, or anyone else, wants help understanding how their X startup
works, we need a few concrete pieces of information before we can even
begin:

1) What version of Debian are you using?

2) How do you log in to your computer?  If it's a display manager
   (graphical login), which one is it?  If you need help figuring this
   out, see below.

3) How do you start X?  (Do you explicitly type a command, or is it started
   automatically by your graphical login?)


Figuring out which display manager you are using:

This is freakin' hard.  Way harder than it needs to be, in my opinion,
but I don't have any specific suggestions for how to remedy this, short
of the display managers individually choosing to identify themselves
in some way on the screen.

There are two ways I can think of to approach the situation.  The first
is to ask the Debian package manager which display manager(s) are
installed.  This basically means you need to know the names of ALL of
the common display manager packages, so you can ask for them all.

As a shortcut, however, we can take advantage of the fact that most of
them end with the letters "dm", or with the letters "dm" followed by
a single digit.  Thus:

# dpkg -l \*dm \*dm\[0-9]
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
un  gdm3           <none>       <none>       (no description available)
ii  kde-config-sdd 4:5.8.4-1    amd64        KCM module for SDDM
un  mdadm          <none>       <none>       (no description available)
ii  sddm           0.14.0-4+deb amd64        modern display manager for X11

On this system, it looks like sddm is installed.  So that's probably
the display manager that's in use.

The second approach is to log out of your X session so that the display
manager is actually running.  Then login on the text console (by pressing
Ctrl-Alt-F2), or by ssh-ing into the computer, and ask the system which
display manager processes are running.  Again, this requires that you
have some knowledge of the *names* of these processes, so you know what
to look/ask for.

# ps -ef | grep gdm
root     32374 32342  0 12:01 pts/0    00:00:00 grep gdm

Nope.

# ps -ef | grep lightdm
root     32376 32342  0 12:01 pts/0    00:00:00 grep lightdm

Nope.

# ps -ef | grep sddm
root       603     1  0 Nov02 ?        00:00:00 /usr/bin/sddm
root       683   603  0 Nov02 tty7     00:38:45 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/{2b3b5bd9-8457-4fd5-b80d-b4c78b6bbc85} -background none -noreset -displayfd 18 vt7
root      1155   603  0 Nov02 ?        00:00:00 /usr/lib/x86_64-linux-gnu/sddm/sddm-helper --socket /tmp/sddm-authe24f9403-2eb8-4029-a8c8-83969060da79 --id 2 --start /usr/bin/sddm-greeter --socket /tmp/sddm-:0-nWnvBg --theme /usr/share/sddm/themes/debian-theme --user sddm --greeter
sddm      1157     1  0 Nov02 ?        00:00:00 /lib/systemd/systemd --user
sddm      1158  1157  0 Nov02 ?        00:00:00 (sd-pam)
sddm      1160  1155  0 Nov02 ?        01:40:22 /usr/bin/sddm-greeter --socket /tmp/sddm-:0-nWnvBg --theme /usr/share/sddm/themes/debian-theme
sddm      1168     1  0 Nov02 ?        00:00:00 dbus-launch --autolaunch 5942ce2e232449d09bfb1b98b5b26d87 --binary-syntax --close-stderr
sddm      1169     1  0 Nov02 ?        00:00:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
root     32378 32342  0 12:01 pts/0    00:00:00 grep sddm

Bingo!  Looks like sddm is in use.

Of course, a third method would be to know what each display manager
actually *looks* like on the screen, so that you can identify it visually.
If you can do that, great.  I don't expect it to be a realistic choice
for most people.

[toc] | [prev] | [next] | [standalone]

#202876

On Tue 27 Nov 2018 at 12:04:37 -0500, Greg Wooledge wrote:

[...]

> My understanding is .xsessionrc was created in order to give users a
> modicum of control over their own lives if they happen to use GNOME.

It doesn't say that in #411639.

[...]

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#202900

On Thu, Nov 29, 2018 at 08:10:43PM +0000, Brian wrote:
> How does ~/.xsessionrc assume such importance over ~/.xsession in the
> grand scheme of X things?

Because it's the only file that's guaranteed to be read no matter what
kind of crazy nonstandard X session the user invokes (GNOME, I'm looking
at you).

Therefore, when writing a wiki page for the least knowledgeable end user,
it is the advice that I put *first*, with the description that this is
the *simplest* way of doing things.

Then I put the traditional "or .xsession but it only works if you ___" at
the end.  And I indicate that this is a more advanced way of doing things.
Therefore, users who self-identify as "advanced" will try that.  Whether
they are *actually* advanced is a different story, but they have been
given both choices, and appropriate descriptions and warnings.

[toc] | [prev] | [next] | [standalone]

#202902

On Thu 29 Nov 2018 at 15:17:03 -0500, Greg Wooledge wrote:

> On Thu, Nov 29, 2018 at 08:10:43PM +0000, Brian wrote:
> > How does ~/.xsessionrc assume such importance over ~/.xsession in the
> > grand scheme of X things?
> 
> Because it's the only file that's guaranteed to be read no matter what
> kind of crazy nonstandard X session the user invokes (GNOME, I'm looking
> at you).
> 
> Therefore, when writing a wiki page for the least knowledgeable end user,
> it is the advice that I put *first*, with the description that this is
> the *simplest* way of doing things.
> 
> Then I put the traditional "or .xsession but it only works if you ___" at
> the end.  And I indicate that this is a more advanced way of doing things.
> Therefore, users who self-identify as "advanced" will try that.  Whether
> they are *actually* advanced is a different story, but they have been
> given both choices, and appropriate descriptions and warnings.

So the page is about ~/xsessionrc and GNOME and gdm3. The title doesn't
reflect that. Nor does the (non-existent) page description.

  > kind of crazy nonstandard X session the user invokes (GNOME, I'm
  > looking at you).

indictes an agenda ("...crazy nonstandard...") which might be worthy of
addressing, but the page does little to indicate how a user would handle
a standard Debian Xsession and startx with ~/.xsession.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#202901

On Wed 28 Nov 2018 at 20:18:25 +0000, Brian wrote:

> On Tue 27 Nov 2018 at 12:04:37 -0500, Greg Wooledge wrote:
> 
> [...]
> 
> > My understanding is .xsessionrc was created in order to give users a
> > modicum of control over their own lives if they happen to use GNOME.
> 
> It doesn't say that in #411639.
> 
> [...]

However:

https://wiki.debian.org/Xsession says (referring to ~/xsessionrc)

 There are typically three kinds of commands you may wish to use in this file:

   * You may place environment variable definitions here, directly: export SOME_VAR="some value"

This was the reason for ~/.xsessionrc coming into existence.

   * You may dot in some other POSIX shell configuration file: if [ -r ~/.profile ]; then . ~/.profile; fi

A user can, but ~/xsessionrc wasn't invented for that. ~/.xsession was.

   * You may directly run X client programs: xclock -geometry +0+0 &

A user can, but ~/.xsessionrc definitely wasn't devised for that. OTOH,
~/.xsession was.

How does ~/.xsessionrc assume such importance over ~/.xsession in the
grand scheme of X things?

-- 
Brian

[toc] | [prev] | [next] | [standalone]

#202835

On Tue 27 Nov 2018 at 13:52:25 +0100, Ionel Mugurel Ciobîcă wrote:

> Dear all,
> 
> I have issues with stretch, to many to count...
> This one will focus on the window manager startup.
> 
> I did a fresh install of Debian stretch using net install disk.
> I use Debian (and Linux) from 1997. In all this time I used fvwm2 as
> windows manager. I also used Unix in 1995-1996 with fvwm2.
> 
> So after the installation, I edit the file $HOME/.xsession
> and I added as last line fvwm2.

You could show us your .xsession.

>                                 I also made the x-window-manager point
> to fvwm2. 

That should have been done for you. startx should (without .xsession}
bring up fvwm.

>           When I login the .xsession is not read, like it was done
> before for older releases, but fvwm is started. After many

How do you know it is not read? (That's a different question from asking
why it was not acted on).

> permutations I found out that if I rename the .xsession into
> .xsessionrc then the file is read, but then the fvwm is started twice,
> one after each other. In other words after I exit fvwm it will enter
> again in fvwm, but the second time without the ssh-agent and other
> things.

Xsession(5) describes what .xsessionrc is used for. Does your use fit
the intended use? Or are you abusing the file's intended purpose?

> 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.
> 
> I tried both kdm and xdm as display managers. It will make no
> difference. I use fvwm 2.6.7. I have Linux 4.9.0-8-amd64.
> 
> I would appreciate any hint.

Make it simple to begin with. Type startx (no .xsession) and go from
there when you have that working.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#202909

On Fri, Nov 30, 2018 at 04:20:15PM +0100, Ionel Mugurel Ciobîcă wrote:
> @ Brian, here is my formal .xsession (currently .xsessionrc) file:

I assume you meant "former".

> ==========================cut here========================
> #!/bin/bash
> xsetbg background1.png
> rclock -fg white -bg black -fn
> "-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-16" -geometry
> 98x95+1817+23 &
> eval `ssh-agent -s`
> xrdb -m .Xresources
> xrdb -m .Xdefaults
> xmodmap .xmodmap
> ssh-add -c
> setroot -solid steelblue1
> xsetbg background2.png
> ( sleep 2 ; /home/mugurel/bin/*ncepe ) &
> fvwm2
> ==========================cut here========================

An .xsessionrc file should NOT invoke the window manager or session
manager.  .xsessionrc is read *in addition* to (before) the code that
runs your chosen, or the default, session or window manager.

An .xsession file SHOULD invoke a window manager or session manager,
because it completely replaces the system-wide stuff.  But only if
you use a "Debian X session".  Not if you use a GNOME session, or anything
else.  In those cases, your .xsession file may be completely ignored.

[toc] | [prev] | [next] | [standalone]

#202911

On 30-11-2018, at 10h 25'17", Greg Wooledge wrote about "Re: issues with stretch, issue 2 from many"
> On Fri, Nov 30, 2018 at 04:20:15PM +0100, Ionel Mugurel Ciobîcă wrote:
> > @ Brian, here is my formal .xsession (currently .xsessionrc) file:
> 
> I assume you meant "former".

Yes, Greg. Sorry for my English. I never learn it at school, I just
pick it with time...

> 
> > ==========================cut here========================
> > #!/bin/bash
> > xsetbg background1.png
> > rclock -fg white -bg black -fn "-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-16" -geometry 98x95+1817+23 &
> > eval `ssh-agent -s`
> > xrdb -m .Xresources
> > xrdb -m .Xdefaults
> > xmodmap .xmodmap
> > ssh-add -c
> > setroot -solid steelblue1
> > xsetbg background2.png
> > ( sleep 2 ; /home/mugurel/bin/*ncepe ) &
> > fvwm2
> > ==========================cut here========================
> 
> An .xsessionrc file should NOT invoke the window manager or session
> manager.  .xsessionrc is read *in addition* to (before) the code that
> runs your chosen, or the default, session or window manager.
> 
> An .xsession file SHOULD invoke a window manager or session manager,
> because it completely replaces the system-wide stuff.  But only if
> you use a "Debian X session".  Not if you use a GNOME session, or anything
> else.  In those cases, your .xsession file may be completely ignored.

Greg, I care less about what should and what should not. .xsession is
ignored in stretch (but not before), so I found out that .xsessionrc
is not, so I renamed. Regardless of my .xsession/.xsessionrc file
something is calling for a x-window-session without the
personalisation that I want.

If you know a way to still have my personalisation with the system
call of the x-window-manager I am only ears. 

If I comment out fvwm2 call in .xessionrc file, I get a fvwm2 session
without the ssh-agent. So all the ssh calls from the fvwm menu will
ask for password. Not even for the passphrase.

So, do you know what is the Debian standard way to use
xdm/fvwm2/ssh-agent combo in stretch? Before stretch all is working
well with .xsession file...
Anyone?


Thank you,
 Ionel

[toc] | [prev] | [next] | [standalone]

#202912

On Fri, Nov 30, 2018 at 04:43:04PM +0100, Ionel Mugurel Ciobîcă wrote:
> Greg, I care less about what should and what should not. .xsession is
> ignored in stretch (but not before),

Not if you type startx.  I login on the Linux text console in stretch,
and type startx, and my .xsession is used.  Just like it always has been.
Just like it is for everyone else who uses startx.

> so I found out that .xsessionrc
> is not, so I renamed.

You must comment out the explicit "fvwm2" at the end of the file after
you do that.  Otherwise, you will try to run a window manager TWICE.
Once in .xsessionrc and then once in the Debian X session, or the GNOME
session, or whatever it is that you are using.

> Regardless of my .xsession/.xsessionrc file
> something is calling for a x-window-session without the
> personalisation that I want.

Yes.  As I have REPEATEDLY told you.  As it says in the documentation,
and on the wiki page, and everywhere.

Debian will try to run a session manager or a window manager AFTER it
finishes reading your .xsessionrc file.


Now, please answer the following questions:

1) What version of Debian are you running?

2) How do you log in to your computer?  If it's by a display manager
   (graphical login), which one is it?

3) How do you start the X window system?

4) How have you configured whichever dot files are relevant to #2 and #3?

5) What is the actual problem you are having?


#2 IS CRITICALLY IMPORTANT and I have never yet seen you answer it.
Maybe I missed it somewhere in this incredibly drawn-out and unfocused
thread, but I don't think so.

[toc] | [prev] | [next] | [standalone]

#202913

[Multipart message — attachments visible in raw view] — view raw

On Sat, Dec 1, 2018 at 0:59 Greg Wooledge <wooledg@eeg.ccf.org> wrote:

>
> Now, please answer the following questions:
>
> 1) What version of Debian are you running?
>
> 2) How do you log in to your computer?  If it's by a display manager
>    (graphical login), which one is it?
>
> 3) How do you start the X window system?
>
> 4) How have you configured whichever dot files are relevant to #2 and #3?
>
> 5) What is the actual problem you are having?
>
>
> #2 IS CRITICALLY IMPORTANT and I have never yet seen you answer it.
> Maybe I missed it somewhere in this incredibly drawn-out and unfocused
> thread, but I don't think so.
>
> He said he uses xdm.

[toc] | [prev] | [next] | [standalone]

#202914

On Fri 30 Nov 2018 at 10:58:52 -0500, Greg Wooledge wrote:

[...]

> Now, please answer the following questions:
> 
> 1) What version of Debian are you running?
> 
> 2) How do you log in to your computer?  If it's by a display manager
>    (graphical login), which one is it?
> 
> 3) How do you start the X window system?
> 
> 4) How have you configured whichever dot files are relevant to #2 and #3?
> 
> 5) What is the actual problem you are having?
> 
> 
> #2 IS CRITICALLY IMPORTANT and I have never yet seen you answer it.

It is in Ionel Mugurel Ciobîcă's first post of today that you replied
to.

> Maybe I missed it somewhere in this incredibly drawn-out and unfocused
> thread, but I don't think so.

It happens. :)

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#202910

On 27-11-2018, at 13h 52'25", Ionel Mugurel Ciobîcă wrote about "issues with stretch, issue 2 from many"
> Dear all,
> 
> 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.
> 

@ Brian, here is my formal .xsession (currently .xsessionrc) file:

==========================cut here========================
#!/bin/bash
xsetbg background1.png
rclock -fg white -bg black -fn
"-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-16" -geometry
98x95+1817+23 &
eval `ssh-agent -s`
xrdb -m .Xresources
xrdb -m .Xdefaults
xmodmap .xmodmap
ssh-add -c
setroot -solid steelblue1
xsetbg background2.png
( sleep 2 ; /home/mugurel/bin/*ncepe ) &
fvwm2
==========================cut here========================

startx would have been bringing up whatever x-window-manager was
pointing at, which was kde.

xsession was not read because I did not get the clock, I was not asked
for the passphrase, I did not get the background, etc.

I am not abusing anything. .xsession was working before stretch and it
is not working with stretch. Reading some manuals I found out about
.xsessionrc, so I renamed .xsession into .xsessionrc.

I am not fun of startx, it will read my .xsession?


@ 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.

If your call to fvwm2 is first in .xsession, how do you get the rest
to be executed?

Initial x-window-manager was pointing to kde.

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.


@ Greg: I do not switching things around randomly and frequently. I
use xdm. I tried kdm when I encounter the issues with .xsession not
being read.

As I already posted:
 1. I use latest Debian stable. Fresh install.
 2. I use xdm to login.
 3. X starts automatically

About 2, is not that hard. I usually uninstall all alternative dm's and
then install xdm, before I login the first time as user.

I do not use gnome. I uninstall all packages related to gnome.


Any (new) ideas what I can do?

Thank you.
  Ionel

[toc] | [prev] | [next] | [standalone]

#202915

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"
> > Dear all,
> > 
> > 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.
> > 
> 
> @ Brian, here is my formal .xsession (currently .xsessionrc) file:
> 
> ==========================cut here========================
> #!/bin/bash
> xsetbg background1.png
> rclock -fg white -bg black -fn
> "-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-16" -geometry
> 98x95+1817+23 &
> eval `ssh-agent -s`
> xrdb -m .Xresources
> xrdb -m .Xdefaults
> xmodmap .xmodmap
> ssh-add -c
> setroot -solid steelblue1
> xsetbg background2.png
> ( sleep 2 ; /home/mugurel/bin/*ncepe ) &
> fvwm2
> ==========================cut here========================

My .xsession has "exec fvwm" as the last line but I do not think that
makes your choice incorrect. Also, your other lines look reasonable but
I've not had any experience with using such a varied assortment of
commands.

What I would do is start with "fvwm" as the only line and test with
startx. Then build up the file line by line, testing at each stage.

> startx would have been bringing up whatever x-window-manager was
> pointing at, which was kde.
> 
> xsession was not read because I did not get the clock, I was not asked
> for the passphrase, I did not get the background, etc.
> 
> I am not abusing anything. .xsession was working before stretch and it
> is not working with stretch. Reading some manuals I found out about
> .xsessionrc, so I renamed .xsession into .xsessionrc.
> 
> I am not fun of startx, it will read my .xsession?

Definitely. And - if works with startx, it should work with xdm.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#202968

[Multipart message — attachments visible in raw view] — view raw

On 1/12/18 5:49 AM, Brian wrote:
...
>> fvwm2
>> ==========================cut here========================
> My .xsession has "exec fvwm" as the last line but I do not think that
> makes your choice incorrect.

The difference is presumably that the former calls fvwm2 and then
returns to the shell script when it's finished.

The latter replaces the shell script, so anything that would run after
it (like another window manager?) won't run.

Richard

[toc] | [prev] | [next] | [standalone]

#203069

On Mon 03 Dec 2018 at 08:52:06 (+1300), Richard Hector wrote:
> On 1/12/18 5:49 AM, Brian wrote:
> ...
> >> fvwm2
> >> ==========================cut here========================
> > My .xsession has "exec fvwm" as the last line but I do not think that
> > makes your choice incorrect.
> 
> The difference is presumably that the former calls fvwm2 and then
> returns to the shell script when it's finished.
> 
> The latter replaces the shell script, so anything that would run after
> it (like another window manager?) won't run.

While that's true, it doesn't make much difference with respect to the
problem because fvwm2 was the last line of the script anyway.

One difference it *does* make is that not exec-ing it means that
there's an extra shell sitting there throughout *this* invocation of
fvwm2.

But, while posting .xsession on its own might make sense if you're
starting X simply with startx, it only gives a fraction of the story
if you're using a DM. This is presumably why the OP gets two WM
instances (the DM starts one, .xsession starts the other), and I don't
have a clue which is the "right" one with the ssh stuff in it.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#202948

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.

[toc] | [prev] | [next] | [standalone]

#203267

On 27-11-2018, at 13h 52'25", Ionel Mugurel Ciobîcă wrote about "issues with stretch, issue 2 from many"
> Dear all,
[...]
> 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.
[...]

This issue is no longer relevant. I cannot re-reproduced it. Now the
.xsession is read as it should be. Also if I keep it as .xsessionrc
the second fvwm session will actually make use of the content of
.xsessionrc.

I did not do any updates lately, I am not sure what solved this...

So, I am back using the .xsession, no more issues with xdm/fvmw combo.
Thank you all for contributing with ideas.

Kind regards,
 Ionel

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web