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

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

How to cause a process started in .xsessionrc to terminate with x-session termination?

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

Contents

  How to cause a process started in .xsessionrc to terminate with  x-session termination? Arkadiusz Dabrowski <ardabro@gmail.com> - 2021-11-17 22:40 +0100
    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-17 23:10 +0100
    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Brian <ad44@cityscape.co.uk> - 2021-11-18 00:50 +0100
    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-18 14:10 +0100
    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? songbird <songbird@anthive.com> - 2021-11-18 14:10 +0100
    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? David Wright <deblis@lionunicorn.co.uk> - 2021-11-18 21:40 +0100
      Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-18 21:50 +0100
        Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Jonathan Dowland <jon+debian-user@dow.land> - 2021-11-18 22:30 +0100
          Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-18 23:00 +0100
            Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Arkadiusz Dabrowski <ardabro@gmail.com> - 2021-11-18 23:10 +0100
        Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Brian <ad44@cityscape.co.uk> - 2021-11-19 19:40 +0100
          Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Arkadiusz Dabrowski <ardabro@gmail.com> - 2021-11-20 21:50 +0100
            Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-20 22:20 +0100
              Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Arkadiusz Dabrowski <ardabro@gmail.com> - 2021-11-21 19:20 +0100
                Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-21 20:20 +0100
                  Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Arkadiusz Dabrowski <ardabro@gmail.com> - 2021-11-21 20:50 +0100
                  Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? David Wright <deblis@lionunicorn.co.uk> - 2021-11-22 06:50 +0100
                    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-22 13:40 +0100
                      Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? David Wright <deblis@lionunicorn.co.uk> - 2021-11-22 21:50 +0100
              Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Musbur <musbur@posteo.org> - 2021-11-22 16:30 +0100
                Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-22 17:00 +0100
                  Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-22 17:50 +0100
                    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Jonathan Dowland <jon+debian-user@dow.land> - 2021-11-23 13:10 +0100
                      Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-23 14:00 +0100
                        Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? David Wright <deblis@lionunicorn.co.uk> - 2021-11-23 16:30 +0100
                          Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-12-10 14:40 +0100
                    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Andrei POPESCU <andreimpopescu@gmail.com> - 2021-12-10 15:10 +0100
                  Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? David Wright <deblis@lionunicorn.co.uk> - 2021-11-22 21:50 +0100
                    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Greg Wooledge <greg@wooledge.org> - 2021-11-22 22:20 +0100
                      Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? David Wright <deblis@lionunicorn.co.uk> - 2021-11-23 16:30 +0100
      Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Jonathan Dowland <jon+debian-user@dow.land> - 2021-11-18 22:30 +0100
    Re: How to cause a process started in .xsessionrc to terminate with  x-session termination? Mark Neyhart <Mark.Neyhart@akleg.gov> - 2021-11-18 22:20 +0100

Page 1 of 2  [1] 2  Next page →

#242225 — How to cause a process started in .xsessionrc to terminate with x-session termination?

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

Hi all
I have a problem with unison sync termination when it is started from
.xsessionrc.
It works flawlessly but when I log out it is orphaned and not terminated.
I start it like this:
nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &
Once started the parent is x-session-manager and they the same process
group.
What can I do to terminate the process with x-session?

[toc] | [next] | [standalone]

#242226

On Wed, Nov 17, 2021 at 10:39:21PM +0100, Arkadiusz Dabrowski wrote:
> I have a problem with unison sync termination when it is started from
> .xsessionrc.
> It works flawlessly but when I log out it is orphaned and not terminated.
> I start it like this:
> nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &

It sounds like you don't have a .xsession (or .xinitrc) file, and are
simply using the default Debian Xsession.

It also sounds like unison is not an X application.  Usually the programs
that you start from .xsessionrc are X client apps, which will terminate
when the X server goes away at logout.  Since unison is presumably not an
X client app, it survives this.

