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


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

Re: Re: Reproducible bug

Started byLaurent Lyaudet <laurent.lyaudet@gmail.com>
First post2017-11-10 20:50 +0100
Last post2017-11-14 09:40 +0100
Articles 10 — 6 participants

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


Contents

  Re: Re: Reproducible bug Laurent Lyaudet <laurent.lyaudet@gmail.com> - 2017-11-10 20:50 +0100
    Re: Re: Reproducible bug deloptes <deloptes@gmail.com> - 2017-11-10 21:10 +0100
    Re: Re: Reproducible bug Laurent Lyaudet <laurent.lyaudet@gmail.com> - 2017-11-12 17:50 +0100
      Re: Re: Reproducible bug deloptes <deloptes@gmail.com> - 2017-11-12 18:10 +0100
      Re: Re: Reproducible bug Cindy-Sue Causey <butterflybytes@gmail.com> - 2017-11-12 18:30 +0100
        Hidden files [was: Reproducible bug] <tomas@tuxteam.de> - 2017-11-12 18:50 +0100
        Re: Reproducible bug Curt <curty@free.fr> - 2017-11-12 19:20 +0100
      Re: Re: Reproducible bug Laurent Lyaudet <laurent.lyaudet@gmail.com> - 2017-11-12 21:10 +0100
        Re: Reproducible bug David Wright <deblis@lionunicorn.co.uk> - 2017-11-14 03:50 +0100
        Re: Reproducible bug Curt <curty@free.fr> - 2017-11-14 09:40 +0100

#188858 — Re: Re: Reproducible bug

FromLaurent Lyaudet <laurent.lyaudet@gmail.com>
Date2017-11-10 20:50 +0100
SubjectRe: Re: Reproducible bug
Message-ID<uKntn-7Bp-1@gated-at.bofh.it>

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

2017-11-09 20:03 GMT+01:00 Laurent Lyaudet <laurent.lyaudet@gmail.com>:

> >On Wed, Nov 08, 2017 at 08:19:11PM +0100, Laurent Lyaudet wrote:
> >>    Hello,
> >>
> >>    I found a reproducible bug in latest stable Debian on my laptop.
> >>    My install is up-to-date with latest security updates (that's the first
> >>    thing I do anytime I start my laptop).
> >>    I'm using Gnome.
> >>    Steps to reproduce on my laptop:
> >>     - activate the wifi with upper right screen controls
> >>     - repeatedly click on "Activities" in the upper left corner to show the
> >>    quick launch bar and click below to hide it. After a few seconds after the
> >>    network connection is set, the click on Activities no longer works. After
> >>    one minute, it starts working again.
> >>
> >>    Note that if I don't activate the wifi, then I can repeatedly click on
> >>    "Activities" without triggering the bug.
> >
> >This sounds like some sort of network-related time out.  Do you have
> >LDAP authentication, Kerberos, Samba, NFS automounts, etc.?  Does it
> <always happen regardless of what wireless network you connect to?  Could
> <it be the DNS configuration, whether that is the configuration pushed by
> >the network's DHCP server or an override configuration you are using?
>
> Hello Roberto,
>
> Thanks for the response.
>
> I have nothing of LDAP authentication, Kerberos, Samba, NFS, etc.
>
> I'm using my laptop only at home with the box of my ISP.
>
> I changed nothing with the box for years.
> When I fresh installed Debian Stretch, the only thing I did was choosing the wifi of my box with gnome interface and entering the password for it.
>
> Hence I assume it is using DHCP.
>
> I have no override configuration or anything complicated.
>
> Basically, I just use Firefox with my laptop. Sometimes I code C or PHP stuff or compile latex file but that's it.
>
> I will take my laptop at work, tomorrow, and try to connect to the wifi network there if you think it might help finding the cause.
>
> Thanks, best regards,
>
>    Laurent
>
>
Hello Roberto,

As you suggested, I took my laptop at work and tested with the wifi there.
I reproduced the bug also there.
I don't know if I can reproduce it with any wifi network but at least it is
not particular to my home network only.

Let me know what I can do next to find the cause of the bug.

Thanks, best regards,
    Laurent

[toc] | [next] | [standalone]


#188862

Fromdeloptes <deloptes@gmail.com>
Date2017-11-10 21:10 +0100
Message-ID<uKnMK-7Yj-15@gated-at.bofh.it>
In reply to#188858
Laurent Lyaudet wrote:

