Hi,
Max Nikulin wrote:
> > > A bit off-topic question. In what wiki page you would expect to find
> > > suggestions to inspect ~/.xsession-errors file and journalctl output?
I wrote:
> > I pasted ".xsession-errors" into the "Search:" field at the up
On 23/07/2024 19:20, Thomas Schmitt wrote:
A bit off-topic question. In what wiki page you would expect to find
suggestions to inspect ~/.xsession-errors file and journalctl output?
I pasted ".xsession-errors" into the "Search:" field at the upper right
corner of any
On Tue, Jul 23, 2024 at 14:20:43 +0200, Thomas Schmitt wrote:
> The only helpful match is
>
>
> https://wiki.debian.org/JigdoOnLive?action=fullsearch&context=180&value=.xsession-errors&fullsearch=Text
>
> "What Does The Log Say?
>...
>I
Hi,
Max Nikulin wrote:
> A bit off-topic question. In what wiki page you would expect to find
> suggestions to inspect ~/.xsession-errors file and journalctl output?
I pasted ".xsession-errors" into the "Search:" field at the upper right
corner of any Debian wiki
I've finally sorted it out. The problem is Debian bug 870126.
Work around it by manually adding:
sessionoptional pam_keyinit.so force revoke
to /etc/pam.d/nodm
On 2021-11-01, Lucio Crusca wrote:
> On Nov 1, 2021 I wrote:
>> (actually a Raspbian, but I assume it's no different
>
> I've now tried installing a clean Debian 11 with Nodm in a virtual
> machine and I face exactly the same problem, so we can safely exclude
> any Raspbian-specific problems.
>
On Nov 1, 2021 I wrote:
(actually a Raspbian, but I assume it's no different
I've now tried installing a clean Debian 11 with Nodm in a virtual
machine and I face exactly the same problem, so we can safely exclude
any Raspbian-specific problems.
$HOME`
automatically at system startup. The system is a Debian GNU/Linux 10
(actually a Raspbian, but I assume it's no different to this end) that
uses NoDM [1] to start Xorg. It automatically logs the unprivileged user
in and it runs the `$HOME/.xsession` startup script.
I have the following scrip
On Sun, Nov 1, 2020, 11:48 AM Teemu Likonen wrote:
> * 2020-11-01 11:09:50+01, Anders Andersson wrote:
>
> > On Mon, Oct 26, 2020 at 5:43 PM Teemu Likonen wrote:
> >> From my backups I found an ~/.xsession-errors file of size 111
> >> megabytes. Probably I deleted
* 2020-11-01 11:09:50+01, Anders Andersson wrote:
> On Mon, Oct 26, 2020 at 5:43 PM Teemu Likonen wrote:
>> From my backups I found an ~/.xsession-errors file of size 111
>> megabytes. Probably I deleted the file at that point and it started
>> grow again.
>
> Amateur
On Mon, Oct 26, 2020 at 5:43 PM Teemu Likonen wrote:
>
> It seems that ~/.xsession-errors file can still grow to infinity in
> size. Sometimes it grows really fast. This is nothing new: we have all
> seen it and talked about it. What do you do to maintain this file?
>
> - Do
d any code that referenced
> > "xsession-errors" or "ERRFILE" or any logfile except
> > "~/.cache/lxsession/LXDE/run.log".
>
> The relevant code apparently exists in the greeter app (or whatever it's
> called) I use (lightdm):
>
> src
On 2020-10-28, David wrote:
>
> Yes, I don't feel that I found the full answer. Because I spent a while
> using https://codesearch.debian.net/ to examine the source code
> of lxsession but I was unable to find any code that referenced
> "xsession-errors" or &
On Tue 27 Oct 2020 at 07:53:01 (-0400), Greg Wooledge wrote:
> On Tue, Oct 27, 2020 at 11:28:12AM +1100, David wrote:
> > On Tue, 27 Oct 2020 at 10:56, David Wright wrote:
> > > fuser -v "$j"
> > > [ $? -ne 0 ] && gzip "$j&
, Tixy wrote:
> > > > > On Mon, 2020-10-26 at 18:35 +0200, Teemu Likonen wrote:
> > > > > > It seems that ~/.xsession-errors file can still grow to infinity in
> > > > > > size. Sometimes it grows really fast. This is nothing new: we have
> &
Likonen wrote:
>
> > > > > It seems that ~/.xsession-errors file can still grow to infinity in
> > > > > size. Sometimes it grows really fast. This is nothing new: we have all
> > > > > seen it and talked about it. What do you do to maintain this file?
On Mi, 28 oct 20, 15:28:37, David wrote:
> On Wed, 28 Oct 2020 at 00:45, Andrei POPESCU wrote:
>
> > On my system the file is rotated (renamed to .xsession-errors.old), on
> > every login as far as I can tell.
>
> > Didn't find (yet) what is doing this (using li
On Wed, 28 Oct 2020 at 00:45, Andrei POPESCU wrote:
> On Ma, 27 oct 20, 07:55:00, Greg Wooledge wrote:
> > On Mon, Oct 26, 2020 at 11:07:37PM +, Tixy wrote:
> > > On Mon, 2020-10-26 at 18:35 +0200, Teemu Likonen wrote:
> > > > It seems that ~/.xsession-errors f
t; (Why doesn't Debian have this automatically?)
I simply (like someone else mentioned on the list) truncate the file
periodically (actually, once every minute) using a crontab with a task like
this:
* * * * * echo "Cleared on $(date) by $USER cron" >
/home//.xsess
r instance, such logrotate policy
> would be denied by SELinux.
> That, and inviting running-as-root logrotate to cleanup user files opens
> all kinds of trouble.
I'm using KDE Plasma desktop and my .xsession-errors grows quite fast.
I'll probably write some rotation system
On Ma, 27 oct 20, 07:55:00, Greg Wooledge wrote:
> On Mon, Oct 26, 2020 at 11:07:37PM +, Tixy wrote:
> > On Mon, 2020-10-26 at 18:35 +0200, Teemu Likonen wrote:
> > > It seems that ~/.xsession-errors file can still grow to infinity in
> > > size. Sometimes it grows r
On Mon, Oct 26, 2020 at 11:07:37PM +, Tixy wrote:
> On Mon, 2020-10-26 at 18:35 +0200, Teemu Likonen wrote:
> > It seems that ~/.xsession-errors file can still grow to infinity in
> > size. Sometimes it grows really fast. This is nothing new: we have all
> > seen it and
On Tue, Oct 27, 2020 at 11:28:12AM +1100, David wrote:
> On Tue, 27 Oct 2020 at 10:56, David Wright wrote:
> > fuser -v "$j"
> > [ $? -ne 0 ] && gzip "$j" && mv -i "$j.gz" "$HOME/.monitors/xsession/"
>
> &
On Tue, 27 Oct 2020 at 10:56, David Wright wrote:
> fuser -v "$j"
> [ $? -ne 0 ] && gzip "$j" && mv -i "$j.gz" "$HOME/.monitors/xsession/"
[...]
> (Script improvements always appreciated.)
Hi, you might be interes
On Mon 26 Oct 2020 at 18:35:45 (+0200), Teemu Likonen wrote:
> It seems that ~/.xsession-errors file can still grow to infinity in
> size. Sometimes it grows really fast. This is nothing new: we have all
> seen it and talked about it. What do you do to maintain this file?
>
>
Tixy writes:
> I guess as I never hibernate my laptop and turn it off every day, it
> never gets to an annoying size.
I haven't rebooted my desktop for three months. ls -l .xsession-errors
shows 468223. I consider that trivial and ignore it.
--
John Hasler
jhas...@newsguy.com
Elmwood, WI USA
On Mon, 2020-10-26 at 18:35 +0200, Teemu Likonen wrote:
> It seems that ~/.xsession-errors file can still grow to infinity in
> size. Sometimes it grows really fast. This is nothing new: we have all
> seen it and talked about it. What do you do to maintain this file?
Don't do anyt
Teemu Likonen writes:
It seems that ~/.xsession-errors file can still grow to infinity in
size. Sometimes it grows really fast. This is nothing new: we have all
seen it and talked about it. What do you do to maintain this file?
Until now, I had not seen it as a problem. But it is quite large
n 2005-02-27. There are ideas about
/etc/X11/Xsession script too. Debian developers certainly can fix this
if they want.
--
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450
signature.asc
Description: PGP signature
On 2020-10-26 18:35 +0200, Teemu Likonen wrote:
> It seems that ~/.xsession-errors file can still grow to infinity in
> size. Sometimes it grows really fast. This is nothing new: we have all
> seen it and talked about it. What do you do to maintain this file?
>
> - Do you just
Hi.
On Mon, Oct 26, 2020 at 06:35:45PM +0200, Teemu Likonen wrote:
> It seems that ~/.xsession-errors file can still grow to infinity in
> size. Sometimes it grows really fast. This is nothing new: we have all
> seen it and talked about it. What do you do to maintain
It seems that ~/.xsession-errors file can still grow to infinity in
size. Sometimes it grows really fast. This is nothing new: we have all
seen it and talked about it. What do you do to maintain this file?
- Do you just delete it when you happen to notice it's too big?
- Do you conf
Hi there,
I found the following in the ~/.xsession-errors :
dbus-update-activation-environment: warning: error sending to systemd:
org.freedesktop.DBus.Error.Spawn.ChildExited: Process
org.freedesktop.systemd1 exited with status 1
I was trying to search the net but no luck. Any suggestions
On 2018-04-06 18:56, Greg Wooledge wrote:
> On Fri, Apr 06, 2018 at 06:45:20PM +0200, Mikhail Morfikov wrote:
>> Basically even the standard "exec ..." in the /etc/X11/Xsession file (with
>> changed $ERRFILE) works fine, but I have to "cat" the FIFO device first
On Fri, Apr 06, 2018 at 06:45:20PM +0200, Mikhail Morfikov wrote:
> Basically even the standard "exec ..." in the /etc/X11/Xsession file (with
> changed $ERRFILE) works fine, but I have to "cat" the FIFO device first
> (without
> using systemd). The same with
On 2018-04-06 17:53, Greg Wooledge wrote:
> On Fri, Apr 06, 2018 at 05:48:35PM +0200, Mikhail Morfikov wrote:
>> If I set $ERRFILE to the FIFO device, processing of the script will be
>> stopped
>> in the point where "exec ..." appears (before sourcing the
>> /etc/X11/Xsession.d/
>> dir).
>
> Yo
On 2018-04-06 18:29, Don Armstrong wrote:
> On Fri, 06 Apr 2018, Mikhail Morfikov wrote:
>> Basically, all messages returned by X-applications are redirected to the
>> ~/.xsession-errors file.
> [...]
>> Unfortunately, the ~/.xsession-errors file grows in size, and a
On Fri, 06 Apr 2018, Mikhail Morfikov wrote:
> Basically, all messages returned by X-applications are redirected to the
> ~/.xsession-errors file.
[...]
> Unfortunately, the ~/.xsession-errors file grows in size, and after a
> few hours it's around 20-30 MiB, and the content
On Fri, Apr 06, 2018 at 05:48:35PM +0200, Mikhail Morfikov wrote:
> If I set $ERRFILE to the FIFO device, processing of the script will be stopped
> in the point where "exec ..." appears (before sourcing the
> /etc/X11/Xsession.d/
> dir).
You need to run something in the background which opens th
On 2018-04-06 15:48, to...@tuxteam.de wrote:
> On Fri, Apr 06, 2018 at 03:18:08PM +0200, Mikhail Morfikov wrote:
>> Basically, all messages returned by X-applications are redirected to the
>> ~/.xsession-errors file [...]
>
>> till a terminal with "cat" is st
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 06, 2018 at 03:18:08PM +0200, Mikhail Morfikov wrote:
> Basically, all messages returned by X-applications are redirected to the
> ~/.xsession-errors file [...]
> till a terminal with "cat" is started inside of the
Basically, all messages returned by X-applications are redirected to the
~/.xsession-errors file. In some desktop environments this file is emptied with
each X session restart. At least that was the case of my Openbox + LightDM
setup. Now, I'm trying to migrate to KDE/Plasma5, and as a part
On Fri 24 Jun 2016 at 13:13:22 (-0700), Mike McClain wrote:
> I open several aps in .xsession, a couple of xterms, clock, iceweasel.
> The first in .xsession is an xterm I use for command line stuff.
> This xterm is seldom at any one pts but rather moves around. Is there
> a w
I open several aps in .xsession, a couple of xterms, clock, iceweasel.
The first in .xsession is an xterm I use for command line stuff.
This xterm is seldom at any one pts but rather moves around. Is there
a way to tell X to always open that xterm on /dev/pts/1?
Thanks,
Mike
--
During
On Sat 08 Nov 2014 at 07:16:41 -1000, Joel Roth wrote:
> On Sat, Nov 08, 2014 at 04:17:21PM +, Brian wrote:
> > On Sat 08 Nov 2014 at 06:02:00 -1000, Joel Roth wrote:
> >
> > > Do you have a reference about .xinitrc vs. .xsession?
> >
> > Lots. :).
On Sat, Nov 08, 2014 at 04:17:21PM +, Brian wrote:
> On Sat 08 Nov 2014 at 06:02:00 -1000, Joel Roth wrote:
>
> > Do you have a reference about .xinitrc vs. .xsession?
>
> Lots. :). Fortunately, startx(1) has now been altered to read:
>
> Note that in the Debian
Not exactly sure how display managers handle defaults when you have
> > both. Per user there is also ~/.dmrc.
> >
>
> In this particular case, the problem was an ~/.xinitrc, (linked to
> ~/.xsession, dated 1994!!! launching fvwm,) in the user's account. If
> a .xinit
On 25/10/14 22:11, John Conover wrote:
> Andrei POPESCU writes:
>> On Vi, 24 oct 14, 09:33:59, Raffaele Morelli wrote:
>>> On 24/10/14 at 10:17am, Andrei POPESCU wrote:
>>>> On Jo, 23 oct 14, 19:38:15, John Conover wrote:
>>>>>
>>>>> I
Andrei POPESCU writes:
> On Vi, 24 oct 14, 09:33:59, Raffaele Morelli wrote:
> > On 24/10/14 at 10:17am, Andrei POPESCU wrote:
> > > On Jo, 23 oct 14, 19:38:15, John Conover wrote:
> > > >
> > > > I use two WM, (xfce and fvwm.) Lightdm's "D
On Vi, 24 oct 14, 09:33:59, Raffaele Morelli wrote:
> On 24/10/14 at 10:17am, Andrei POPESCU wrote:
> > On Jo, 23 oct 14, 19:38:15, John Conover wrote:
> > >
> > > I use two WM, (xfce and fvwm.) Lightdm's "Default Xsession" is fvwm2.
> > >
&g
On 24/10/14 at 10:17am, Andrei POPESCU wrote:
> On Jo, 23 oct 14, 19:38:15, John Conover wrote:
> >
> > I use two WM, (xfce and fvwm.) Lightdm's "Default Xsession" is fvwm2.
> >
> > How do I change lightdm's "Default Xsession" to xfce?
>
On Jo, 23 oct 14, 19:38:15, John Conover wrote:
>
> I use two WM, (xfce and fvwm.) Lightdm's "Default Xsession" is fvwm2.
>
> How do I change lightdm's "Default Xsession" to xfce?
I prefer to do this at system level (i.e. will work for any DM):
On 23/10/14 at 07:38pm, John Conover wrote:
>
> I use two WM, (xfce and fvwm.) Lightdm's "Default Xsession" is fvwm2.
>
> How do I change lightdm's "Default Xsession" to xfce?
>
> Thanks,
>
> John
>
> --
>
> John Co
On 24/10/14 13:38, John Conover wrote:
>
> I use two WM, (xfce and fvwm.) Lightdm's "Default Xsession" is fvwm2.
>
> How do I change lightdm's "Default Xsession" to xfce?
>
> Thanks,
>
> John
>
As root:-
/usr/lib/i386-linux-gnu/
I use two WM, (xfce and fvwm.) Lightdm's "Default Xsession" is fvwm2.
How do I change lightdm's "Default Xsession" to xfce?
Thanks,
John
--
John Conover, cono...@rahul.net, http://www.johncon.com/
--
To UNSUBSCRIBE, email to debian-user-requ...@lists
On Mon, 15 Sep 2014 15:07:48 +0800
Bret Busby wrote:
> On 15/09/2014, Chen Wei wrote:
> > On Tue, Sep 09, 2014 at 03:29:04PM +0800, Bret Busby wrote:
> >> .xsession-errors, which is currently sitting at about 740MB, and
> >> has been growing in the last hour.
> &
On 15/09/2014, Chen Wei wrote:
> On Tue, Sep 09, 2014 at 03:29:04PM +0800, Bret Busby wrote:
>> .xsession-errors, which is currently sitting at about 740MB, and has
>> been growing in the last hour.
>>
>> entries from before the current boot session) entries, so as to
On Tue, Sep 09, 2014 at 03:29:04PM +0800, Bret Busby wrote:
> .xsession-errors, which is currently sitting at about 740MB, and has
> been growing in the last hour.
>
> entries from before the current boot session) entries, so as to reduce
> the file size to content that is necessar
Bret Busby writes:
> So, I believe (unttil and unless, advised otherwise) that the
> deleteing the file (which did not free up the disc space, in itself),
> and then, renaming the xsystem-errors.old file, to xsystem-errors,
> appears to have disappeared the problem, which, if I had known
> earlie
Bret Busby writes:
> I note that, with that file that is being accessed by Nautilus,
> assuming that the number 1169162 , is the size of the file, I have
> tried, but, apparently, can not reduce that to zero, as that number
> does not change, with my attempts.
On a side note: You could try nemo
still have the system
up in
the same state, you might see it in /proc/$(pidof Xorg)/fd (or it might
be
another process other than Xorg, or I might be wrong entirely)
if you have lsof installed, you can find out what processes are still
using the deleted file quite easily:
$ lsof |grep '
installed, you can find out what processes are still
> using the deleted file quite easily:
>
> $ lsof |grep '\.xsession-errors'
>
> might produce lines like
>
> xterm 2237 busbyenator 1w REG 8,1 0 359981
> /home/busbyenator/.xsession-errors (deleted)
> xterm
ed the file, then ran "Empty Trash Can",
>> but, no disc space was freed, then, subsequently, I observed that a
>> new file had been created;
>> .xsession-errors.old
>> with a size of about 33kB, and so I overwrote that, as described
>> above, and that red
might be
another process other than Xorg, or I might be wrong entirely)
if you have lsof installed, you can find out what processes are still
using the deleted file quite easily:
$ lsof |grep '\.xsession-errors'
might produce lines like
xterm 2237 busbyenator 1w REG 8,1 0 359981 /h
but, no disc space was freed, then, subsequently, I observed that a
> new file had been created;
> .xsession-errors.old
> with a size of about 33kB, and so I overwrote that, as described
> above, and that reduced its size to zero, but, I now do not have the
> original file with whic
On Wed, Sep 10, 2014 at 01:54:08AM +0800, Bret Busby wrote:
> The file has (kind of) gone, now (it is no longer accessible, but,
> appears to still exist, in the ether of the unknown; still taking up
> disc space, whilst, in theory, non-existent),
A file continues to use up disk space until all op
On 10/09/2014, Brian wrote:
> On Wed 10 Sep 2014 at 01:24:24 +0800, Bret Busby wrote:
>
>> Just out of interest, "top" shows the system as having been up for 21
>> days, so, the xsession-errors file grew to 743MB, in 21 days. I saw,
>> at the top of that file, be
On Wed 10 Sep 2014 at 01:24:24 +0800, Bret Busby wrote:
> Just out of interest, "top" shows the system as having been up for 21
> days, so, the xsession-errors file grew to 743MB, in 21 days. I saw,
> at the top of that file, before I deleted it, reference to 21 August,
> s
age to the boot session, would occur.
>>
>> I very much doubt that any such damage would occur by deleting it, but
>> the following incantation is one answer:
>>
>> tal% ls -alh .xsession-errors
>> -rw--- 1 chrisb chrisb 33K Sep 9 17:40 .xsession-errors
>&
doubt that any such damage would occur by deleting it, but
> the following incantation is one answer:
>
> tal% ls -alh .xsession-errors
> -rw--- 1 chrisb chrisb 33K Sep 9 17:40 .xsession-errors
>
> tal% :> .xsession-errors
> tal% ls -alh .xsession-errors
> -rw---
he following incantation is one answer:
tal% ls -alh .xsession-errors
-rw--- 1 chrisb chrisb 33K Sep 9 17:40 .xsession-errors
tal% :> .xsession-errors
tal% ls -alh .xsession-errors
-rw--- 1 chrisb chrisb 0 Sep 9 21:25 .xsession-errors
--
"If you're not careful, the newspapers
On 09/09/14 at 03:29pm, Bret Busby wrote:
> Hello.
>
> In trying to work out why my disk space gets progressively consumed so
> that I repeatedly run out of disc space without any known reason, in
> examining my hidden files in my home directory, I found the file
> .xsessio
file size to content that is necessary to retain for debugging?
xsession-errors should be re-created when a new session starts (see
/etc/X11/Xsession for the details). Long-running X session can produce
annoyingly large .xsession-errors indeed.
The solution to this problem comes in the form of logro
Hello.
In trying to work out why my disk space gets progressively consumed so
that I repeatedly run out of disc space without any known reason, in
examining my hidden files in my home directory, I found the file
.xsession-errors, which is currently sitting at about 740MB, and has
been growing in
> > Bug#739444
Oops, by accident I posted a wrong link.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1392754630.2586.42.camel@archlinux
On Tue, 2014-02-18 at 11:19 -0600, y...@marupa.net wrote:
> This is probably not the best advice but: If nothing slows
> down/crashes/screws up data, then you can probably ignore it.
It's a good advice, it's only missing that people should do some
Internet research.
https://bugs.debian.org/cgi-bi
On 18/02/14 02:02 PM, Sven Joachim wrote:
On 2014-02-18 18:12 +0100, Frank McCormick wrote:
I have been noticing this error in .xsession-errors file lately:
glibtop: Non-standard uts for running kernel:
release 3.12-1-686-pae=3.12.0 gives version code 199680
Can someone explain what's
code:
Fwd: Bug#739444: glibtop: Non-standard uts for running kernel:
Package: libgtop2-7
Version: 2.28.5-2
Severity: normal
Dear Maintainer,
* What led up to the situation?
..xsession-errors entry:
glibtop: Non-standard uts for running kernel:
release 3.12-1-amd64=3.12.0 gives version code
uts for running kernel:
Package: libgtop2-7
Version: 2.28.5-2
Severity: normal
Dear Maintainer,
* What led up to the situation?
..xsession-errors entry:
glibtop: Non-standard uts for running kernel:
release 3.12-1-amd64=3.12.0 gives version code 199680
I have a comment to the bug...re
ibgtop2-7
Version: 2.28.5-2
Severity: normal
Dear Maintainer,
* What led up to the situation?
..xsession-errors entry:
glibtop: Non-standard uts for running kernel:
release 3.12-1-amd64=3.12.0 gives version code 199680
--
Paul Cartwright
Registered Linux User #367800 and new counte
On 2014-02-18 18:12 +0100, Frank McCormick wrote:
> I have been noticing this error in .xsession-errors file lately:
>
>
> glibtop: Non-standard uts for running kernel:
> release 3.12-1-686-pae=3.12.0 gives version code 199680
>
> Can someone explain what's this about ?
On Tuesday, February 18, 2014 12:12:20 PM Frank McCormick wrote:
> I have been noticing this error in .xsession-errors file lately:
>
>
> glibtop: Non-standard uts for running kernel:
> release 3.12-1-686-pae=3.12.0 gives version code 199680
>
>
> Can someone explain wh
I have been noticing this error in .xsession-errors file lately:
glibtop: Non-standard uts for running kernel:
release 3.12-1-686-pae=3.12.0 gives version code 199680
Can someone explain what's this about ? Should I be concerned?
Thanks
--
To UNSUBSCRIBE, email to debian-user
On 1/3/14, Brian wrote:
> On Fri 03 Jan 2014 at 16:28:05 +1100, Zenaan Harkness wrote:
>> On 12/13/13, Zenaan Harkness wrote:
>> >
>> > Clearly consolekit is started (logout, as well as reboot etc now
>> > work), my keyboard shortcuts work etc.
>> >
>> > This seems ideal - no per-user configurati
On Fri 03 Jan 2014 at 16:28:05 +1100, Zenaan Harkness wrote:
> On 12/13/13, Zenaan Harkness wrote:
> >
> > Clearly consolekit is started (logout, as well as reboot etc now
> > work), my keyboard shortcuts work etc.
> >
> > This seems ideal - no per-user configuration, and it just works (TM)(C)(R)
was inspired by what is the new/current "debian way".
>
> On a whim, I removed ~/.xinitrc and ~/.xsession and I have no ~/.xsessionrc
> .
>
> So now things work as well as they did with ~/.xinitrc , but without
> any ~/.x* files! This is good.
>
> Clearly consolekit is starte
On 2013-12-12 00:21:18 -0700, Bob Proulx wrote:
> 2.1 xdm graphical login manager (or gdm, or kdm, or lightdm, or other)
> Runs /etc/X11/Xsession
> Redirects output to .xsession-errors
[...]
Not for gdm3 3.5.2+. $XDG_CACHE_HOME/gdm/session.log is now used,
but this is cu
On Mon 16 Dec 2013 at 17:17:01 +1300, Chris Bannister wrote:
> On Sat, Dec 14, 2013 at 08:25:56PM +, Brian wrote:
> >
> > Put
> >
> >exec fvwm
> >
> > after the xterm command in .xsession. This command does not complete and
> > .xsessio
On Sat, Dec 14, 2013 at 08:25:56PM +, Brian wrote:
>
> Put
>
>exec fvwm
>
> after the xterm command in .xsession. This command does not complete and
> .xsession doesn't close. You've summoned X, give it a chance to show off
> what it can do :).
>
&g
und: blue" -geom 120x15 &
> tal%
You start an xterm. Remember that a script executes each line
sequentially and only moves on to the next line if the previous command
completes.
The xterm is put in the background; the command has completed. There is
no next line in .xsessionrc so /etc/X
On Sun, 15 Dec 2013 06:29:52 +1300 Chris Bannister sent:
> I do remember this issue in the past, a google was not very helpful -
> and may even have been misleading - e.g. suggesting that .xsessionrc
> was the correct file to use. And since .xsession or .xinitrc didn't
> work I
On Thu, Dec 12, 2013 at 02:23:48PM +, Brian wrote:
> On Thu 12 Dec 2013 at 00:21:18 -0700, Bob Proulx wrote:
>
> > The man page for Xsession documents ~/.xsessionrc and ~/.xsession. It
> > says that ~/.xsessionrc is only for setting variables and the
> > ~/.xsession i
Brian wrote:
> May we look a little closer at one or two of the things you say?
>
> Bob Proulx wrote:
> > Because startx does not use .xsession. You have things criss-crossed.
Oops! I was definitely wrong with that statement.
> 1. Running startx basically runs xinit.
&g
ven in
>
>/usr/share/doc/xfce4-session/README.Debian
This is excellent advice.
Please Note: before these experiments, I simply had ~/.xinitrc, and
startx worked.
However, I was inspired by what is the new/current "debian way".
On a whim, I removed ~/.xinitrc and ~/.xsessi
On Thu, 12 Dec 2013 19:13:50 + Brian sent:
> [When talking about .xsessionrc versus .xsession]
>
> > I might just revert it back to ~/.xsession and see what error
> > messages I receive, if any?
>
> You won't get any error messages. The system will execute v
On Thu, 12 Dec 2013 14:23:48 + Brian sent:
> Putting commands in .xsessionrc is very naughty. Are you still there,
> Charlie? For your own good, please stop doing it.
I've renamed the file to ~/.xsession after reading the information Bob
kindly supplied and it's all working
On Thu 12 Dec 2013 at 17:47:12 +1100, Charlie wrote:
> I'm happy with what happens when I boot my system - same as when I
> used .xsessionrc with FVWM. But will look into it and read a bit when
> time permits. I could be doing the wrong thing entirely.
You are. But you will never know until you e
On Thu 12 Dec 2013 at 22:18:31 +1100, Charlie wrote:
[When talking about .xsessionrc versus .xsession]
> I might just revert it back to ~/.xsession and see what error messages
> I receive, if any?
You won't get any error messages. The system will execute valid commands
in .xessio
de kdm :). I'm unsure that helps.
> I have experimented with a couple combinations, but there are too many.
Keep .xsession as a contant. You know it makes sense.
> I have at the moment, startx working well, with .xinitrc and .xsession
> both linking to the same file (bash script, wit
May we look a little closer at one or two of the things you say?
On Wed 11 Dec 2013 at 23:36:51 -0700, Bob Proulx wrote:
> Because startx does not use .xsession. You have things criss-crossed.
1. Running startx basically runs xinit.
2. startx first looks for ~/.xinitrc which, unless there
1 - 100 of 484 matches
Mail list logo