You could try using an .xsession file.  This gives you more control over
the session.  You could even read the default Debian Xsession from your
.xsession file, to keep things simple.  For example, something like this
may meet your needs (untested):

. /etc/X11/Xsession
pkill unison

It's not the most elegant solution, but you could start with this,
see whether it works at all, and then improve it from here if it does.

There may be other solutions.  For instance, maybe you can find something
in systemd or dbus that starts a managed service as a child of your login
session, and kills it upon logout.  I don't actually know whether systemd
or dbus can do this, but if it can, it might be a better solution.

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

#242227

On Wed 17 Nov 2021 at 22:39:21 +0100, Arkadiusz Dabrowski wrote:

> Hi all
> I have a problem with unison sync termination when it is started from
> .xsessionrc.

.xsessionrc is for stting environment variables for an X session. This
your intentio?

-- 
Brian.

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

#242228

On Wed, Nov 17, 2021 at 08:21:00PM -0500, songbird wrote:
> Arkadiusz Dabrowski wrote:
> ...
> > It works flawlessly but when I log out it is orphaned and not terminated.
> > I start it like this:
> > nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &
> > Once started the parent is x-session-manager and they the same process
> > group.
> > What can I do to terminate the process with x-session?
> 
>   does it work if you don't put it in the background?

That would prevent the rest of the X session from running, until the
unison process terminates.

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

#242229

Arkadiusz Dabrowski wrote:
...
> It works flawlessly but when I log out it is orphaned and not terminated.
> I start it like this:
> nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &
> Once started the parent is x-session-manager and they the same process
> group.
> What can I do to terminate the process with x-session?

  does it work if you don't put it in the background?


  songbird

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

#242234

On Wed 17 Nov 2021 at 22:39:21 (+0100), Arkadiusz Dabrowski wrote:

> I have a problem with unison sync termination when it is started from
> .xsessionrc.
> It works flawlessly but when I log out it is orphaned and not terminated.
> I start it like this:
> nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &
> Once started the parent is x-session-manager and they the same process
> group.

I think this is because you're starting it in the wrong file.
Everything in .xsessionrc should complete immediately. Use it
to set parameters and things like that.

> What can I do to terminate the process with x-session?

Start all your X clients and programs in .xsession. They should all be
backgrounded with &, as shown in   man xinit. There's an example at
about line 78 (buster version) on that page.

You'll see there that they start the Window Manager last. This has
disadvantages, in that you can't tell programs like xterm where to
map their windows if the WM hasn't yet started. This is solved by
exec'ing the WM early in .xsession, and waiting on its PID at the
end. If and when you close the WM, wait terminates and you fall out
of the end of .xsession, and X terminates.

That way, all these background processes get destroyed, and the same
is true if you are in the habit of using Ctrl-Alt-Backspace to kill
X rather than neatly closing the WM.

Briefly:

# ~/.xsession contents

# very early stuff
# [ … ]

if [ -x /usr/bin/fvwm ]; then
    exec /usr/bin/fvwm & Wmpid=$!
else
    printf '%s\n' "Error - no window manager found"
fi

# now start your clients and programs, all backgrounded with &
# [ … ]

# at the end of the file is one foreground program:

# wait for the window manager in the background to die
wait $Wmpid

# end-of-file

Cheers,
David.

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

#242238

On Thu, Nov 18, 2021 at 02:34:52PM -0600, David Wright wrote:
> On Wed 17 Nov 2021 at 22:39:21 (+0100), Arkadiusz Dabrowski wrote:
> 
> > I have a problem with unison sync termination when it is started from
> > .xsessionrc.
> > It works flawlessly but when I log out it is orphaned and not terminated.
> > I start it like this:
> > nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &
> > Once started the parent is x-session-manager and they the same process
> > group.
> 
> I think this is because you're starting it in the wrong file.
> Everything in .xsessionrc should complete immediately. Use it
> to set parameters and things like that.