>> >> My install is up-to-date with latest security updates (that's the
>> >> first thing I do anytime I start my laptop).

There is a rule: "never touch a running system" which means if something
works let it work. through your process you are exposed to bugs without a
way back. this is just an advise to review the process

I don't use Gnome, because gtk with the concept behind caused a lot of
trouble long time ago and could not convince me that it will ever get
better so I can't help much. But ... there should be logging facility and
you need perhaps to enable something somewhere to see where it is coming
from or what is happening when the problem appears.

I usually look first in ~/.xsession-errors

someone else perhaps could help on where and how to debug gtk/gnome

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


#188911

FromLaurent Lyaudet <laurent.lyaudet@gmail.com>
Date2017-11-12 17:50 +0100
Message-ID<uL3Ch-2D9-3@gated-at.bofh.it>
In reply to#188858

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

Hello,

Thanks for your feedback.

Laurent Lyaudet wrote:

>> >> My install is up-to-date with latest security updates (that's the
>> >> first thing I do anytime I start my laptop).
deloptes wrote:
> There is a rule: "never touch a running system" which means if something
> works let it work. through your process you are exposed to bugs without a
> way back. this is just an advise to review the process

I think this is a very bad advice.
You should always be uptodate with security updates since there is
plenty of people ready to exploit already corrected security issues.

The people that correct these security issues do this hard work for a reason.

Never let your system stay insecure or say people to do so, unless you
want them to be screwed by perverts behind a computer.

> I don't use Gnome, because gtk with the concept behind caused a lot of
> trouble long time ago and could not convince me that it will ever get
> better so I can't help much. But ... there should be logging facility and
> you need perhaps to enable something somewhere to see where it is coming
> from or what is happening when the problem appears.

> I usually look first in ~/.xsession-errors

> someone else perhaps could help on where and how to debug gtk/gnome

Thanks for this indication. I found no such file with :

find / -name 'xsession*'

I will google for gnome error logging.


Best regards,

   Laurent Lyaudet



2017-11-10 21:47 GMT+01:00 Laurent Lyaudet <laurent.lyaudet@gmail.com>:

> Hi,
>
> Thanks for the response.
> I did not install any gnome extension or tweaking tools for gnome.
> So I'm afraid the cause is somewhere else.
> Note that if it's a malware, I'm glad you cannot reproduce the bug ;)
>
> Best regards,
>    Laurent Lyaudet
>
>
>
>
> 2017-11-10 21:22 GMT+01:00 RRRoy BBBean <rrroybbbean@gmail.com>:
>
>> On Fri, 2017-11-10 at 20:26 +0100, Laurent Lyaudet wrote:
>> > Hello Roberto,
>> > As you suggested, I took my laptop at work and tested with the wifi
>> > there.
>> > I reproduced the bug also there.
>> > I don't know if I can reproduce it with any wifi network but at least
>> > it is
>> > not particular to my home network only.
>> >
>> I tried this on my computer. I cannot reproduce the error.
>>
>> Last year I was working a lot with Gnome3 on Fedora24. I was installing
>> and trying out lots of cool Gnome Shell Extension. After a few days, I
>> noticed that various Gnome-related things started acting crazy or not
>> working at all. I deinstalled most of these additional extensions, and
>> now (on both Fedora and Debian) I stick with the default Gnome Shell
>> Extensions plus a small number of additional extensions that I can't
>> live without.
>>
>> Let me suggest that if you have installed additional Gnome Shell
>> Extensions on top of the defaults, you remove them and see if the
>> problem goes away. You will probably need to restart your laptop to be
>> sure you get a clean load of Gnome.
>>
>>
>

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


#188913

Fromdeloptes <deloptes@gmail.com>
Date2017-11-12 18:10 +0100
Message-ID<uL3VD-2Z5-9@gated-at.bofh.it>
In reply to#188911
Laurent Lyaudet wrote:

> I think this is a very bad advice.

No it is a wise advise. When you make a change and if you want to be sure it
works - make it on a test system. Otherwise you see what happens!

> You should always be uptodate with security updates since there is
> plenty of people ready to exploit already corrected security issues.
> 

true

> The people that correct these security issues do this hard work for a
> reason.
> 

true, but often the introduce regressions ;-) they are also humans

> Never let your system stay insecure or say people to do so, unless you
> want them to be screwed by perverts behind a computer.

what means stay insecure? don't use internet and its done :)

its always money / time / risk ratio 

regards

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


#188914