I think of .xsessionrc a little differently.  It's the "novice mode" file,
which you can use regardless of which x-session-manager or x-window-manager
ultimately gets used, and without needing to take control of your whole
session yourself.

That makes it great for quickie "I just want to start xclock too" type
things, where maintaining a whole .xsession file would be overkill.

In the OP's case, though, they want something that "novice mode" can't
handle, so there's a decent reason to move to "advanced mode".

(I still wonder whether systemd offers anything relevant here.  And if
not, what the hell *is* the point of systemctl --user?  I've never used
it, nor found any reason to use it.  Yet.)

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

#242240

On Thu, Nov 18, 2021 at 03:46:48PM -0500, Greg Wooledge wrote:
>(I still wonder whether systemd offers anything relevant here.  And if
>not, what the hell *is* the point of systemctl --user?  I've never used
>it, nor found any reason to use it.  Yet.)

systemd certainly does offer something here. It's related to what
processes are considered to belong to a "session", it came in with
version 230, and there was quite a stink about it from people who
wanted this not to happen, at the time:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394>

It seems that the Debian Xsession setup does start a systemd --user
service. I've never tried to use it for this purpose.


-- 
Please do not CC me for listmail.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

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

#242243

On Thu, Nov 18, 2021 at 09:21:34PM +0000, Jonathan Dowland wrote:
> On Thu, Nov 18, 2021 at 03:46:48PM -0500, Greg Wooledge wrote:
> > (I still wonder whether systemd offers anything relevant here.  And if
> > not, what the hell *is* the point of systemctl --user?  I've never used
> > it, nor found any reason to use it.  Yet.)
> 
> systemd certainly does offer something here. It's related to what
> processes are considered to belong to a "session", it came in with
> version 230, and there was quite a stink about it from people who
> wanted this not to happen, at the time:
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394>
> 
> It seems that the Debian Xsession setup does start a systemd --user
> service. I've never tried to use it for this purpose.

I've seen that bug before.  That's a change which got reverted, or at
least, the default behavior was returned to the previous norm.

Debian's /etc/systemd/logind.conf has

#KillUserProcesses=no

which indicates that the default is for this "kill everything the user
left running" setting to be disabled, as it was before the controversial
change.

I think this is a dead end for this particular question, because it's
an all-or-nothing setting.  Either *all* background processes that the
user creates get nuked when the user logs out, or *none* of them do.  There
doesn't appear to be a way to "mark" particular processes for reaping
while leaving the rest alone.

Maybe some other part of systemd offers more flexibility, but if so, I
don't know what part it would be.  I'm still waiting to see an actual
user-friendly *document* that describes how to use systemd.

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

#242244

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

Thank You all guys for help!
If systemd feature is not an option I'll try a .xession solution. Looks
promising.

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

#242257

On Thu 18 Nov 2021 at 15:46:48 -0500, Greg Wooledge wrote:

> On Thu, Nov 18, 2021 at 02:34:52PM -0600, David Wright wrote:
> > On Wed 17 Nov 2021 at 22:39:21 (+0100), Arkadiusz Dabrowski wrote:
> > 
> > > I have a problem with unison sync termination when it is started from
> > > .xsessionrc.
> > > It works flawlessly but when I log out it is orphaned and not terminated.
> > > I start it like this:
> > > nice -n18 ionice -c2 -n7 unison unison_profile &>/dev/null &
> > > Once started the parent is x-session-manager and they the same process
> > > group.
> > 
> > I think this is because you're starting it in the wrong file.
> > Everything in .xsessionrc should complete immediately. Use it
> > to set parameters and things like that.
> 
> I think of .xsessionrc a little differently.  It's the "novice mode" file,
> which you can use regardless of which x-session-manager or x-window-manager
> ultimately gets used, and without needing to take control of your whole
> session yourself.
> 
> That makes it great for quickie "I just want to start xclock too" type
> things, where maintaining a whole .xsession file would be overkill.
> 
> In the OP's case, though, they want something that "novice mode" can't
> handle, so there's a decent reason to move to "advanced mode".

An interesting view. I think of ~/.xsession as being the correct,
traditional and well-tested file for a user to customise an X session
begun with startx or xdm. It never fails to work for novice users.

I think of ~/.xsessionrc in terms of the what is in the changelog for
xorg:

  * Add support for $HOME/.xsessionrc. Closes: #411639
    This file, if present, will get sourced during the start of your
    X session. This allows you to set session-wide environment variables
    easily for things like locale information. Patch adapted from one by
    Yves-Alexis Perez. Thanks also to Holger Levsen and Osamu Aoki for
    advice.

-- 
Brian.

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

#242271

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

Unfortunately, the solution with .xsession file doesn't work.
I resorted to something very simplistic:

<begin-of-the-file>
exec /usr/bin/marco
<EOF>

Note: I use mate desktop with marco wm.
Started with "exec" according to Debian documentation:
https://wiki.debian.org/Xsession
They also use some other stuff, I'm not sure if I need any of these lines:

xsetroot -solid grayxmodmap -e "keysym Super_L = Multi_key"xset s off;
xset dpms 0 1800 0exec fvwm


...and my session doesn't start at all - login popup disappears and nothing
else happens on the screen.
I see that marco is started and ssh-agent is the only process under it.
I have no idea why my .xsession file name appears in the command line where
ssh-agent is started but it looks suspicious. Another x-session is started?

root       17474  0.0  0.1 165776  9604 ?        Sl   21:23   0:00  \_
lightdm --session-child 12 21
arek       17484  0.0  0.3 274164 27188 ?        Ssl  21:23   0:00      \_
/usr/bin/marco
arek       17572  0.0  0.0   5964   468 ?        Ss   21:23   0:00
 \_ /usr/bin/ssh-agent env TMPDIR=/tmp/0_arek /usr/bin/im-launch /bin/bash
/home/arek/.xsession


What could happen here?

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

#242272

On Sat, Nov 20, 2021 at 09:46:24PM +0100, Arkadiusz Dabrowski wrote:
> Unfortunately, the solution with .xsession file doesn't work.
> I resorted to something very simplistic:
> 
> <begin-of-the-file>
> exec /usr/bin/marco
> <EOF>
> 
> Note: I use mate desktop with marco wm.

I doubt very much that this is the correct command for starting MATE.
Unfortunately, I am not a MATE user, so I don't know what the correct
command *is*.  But this doesn't look like it'll be the one.

Have you considered using my suggestion?  Put these two lines in .xsession:

. /etc/X11/Xsession
pkill unison

Keep your .xsessionrc which starts the unison program.  (Or you could
move it here, later, but for now I'm simply trying to do the bare
minimum needed to achieve a working setup.)

> Started with "exec" according to Debian documentation:
> https://wiki.debian.org/Xsession

You're cargo-culting stuff with zero understanding.  That's not going
to help.

If you don't know how shell scripts work, if you don't know what the
"exec" command does... then this is going to be quite difficult for you.

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

#242304

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

Have you considered using my suggestion?  Put these two lines in .xsession:
>
> . /etc/X11/Xsession
> pkill unison
>
> Keep your .xsessionrc which starts the unison program.  (Or you could
> move it here, later, but for now I'm simply trying to do the bare
> minimum needed to achieve a working setup.)
>
> That is even worse. I see that ~/.xsession is invoked from
etc/X11/Xsession (indirectly by calling
/etc/X11/Xsession.d/50x11-common_determine-startup)
and after .xsessionrc (called prior from
/etc/X11/Xsession.d/40x11-common_xsessionrc) so I ended-up with hundreds of
unison instances instead of new X session.

But it is not so bad: I learned about X11 starting process so will be able
to analyze it and invent something. So thanks a lot :)