FromCindy-Sue Causey <butterflybytes@gmail.com>
Date2017-11-12 18:30 +0100
Message-ID<uL4f0-36J-11@gated-at.bofh.it>
In reply to#188911
On 11/12/17, Laurent Lyaudet <laurent.lyaudet@gmail.com> wrote:
> deloptes wrote:
>> I don't use Gnome, because gtk with the concept behind caused a lot of
>> trouble long time ago and could not convince me that it will ever get
>> better so I can't help much. But ... there should be logging facility and
>> you need perhaps to enable something somewhere to see where it is coming
>> from or what is happening when the problem appears.
>
>> I usually look first in ~/.xsession-errors
>
>> someone else perhaps could help on where and how to debug gtk/gnome
>
> Thanks for this indication. I found no such file with :
>
> find / -name 'xsession*'
>
> I will google for gnome error logging.


Does "find" find hidden files without being specifically told how to
do so? The other thing is that maybe you've just been phenomenally
blessed to have no errors. That *could* happen.. :)

~/.xession-errors can be found manually via a text editor or file
manager. Either can be pointed to the /home/[username] ("~/")
directory. If hidden "dot files and folders" are not showing, it's
*almost* universal that a user can do a "CTRL+H" keyboard combination
from *almost* anywhere to alternately reveal and then re-hide hidden
files.

/var/log is another place for some log files. Maybe there's something
in /var/log/syslog (or one or another of its archived versions) that
could show something.

What I'm thinking is maybe there's a warning or error message at boot
that might indicate something's not loading or otherwise performing as
expected during the boot process. That would have a trickle down
effect into overall system operability.

And then again... maybe not. :)

But like in my case just now, I making sure I was referencing the
correct log file... and found mine has a warning about a power button
conflict of interest going on under the hood.. along with a bunch of
other interesting things I keep forgetting to go back and play with
for the purpose of learning more about Debian.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

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


#188915 — Hidden files [was: Reproducible bug]

From<tomas@tuxteam.de>
Date2017-11-12 18:50 +0100
SubjectHidden files [was: Reproducible bug]
Message-ID<uL4yl-3d7-5@gated-at.bofh.it>
In reply to#188914
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Nov 12, 2017 at 12:26:40PM -0500, Cindy-Sue Causey wrote:

[...]

> Does "find" find hidden files without being specifically told how to
> do so? The other thing is that maybe you've just been phenomenally
> blessed to have no errors. That *could* happen.. :)

The secret about hidden files is... that there are no hidden
files [1] :-)

There's just this convention that "ls" (and most GUI "file
managers" don't show files bearing a name which starts with
"." (dot). There's an option for "ls" to show those files
anyway ("-a", think "all"), and the GUIs typically call that
"show hidden files" (in some reminiscence of DOS hidden files,
which were something completely different!), thus causing
confusion.

GUIs have seldom qualms about causing confusion, which is
a pity, and the damage is kind of done now :-(

Typically, files and directories you don't want to "see always",
like "." (aka "self"), ".." (aka parent) and configuration
files and directories are named starting with a dot.

And yes, find does find those files by default.

[1] In Unix-like operating systems, that is.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAloIiZsACgkQBcgs9XrR2kZoCACeNJL374rGau2azu3c30Emam0t
J4AAnjvjCoJzD8qd6b45L3O36bAxwCDy
=Daeb
-----END PGP SIGNATURE-----

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


#188916

FromCurt <curty@free.fr>
Date2017-11-12 19:20 +0100
Message-ID<uL51n-3DU-3@gated-at.bofh.it>
In reply to#188914
On 2017-11-12, Cindy-Sue Causey <butterflybytes@gmail.com> wrote:
> On 11/12/17, Laurent Lyaudet <laurent.lyaudet@gmail.com> wrote:
>> deloptes wrote:
>>> I don't use Gnome, because gtk with the concept behind caused a lot of
>>> trouble long time ago and could not convince me that it will ever get
>>> better so I can't help much. But ... there should be logging facility and
>>> you need perhaps to enable something somewhere to see where it is coming
>>> from or what is happening when the problem appears.
>>
>>> I usually look first in ~/.xsession-errors
>>
>>> someone else perhaps could help on where and how to debug gtk/gnome
>>
>> Thanks for this indication. I found no such file with :
>>
>> find / -name 'xsession*'
>>
>> I will google for gnome error logging.
>
>
> Does "find" find hidden files without being specifically told how to
> do so? The other thing is that maybe you've just been phenomenally
> blessed to have no errors. That *could* happen.. :)