> > Started with "exec" according to Debian documentation:
> > https://wiki.debian.org/Xsession
>
> You're cargo-culting stuff with zero understanding.  That's not going
> to help.
>
> If you don't know how shell scripts work, if you don't know what the
> "exec" command does... then this is going to be quite difficult for you.
>

Too far-reaching assumption. Only the second part about the "exec" was
right :) Now I know about the exec too.

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

#242308

On Sun, Nov 21, 2021 at 07:18:23PM +0100, Arkadiusz Dabrowski wrote:
> Have you considered using my suggestion?  Put these two lines in .xsession:
> >
> > . /etc/X11/Xsession
> > pkill unison
> >
> > Keep your .xsessionrc which starts the unison program.  (Or you could
> > move it here, later, but for now I'm simply trying to do the bare
> > minimum needed to achieve a working setup.)
> >
> > That is even worse. I see that ~/.xsession is invoked from
> etc/X11/Xsession (indirectly by calling
> /etc/X11/Xsession.d/50x11-common_determine-startup)
> and after .xsessionrc (called prior from
> /etc/X11/Xsession.d/40x11-common_xsessionrc) so I ended-up with hundreds of
> unison instances instead of new X session.
> 
> But it is not so bad: I learned about X11 starting process so will be able
> to analyze it and invent something. So thanks a lot :)

Damn.  I was hoping I could come up with a nice, simple way for a novice
user to introduce a .xsession file and reap the benefits thereof, without
having to undergo all of the complexity of writing a full-blown .xsession
file.

Apparently this is not possible.  Debian does not provide a single entry
point which a .xsession file can call upon to do all of the things that
the default system session does when .xsession is absent.  That logic is
buried inside one of the dotted-in files (not scripts) in
/etc/X11/Xsession.d/.

So, if you want to be able to kill a process while logging out of
your X session, apparently you need to create a whole .xsession file.
Congratulations: you're graduating out of novice mode whether you like
it or not.

The first thing you'll have to do is figure out how to actually start
your MATE session.  There'll be some magic starting point that you can
call.  I have no idea what it is.  Debian is probably just using a
symlink from /usr/bin/x-session-manager or something, so if you can't
find it on Google or from your own knowledge of MATE, maybe you could
start with that.

Since you want the process-killing to be done after you terminate your
interactive session, you need to *not* use "exec" when you execute the
MATE session.  That way, the shell will still be there to carry on with
the commands after MATE, one of which will kill the unison process.

In the interests of simplicity, I'd also advise getting rid of the
.xsessionrc file.  You might as well put everything in one file, instead
of two files.  It'll be a lot easier to track things down in the future
when you need to make a change, if they're all in one file.

Putting the unison invocation and the unison kill both in the same file
also means you can kill it *properly*, by keeping its PID, instead of
using pkill.

So then, it would look something like this:

your unison thing &
unisonPID=$!
other things you want to run
magic MATE start command
kill "$unisonPID"

Expect to need to tweak it a few times.  And good luck.

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

#242311

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

niedz., 21 lis 2021 o 20:16 Greg Wooledge <greg@wooledge.org> napisał(a):
>
> Damn.  I was hoping I could come up with a nice, simple way for a novice
> user to introduce a .xsession file and reap the benefits thereof, without
> having to undergo all of the complexity of writing a full-blown .xsession
> file.
>
> Apparently this is not possible.  Debian does not provide a single entry
> point which a .xsession file can call upon to do all of the things that
> the default system session does when .xsession is absent.  That logic is
> buried inside one of the dotted-in files (not scripts) in
> /etc/X11/Xsession.d/.
>
> So, if you want to be able to kill a process while logging out of
> your X session, apparently you need to create a whole .xsession file.
> Congratulations: you're graduating out of novice mode whether you like
> it or not.
>
> The first thing you'll have to do is figure out how to actually start
> your MATE session.  There'll be some magic starting point that you can
> call.  I have no idea what it is.  Debian is probably just using a
> symlink from /usr/bin/x-session-manager or something, so if you can't
> find it on Google or from your own knowledge of MATE, maybe you could
> start with that.
>
> Since you want the process-killing to be done after you terminate your
> interactive session, you need to *not* use "exec" when you execute the
> MATE session.  That way, the shell will still be there to carry on with
> the commands after MATE, one of which will kill the unison process.
>
> In the interests of simplicity, I'd also advise getting rid of the
> .xsessionrc file.  You might as well put everything in one file, instead
> of two files.  It'll be a lot easier to track things down in the future
> when you need to make a change, if they're all in one file.
>
> Putting the unison invocation and the unison kill both in the same file
> also means you can kill it *properly*, by keeping its PID, instead of
> using pkill.
>
> So then, it would look something like this:
>
> your unison thing &
> unisonPID=$!
> other things you want to run
> magic MATE start command
> kill "$unisonPID"
>
> Expect to need to tweak it a few times.  And good luck.