It seems the initial dot is part of the name. So his search syntax would
not find a dot file. If he had put a wildcard at both ends of the
string, but he didn't, and then he isn't looking in his home directory,
either, is he?

-- 
"The world is full of shipping clerks who have read the Harvard Classics."
— Charles Bukowski

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


#188922

FromLaurent Lyaudet <laurent.lyaudet@gmail.com>
Date2017-11-12 21:10 +0100
Message-ID<uL6JP-4Kq-1@gated-at.bofh.it>
In reply to#188911

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

Hello,

Well, find behavior and hidden files was not the intended topic of this
thread ;)
I do already know about Ctrl+H, ls -a, etc.
And indeed my find command is incorrect since I forgot the dot or some
wildcard at the beginning.
After correction, I can say there is no .xsession-errors file on my system.
The only matches were
/usr/share/xsessions
/etc/X11/Xsession.d/40x11-common_xsessionrc

So yes, it may be strange if usually there is plenty of X session errors.

After googling, I looked at /var/log/messages with a lot of, well, messages
that I didn't found interesting and related to my problem.
I also looked at /var/log/gdm3/ but it was empty.

Regarding the boot errors, I have plenty of them as with any laptop I've
seen running with Linux since laptops tend to have weird hardware.
However, despite the same boot errors since I installed Debian on this
laptop, the bug I'm talking in this thread was not present until a few
weeks ago.

I also forgot to say that soon after the bug started I found that hitting
the super/windows/apple key works despite the click not working.
And I already know some people out there will say "problem solved, he can
put up with the bug".

Best regards,
   Laurent Lyaudet


2017-11-12 17:32 GMT+01:00 Laurent Lyaudet <laurent.lyaudet@gmail.com>:

> Hello,
>
> Thanks for your feedback.
>
> Laurent Lyaudet wrote:
>
> >> >> My install is up-to-date with latest security updates (that's the
> >> >> first thing I do anytime I start my laptop).
> deloptes wrote:
> > There is a rule: "never touch a running system" which means if something
> > works let it work. through your process you are exposed to bugs without a
> > way back. this is just an advise to review the process
>
> I think this is a very bad advice.
> You should always be uptodate with security updates since there is plenty of people ready to exploit already corrected security issues.
>
> The people that correct these security issues do this hard work for a reason.
>
> Never let your system stay insecure or say people to do so, unless you want them to be screwed by perverts behind a computer.
>
> > I don't use Gnome, because gtk with the concept behind caused a lot of
> > trouble long time ago and could not convince me that it will ever get
> > better so I can't help much. But ... there should be logging facility and
> > you need perhaps to enable something somewhere to see where it is coming
> > from or what is happening when the problem appears.
>
> > I usually look first in ~/.xsession-errors
>
> > someone else perhaps could help on where and how to debug gtk/gnome
>
> Thanks for this indication. I found no such file with :
>
> find / -name 'xsession*'
>
> I will google for gnome error logging.
>
>
> Best regards,
>
>    Laurent Lyaudet
>
>
>
> 2017-11-10 21:47 GMT+01:00 Laurent Lyaudet <laurent.lyaudet@gmail.com>:
>
>> Hi,
>>
>> Thanks for the response.
>> I did not install any gnome extension or tweaking tools for gnome.
>> So I'm afraid the cause is somewhere else.
>> Note that if it's a malware, I'm glad you cannot reproduce the bug ;)
>>
>> Best regards,
>>    Laurent Lyaudet
>>
>>
>>
>>
>> 2017-11-10 21:22 GMT+01:00 RRRoy BBBean <rrroybbbean@gmail.com>:
>>
>>> On Fri, 2017-11-10 at 20:26 +0100, Laurent Lyaudet wrote:
>>> > Hello Roberto,
>>> > As you suggested, I took my laptop at work and tested with the wifi
>>> > there.
>>> > I reproduced the bug also there.
>>> > I don't know if I can reproduce it with any wifi network but at least
>>> > it is
>>> > not particular to my home network only.
>>> >
>>> I tried this on my computer. I cannot reproduce the error.
>>>
>>> Last year I was working a lot with Gnome3 on Fedora24. I was installing
>>> and trying out lots of cool Gnome Shell Extension. After a few days, I
>>> noticed that various Gnome-related things started acting crazy or not
>>> working at all. I deinstalled most of these additional extensions, and
>>> now (on both Fedora and Debian) I stick with the default Gnome Shell
>>> Extensions plus a small number of additional extensions that I can't
>>> live without.
>>>
>>> Let me suggest that if you have installed additional Gnome Shell
>>> Extensions on top of the defaults, you remove them and see if the
>>> problem goes away. You will probably need to restart your laptop to be
>>> sure you get a clean load of Gnome.
>>>
>>>
>>
>

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