I see, that the real final executor is in the very-last file in the whole
sequence:
/etc/X11/Xsession.d/99x11-common_start:

exec $STARTUP

and STARTUP is set, according to file existence, to one of the
        x-session-manager
        x-window-manager
        x-terminal-emulator
but preferably to: ~/.xsession if it exists

So it seems I need to run one of these three standard executables in my
.xsession and surround it with my process execution and termination by PID.

Thanks again!

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

#242321

On Sun 21 Nov 2021 at 14:16:26 (-0500), Greg Wooledge wrote:
> On Sun, Nov 21, 2021 at 07:18:23PM +0100, Arkadiusz Dabrowski wrote:
> > Have you considered using my suggestion?  Put these two lines in .xsession:
> > >
> > > . /etc/X11/Xsession
> > > pkill unison
> > >
> > > Keep your .xsessionrc which starts the unison program.  (Or you could
> > > move it here, later, but for now I'm simply trying to do the bare
> > > minimum needed to achieve a working setup.)
> > >
> > > That is even worse. I see that ~/.xsession is invoked from
> > etc/X11/Xsession (indirectly by calling
> > /etc/X11/Xsession.d/50x11-common_determine-startup)
> > and after .xsessionrc (called prior from
> > /etc/X11/Xsession.d/40x11-common_xsessionrc) so I ended-up with hundreds of
> > unison instances instead of new X session.
> > 
> > But it is not so bad: I learned about X11 starting process so will be able
> > to analyze it and invent something. So thanks a lot :)
> 
> Damn.  I was hoping I could come up with a nice, simple way for a novice
> user to introduce a .xsession file and reap the benefits thereof, without
> having to undergo all of the complexity of writing a full-blown .xsession
> file.

Perhaps it's expected that a novice would run the GUI version of
unison, when all this would be unnecessary. (CLIs being the exception
rather than the rule.)

> Apparently this is not possible.  Debian does not provide a single entry
> point which a .xsession file can call upon to do all of the things that
> the default system session does when .xsession is absent.  That logic is
> buried inside one of the dotted-in files (not scripts) in
> /etc/X11/Xsession.d/.

Not very deeply, AFAICT. /etc/X11/Xsession.d/50x11-common_determine-startup
will set STARTUP to .[xX]session if either exists, but otherwise run
one of x-session-manager, x-window-manager and x-terminal-emulator, in
that order. If you've installed a DE, I'm guessing that it sets up
x-session-manager. I have fvwm installed, so my x-window-manager has
been set up, and likewise, xterm has set x-terminal-emulator to lxterm.
So a copy/paste/tweak of
  if [ -x /usr/bin/x-session-manager ]; then
    x-session-manager
  elif [ -x /usr/bin/x-window-manager ]; then
    x-window-manager
  elif [ -x /usr/bin/x-terminal-emulator ]; then
    x-terminal-emulator
  fi
should get you there (or just pick the one you want).