#188969

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2017-11-14 03:50 +0100
Message-ID<uLzsu-5RZ-3@gated-at.bofh.it>
In reply to#188922
I'll have another go. This is getting tedious.

<debian-user@lists.debian.org>: host bendel.debian.org[82.195.75.100] said: 550
    5.7.1 <debian-user@lists.debian.org>: Recipient address rejected: Mail
    appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct
    HELO and DNS MX settings or to get removed from DNSBLs; please relay via
    your ISP (lionunicorn.co.uk) (in reply to RCPT TO command)



On Sun 12 Nov 2017 at 20:53:23 (+0100), Laurent Lyaudet wrote:
> Hello,
> 
> Well, find behavior and hidden files was not the intended topic of this
> thread ;)
> I do already know about Ctrl+H, ls -a, etc.
> And indeed my find command is incorrect since I forgot the dot or some
> wildcard at the beginning.
> After correction, I can say there is no .xsession-errors file on my system.
> The only matches were
> /usr/share/xsessions
> /etc/X11/Xsession.d/40x11-common_xsessionrc

There's nothing special about the filename .xsession-errors. On this
system, it's just the value of $ERRFILE, set in /etc/X11/Xsession.
But I don't run gnome, so I couldn't say what its startup files are
like. I can only assume that some sort of juggling goes on because
~/.xsession-errors belongs to the user who started the X server,
but (again I assume) a graphical system must start X before any user
has logged in through the (graphical) display manager.

So you might be better off using find to find files newer than,
say, 5 minutes old immediately after booting and logging in.

$ find ~ -mmin -5 -type f -print

> So yes, it may be strange if usually there is plenty of X session errors.
> 
> After googling, I looked at /var/log/messages with a lot of, well, messages
> that I didn't found interesting and related to my problem.
> I also looked at /var/log/gdm3/ but it was empty.
> 
> Regarding the boot errors, I have plenty of them as with any laptop I've
> seen running with Linux since laptops tend to have weird hardware.
> However, despite the same boot errors since I installed Debian on this
> laptop, the bug I'm talking in this thread was not present until a few
> weeks ago.

Someone mentioned network timeouts. Does this button/menu/whatever
do anything involving the network which could be stalled while
DHCP is doing its dirty work.

> I also forgot to say that soon after the bug started I found that hitting
> the super/windows/apple key works despite the click not working.
> And I already know some people out there will say "problem solved, he can
> put up with the bug".

Well that's at least a workaround, not a solution, assuming that what
"works" is the functionality you expected from clicking.

But if you want to chase down this bug, you might find a gnome list
more productive than this one, viz.

> > > someone else perhaps could help on where and how to debug gtk/gnome

Cheers,
David.

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


#188975

FromCurt <curty@free.fr>
Date2017-11-14 09:40 +0100
Message-ID<uLEVb-Z4-1@gated-at.bofh.it>
In reply to#188922
On 2017-11-12, Laurent Lyaudet <laurent.lyaudet@gmail.com> wrote:
>
> Hello,
>
> Well, find behavior and hidden files was not the intended topic of this
> thread ;)
> I do already know about Ctrl+H, ls -a, etc.
> And indeed my find command is incorrect since I forgot the dot or some
> wildcard at the beginning.
> After correction, I can say there is no .xsession-errors file on my system.
> The only matches were
> /usr/share/xsessions
> /etc/X11/Xsession.d/40x11-common_xsessionrc
>

I'm reading that there is now a log here (if you use GDM, it seems):

 ~/.cache/gdm/session.log

There's also the new-fangled journalctl interrogative method (I'm still
Wheezy--and whoozy--I'm uncertain how they work):

 journalctl -u session-${XDG_SESSION_ID}.scope

and I'm also reading gnome-shell will log errors "there" (but I cannot
test any systemd hypotheses).


-- 
"The world is full of shipping clerks who have read the Harvard Classics."
— Charles Bukowski

[toc] | [prev] | [standalone]


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


csiph-web