> So, if you want to be able to kill a process while logging out of
> your X session, apparently you need to create a whole .xsession file.
> Congratulations: you're graduating out of novice mode whether you like
> it or not.
> 
> The first thing you'll have to do is figure out how to actually start
> your MATE session.  There'll be some magic starting point that you can
> call.  I have no idea what it is.  Debian is probably just using a
> symlink from /usr/bin/x-session-manager or something, so if you can't
> find it on Google or from your own knowledge of MATE, maybe you could
> start with that.

Seems logical.

> Since you want the process-killing to be done after you terminate your
> interactive session, you need to *not* use "exec" when you execute the
> MATE session.  That way, the shell will still be there to carry on with
> the commands after MATE, one of which will kill the unison process.
> 
> In the interests of simplicity, I'd also advise getting rid of the
> .xsessionrc file.  You might as well put everything in one file, instead
> of two files.  It'll be a lot easier to track things down in the future
> when you need to make a change, if they're all in one file.
> 
> Putting the unison invocation and the unison kill both in the same file
> also means you can kill it *properly*, by keeping its PID, instead of
> using pkill.
> 
> So then, it would look something like this:
> 
> your unison thing &
> unisonPID=$!
> other things you want to run
> magic MATE start command
> kill "$unisonPID"

I expect that DEs have DontZap set, so that they get a chance to clean
up after themselves. (That's just a guess. I have no idea how X
servers, DEs and DMs interact with each other.)

I think that my expectation in my earlier post might have been
unrealistic. If you don't map any sort of window, then I'm not sure
that falling out of .xsession would kill a background job. And
zapping the X server likely wouldn't get to the kill command above.

So it would seem common sense to use the GUI that unison provides,
even if the window was minimised or iconified (whatever is possible
while the program is still left running).

> Expect to need to tweak it a few times.  And good luck.

Cheers,
David.

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

#242324

On Sun, Nov 21, 2021 at 11:39:53PM -0600, David Wright wrote:
> On Sun 21 Nov 2021 at 14:16:26 (-0500), Greg Wooledge wrote:
> > So then, it would look something like this:
> > 
> > your unison thing &
> > unisonPID=$!
> > other things you want to run
> > magic MATE start command
> > kill "$unisonPID"
> 
> I expect that DEs have DontZap set, so that they get a chance to clean
> up after themselves. (That's just a guess. I have no idea how X
> servers, DEs and DMs interact with each other.)
> 
> I think that my expectation in my earlier post might have been
> unrealistic. If you don't map any sort of window, then I'm not sure
> that falling out of .xsession would kill a background job. And
> zapping the X server likely wouldn't get to the kill command above.

I'm not sure what you're saying here.  Are you expecting that the OP is
going to "zap" the X server (by which I believe you mean pressing
a magic key combination like Ctrl-Alt-Backspace, with an appropriate
option set in the xorg.conf file to cause that to terminate the X server)
rather than exiting from MATE in the normal manner?

I'm expecting that the OP is exiting/logging out of MATE in whatever
the normal way is.  Further I'm expecting that this normal logout
action causes the "magic MATE start command" to terminate, returning
control to the .xsession script.

We're not "falling out of .xsession" either.  It's just a shell script,
so it works the way any other shell script works.  When the MATE session
ends, the .xsession shell script moves on to the next command, which
is kill.

> So it would seem common sense to use the GUI that unison provides,
> even if the window was minimised or iconified (whatever is possible
> while the program is still left running).

I know nothing about unison itself.  That might work, but I can't confirm
or deny it.  In either case, it doesn't appear to be what the OP wants.

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

#242333

On Mon 22 Nov 2021 at 07:31:04 (-0500), Greg Wooledge wrote:
> On Sun, Nov 21, 2021 at 11:39:53PM -0600, David Wright wrote:
> > On Sun 21 Nov 2021 at 14:16:26 (-0500), Greg Wooledge wrote:
> > > So then, it would look something like this:
> > > 
> > > your unison thing &
> > > unisonPID=$!
> > > other things you want to run
> > > magic MATE start command
> > > kill "$unisonPID"
> > 

¶A
> > I expect that DEs have DontZap set, so that they get a chance to clean
> > up after themselves. (That's just a guess. I have no idea how X
> > servers, DEs and DMs interact with each other.)
> > 

¶B
> > I think that my expectation in my earlier post might have been
> > unrealistic. If you don't map any sort of window, then I'm not sure
> > that falling out of .xsession would kill a background job. And
> > zapping the X server likely wouldn't get to the kill command above.
> 
> I'm not sure what you're saying here.  Are you expecting that the OP is
> going to "zap" the X server (by which I believe you mean pressing
> a magic key combination like Ctrl-Alt-Backspace, with an appropriate
> option set in the xorg.conf file to cause that to terminate the X server)
> rather than exiting from MATE in the normal manner?

When I wrote the post that ¶B refers to, the only evidence that the OP
was using a DE was mention of x-session-manager, which I've never seen
or used. Hence I overlooked it. So that post was written from the
viewpoint of startx, and I'm sure many users of startx terminate their
X server with C-A-B rather that exiting the WM. In my case, it's one
keystroke versus two well-aimed mouse clicks (and the latter assumes
that part of the root window is actually exposed), so you can guess
which way I choose.

> I'm expecting that the OP is exiting/logging out of MATE in whatever
> the normal way is.  Further I'm expecting that this normal logout
> action causes the "magic MATE start command" to terminate, returning
> control to the .xsession script.

As I wrote there, ¶A is a presumption that I have little chance of
confirming myself in the foreseeable future. (If it's untrue, I'd
expect someone would contradict and/or correct it pretty quickly.)

> We're not "falling out of .xsession" either.  It's just a shell script,
> so it works the way any other shell script works.  When the MATE session
> ends, the .xsession shell script moves on to the next command, which
> is kill.

So, back to ¶B; if you're not in the habit of putting exit 0 or return 0
at the end of every script, function, program, etc, that you write,
then most scripts you run can probably terminate by "falling out of
the end". (A counterexample would be FORTRAN X3.9-1966.)

I implied in my first post that a background job started in .xsession
would be killed when the X server terminated, be that by reaching the
end of the .xsession script (if you prefer that expression), or by
killing the X server (which abandons the rest of the .xsession script).
But I think this applies only if it maps a window, hence the need to
kill it, as shown in your example above, and absent from my post.

> > So it would seem common sense to use the GUI that unison provides,
> > even if the window was minimised or iconified (whatever is possible
> > while the program is still left running).
> 
> I know nothing about unison itself.

Nor I, beyond these lines from the Packages file (buster):

  Package: unison
  Description: file-synchronization tool for Unix and Windows

  Package: unison-gtk
  Description: file-synchronization tool for Unix and Windows with GTK+ interface
  Tag: admin::backup, admin::file-distribution, implemented-in::ocaml,
   interface::graphical, interface::x11, role::program, scope::utility,
   uitoolkit::gtk, uitoolkit::ncurses, use::synchronizing,
   x11::application

> That might work, but I can't confirm
> or deny it.  In either case, it doesn't appear to be what the OP wants.

No, but I don't let that constrain my thoughts on a topic. IANAI.
(I am not an intern.)

Cheers,
David.

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

#242326

Am 20.11.2021 22:19 schrieb Greg Wooledge:
> On Sat, Nov 20, 2021 at 09:46:24PM +0100, Arkadiusz Dabrowski wrote:
>> Started with "exec" according to Debian documentation:
>> https://wiki.debian.org/Xsession
> 
> You're cargo-culting stuff with zero understanding.  That's not going
> to help.
> 
> If you don't know how shell scripts work, if you don't know what the
> "exec" command does... then this is going to be quite difficult for 
> you.

I know the difference between using exec and not using exec, but I've 
never understood why Debian explicitly suggests using exec to start the 
wm in .xsession. Maybe to release resources held by the shell instance?

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web