Re: [i3] Detecting screen locked

2015-05-01 Thread Jeff Abrahamson
Good idea, thanks, I'll bind my lock key to that.  I think I learned of
xautolock after learning that I could lock the screen by binding i3lock to
a key.

Jeff Abrahamson
+33 6 24 40 01 57
+44 7920 594 255<-- only if I'm in the UK

http://jeff.purple.com/
http://blog.purple.com/jeff/

On 1 May 2015 at 17:44, Serge van Ginderachter 
wrote:

>
> On 1 May 2015 at 17:40, Jeff Abrahamson  wrote:
>
>> I lock the screen from the keyboard.  That key is bound to i3lock --dpms
>> --inactivity-timeout 10 --color=220022 .
>>
>
>
> ​If you use xautolock, better trigger a lock through it then, I use the
> Pause button to lock it like this:
>
>bindsym Pause exec "xautolock -locknow"​
>
>
>


Re: [i3] Detecting screen locked

2015-05-01 Thread Serge van Ginderachter
On 1 May 2015 at 17:40, Jeff Abrahamson  wrote:

> I lock the screen from the keyboard.  That key is bound to i3lock --dpms
> --inactivity-timeout 10 --color=220022 .
>


​If you use xautolock, better trigger a lock through it then, I use the
Pause button to lock it like this:

   bindsym Pause exec "xautolock -locknow"​


Re: [i3] Detecting screen locked

2015-05-01 Thread Jeff Abrahamson
A bit more info.  It appears that the sequence of events may be the
following:

I lock the screen from the keyboard.  That key is bound to i3lock --dpms
--inactivity-timeout 10 --color=220022 .

A bit later, xautolock decides to lock the screen as well.  That command,
by chance, is not quite the same, which is how I identified the two
locks.  i3lock
--dpms --color=220022 --inactivity-timeout 10 --nofork

There is no good reason they are different, but they do both run
sometimes.  For some reason, the xautolock-launched version sometimes
neither asks for my password nor exits.  This doesn't happen every time,
most of the time, it all works correctly.


Jeff Abrahamson
+33 6 24 40 01 57
+44 7920 594 255<-- only if I'm in the UK

http://jeff.purple.com/
http://blog.purple.com/jeff/

On 17 April 2015 at 12:50, Michael Stapelberg  wrote:

> On Fri, Apr 17, 2015 at 3:00 AM, Jeff Abrahamson  wrote:
> > Thanks.  I understand (and a bit better, now) why strace/ptrace may have
> > problems with a program that calls setuid.  On the other hand, i3lock
> > doesn't have the setuid bit set, and the strace logs do not show an
> attempt
> > to call strace.
> >
> > [S-18]jeff@siegfried:~ $ stat /usr/bin/i3lock
> >   File: ‘/usr/bin/i3lock’
> >   Size: 31912   Blocks: 64 IO Block: 4096   regular file
> > Device: fc01h/64513dInode: 1575208 Links: 1
> > Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
> > Access: 2015-04-16 20:02:56.634223226 +0200
> > Modify: 2014-07-19 01:13:09.0 +0200
> > Change: 2015-03-04 15:18:43.959784604 +0100
> >  Birth: -
> > [S-18]jeff@siegfried:~ $ grep setuid /tmp/i3lock-log-1429256*
> > 1,[S-18] jeff@siegfried:~ $
> >
> > This said, if something PAM did when I logged in affects the behavior of
> > stracing i3lock, I do not think I will try to figure out what PAM has
> done.
> > ;-)  But I still find it odd that i3lock would interpret keystrokes
> > differently under strace or not based on what I know so far.
>
> It doesn’t. I’m saying the PAM stack (outside of i3’s code) likely
> requires setuid permission for some modules (most likely pam_unix).
>
> >
> > Well, I will debug what I can.  Maybe I will compile an i3lock with
> > scaffolding over the weekend to see what I can learn.
> >
> > Thanks again.
> >
> > Jeff Abrahamson
> > +33 6 24 40 01 57
> > +44 7920 594 255<-- only if I'm in the UK
> >
> > http://jeff.purple.com/
> > http://blog.purple.com/jeff/
> >
> > On 17 April 2015 at 11:47, Michael Stapelberg  wrote:
> >>
> >> See http://superuser.com/a/248127 for why setuid is ignored when
> >> running under strace.
> >>
> >> Given that you run i3lock on linux, it might be PAM which uses setuid
> >> in some of its modules.
> >>
> >> On Fri, Apr 17, 2015 at 1:20 AM, Jeff Abrahamson 
> wrote:
> >> > Interesting.  How does setuid have this effect on i3lock but only
> under
> >> > strace?
> >> >
> >> > Any idea where the setuid is coming from or how to find out?  The
> system
> >> > is
> >> > pretty vanilla ubuntu 14.10 (they have a good installer) aside from
> >> > running
> >> > i3 instead of gnome.
> >> >
> >> > The exec path that's visible once I'm logged in is lightdm -> lightdm
> >> > --sesion-child -> i3.  I see that i3 parents what is executed due to
> >> > .xsessionrc.
> >> >
> >> > I'll try to gather traces with -p, but this will depend on me thinking
> >> > to
> >> > trace i3lock from a vt before unlocking the screen.  My apologies in
> >> > advance
> >> > if I take a long time to catch the occasional errant process that way.
> >> >
> >> > And thanks for your ever prompt assistance and insights.
> >> >
> >> > Jeff Abrahamson
> >> > +33 6 24 40 01 57
> >> > +44 7920 594 255<-- only if I'm in the UK
> >> >
> >> > http://jeff.purple.com/
> >> > http://blog.purple.com/jeff/
> >> >
> >> > On 17 April 2015 at 10:09, Michael Stapelberg 
> wrote:
> >> >>
> >> >> Ugh, then you’re running it in a setuid setup. You’ll need to start
> >> >> i3lock
> >> >> and then attach strace afterwards using -p.
> >> >>
> >> >> On Fri, Apr 17, 2015 at 9:56 AM, Jeff Abrahamson 
> >> >> wrote:
> >> >>>
> >> >>> I invoke i3lock at the commandline thus:
> >> >>>
> >> >>> [S-18]jeff@siegfried:gtd $ strace -o/tmp/i3lock-log-$(date +%s) -f
> -s
> >> >>> 2048 -tt  i3lock --dpms --inactivity-timeout 10 --color=220022
> >> >>> [S-18]jeff@siegfried:gtd $
> >> >>>
> >> >>> and the result is that i3lock does not recognize my password.  It
> does
> >> >>> echo my typing, it just always says fail.  I switch to a vt, login,
> >> >>> and kill
> >> >>> it.
> >> >>>
> >> >>> Jeff Abrahamson
> >> >>> +33 6 24 40 01 57
> >> >>> +44 7920 594 255<-- only if I'm in the UK
> >> >>>
> >> >>> http://jeff.purple.com/
> >> >>> http://blog.purple.com/jeff/
> >> >>>
> >> >>> On 17 April 2015 at 09:39, Michael Stapelberg 
> >> >>> wrote:
> >> 
> >>  Yes, but also use -f (to follow child processes) and -s 2048 (to
> >>  increase the size of strings) and -tt (to get

Re: [i3] Detecting screen locked

2015-04-17 Thread Michael Stapelberg
On Fri, Apr 17, 2015 at 3:00 AM, Jeff Abrahamson  wrote:
> Thanks.  I understand (and a bit better, now) why strace/ptrace may have
> problems with a program that calls setuid.  On the other hand, i3lock
> doesn't have the setuid bit set, and the strace logs do not show an attempt
> to call strace.
>
> [S-18]jeff@siegfried:~ $ stat /usr/bin/i3lock
>   File: ‘/usr/bin/i3lock’
>   Size: 31912   Blocks: 64 IO Block: 4096   regular file
> Device: fc01h/64513dInode: 1575208 Links: 1
> Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
> Access: 2015-04-16 20:02:56.634223226 +0200
> Modify: 2014-07-19 01:13:09.0 +0200
> Change: 2015-03-04 15:18:43.959784604 +0100
>  Birth: -
> [S-18]jeff@siegfried:~ $ grep setuid /tmp/i3lock-log-1429256*
> 1,[S-18] jeff@siegfried:~ $
>
> This said, if something PAM did when I logged in affects the behavior of
> stracing i3lock, I do not think I will try to figure out what PAM has done.
> ;-)  But I still find it odd that i3lock would interpret keystrokes
> differently under strace or not based on what I know so far.

It doesn’t. I’m saying the PAM stack (outside of i3’s code) likely
requires setuid permission for some modules (most likely pam_unix).

>
> Well, I will debug what I can.  Maybe I will compile an i3lock with
> scaffolding over the weekend to see what I can learn.
>
> Thanks again.
>
> Jeff Abrahamson
> +33 6 24 40 01 57
> +44 7920 594 255<-- only if I'm in the UK
>
> http://jeff.purple.com/
> http://blog.purple.com/jeff/
>
> On 17 April 2015 at 11:47, Michael Stapelberg  wrote:
>>
>> See http://superuser.com/a/248127 for why setuid is ignored when
>> running under strace.
>>
>> Given that you run i3lock on linux, it might be PAM which uses setuid
>> in some of its modules.
>>
>> On Fri, Apr 17, 2015 at 1:20 AM, Jeff Abrahamson  wrote:
>> > Interesting.  How does setuid have this effect on i3lock but only under
>> > strace?
>> >
>> > Any idea where the setuid is coming from or how to find out?  The system
>> > is
>> > pretty vanilla ubuntu 14.10 (they have a good installer) aside from
>> > running
>> > i3 instead of gnome.
>> >
>> > The exec path that's visible once I'm logged in is lightdm -> lightdm
>> > --sesion-child -> i3.  I see that i3 parents what is executed due to
>> > .xsessionrc.
>> >
>> > I'll try to gather traces with -p, but this will depend on me thinking
>> > to
>> > trace i3lock from a vt before unlocking the screen.  My apologies in
>> > advance
>> > if I take a long time to catch the occasional errant process that way.
>> >
>> > And thanks for your ever prompt assistance and insights.
>> >
>> > Jeff Abrahamson
>> > +33 6 24 40 01 57
>> > +44 7920 594 255<-- only if I'm in the UK
>> >
>> > http://jeff.purple.com/
>> > http://blog.purple.com/jeff/
>> >
>> > On 17 April 2015 at 10:09, Michael Stapelberg  wrote:
>> >>
>> >> Ugh, then you’re running it in a setuid setup. You’ll need to start
>> >> i3lock
>> >> and then attach strace afterwards using -p.
>> >>
>> >> On Fri, Apr 17, 2015 at 9:56 AM, Jeff Abrahamson 
>> >> wrote:
>> >>>
>> >>> I invoke i3lock at the commandline thus:
>> >>>
>> >>> [S-18]jeff@siegfried:gtd $ strace -o/tmp/i3lock-log-$(date +%s) -f -s
>> >>> 2048 -tt  i3lock --dpms --inactivity-timeout 10 --color=220022
>> >>> [S-18]jeff@siegfried:gtd $
>> >>>
>> >>> and the result is that i3lock does not recognize my password.  It does
>> >>> echo my typing, it just always says fail.  I switch to a vt, login,
>> >>> and kill
>> >>> it.
>> >>>
>> >>> Jeff Abrahamson
>> >>> +33 6 24 40 01 57
>> >>> +44 7920 594 255<-- only if I'm in the UK
>> >>>
>> >>> http://jeff.purple.com/
>> >>> http://blog.purple.com/jeff/
>> >>>
>> >>> On 17 April 2015 at 09:39, Michael Stapelberg 
>> >>> wrote:
>> 
>>  Yes, but also use -f (to follow child processes) and -s 2048 (to
>>  increase the size of strings) and -tt (to get timing).
>> 
>>  On Fri, Apr 17, 2015 at 9:23 AM, Jeff Abrahamson 
>>  wrote:
>> >
>> > Sure thing.
>> >
>> > Just to be clear, do you mean that instead of launching "i3lock .."
>> > I
>> > substitute "strace -o/tmp/i3lock-log-$(date +%s) i3lock ..."?
>> >
>> > Jeff Abrahamson
>> > +33 6 24 40 01 57
>> > +44 7920 594 255<-- only if I'm in the UK
>> >
>> > http://jeff.purple.com/
>> > http://blog.purple.com/jeff/
>> >
>> > On 17 April 2015 at 09:19, Michael Stapelberg 
>> > wrote:
>> >>
>> >> i3lock shouldn’t hang around. Can you start stracing all your
>> >> i3lock
>> >> instances automatically and provide the corresponding strace output
>> >> of a
>> >> hung instance in a bugreport?
>> >>
>> >> On Fri, Apr 17, 2015 at 9:04 AM, Jeff Abrahamson 
>> >> wrote:
>> >>>
>> >>> I have a maintenance function that ought not bother spinning the
>> >>> CPU
>> >>> if the screen is locked.  It checks this thus:
>> >>>
>> >>> if pidof i3lo

Re: [i3] Detecting screen locked

2015-04-17 Thread Jeff Abrahamson
Thanks.  I understand (and a bit better, now) why strace/ptrace may have
problems with a program that calls setuid.  On the other hand, i3lock
doesn't have the setuid bit set, and the strace logs do not show an attempt
to call strace.

[S-18]jeff@siegfried:~ $ stat /usr/bin/i3lock
  File: ‘/usr/bin/i3lock’
  Size: 31912   Blocks: 64 IO Block: 4096   regular file
Device: fc01h/64513dInode: 1575208 Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2015-04-16 20:02:56.634223226 +0200
Modify: 2014-07-19 01:13:09.0 +0200
Change: 2015-03-04 15:18:43.959784604 +0100
 Birth: -
[S-18]jeff@siegfried:~ $ grep setuid /tmp/i3lock-log-1429256*
1,[S-18] jeff@siegfried:~ $

This said, if something PAM did when I logged in affects the behavior of
stracing i3lock, I do not think I will try to figure out what PAM has done.
;-)  But I still find it odd that i3lock would interpret keystrokes
differently under strace or not based on what I know so far.

Well, I will debug what I can.  Maybe I will compile an i3lock with
scaffolding over the weekend to see what I can learn.

Thanks again.

Jeff Abrahamson
+33 6 24 40 01 57
+44 7920 594 255<-- only if I'm in the UK

http://jeff.purple.com/
http://blog.purple.com/jeff/

On 17 April 2015 at 11:47, Michael Stapelberg  wrote:

> See http://superuser.com/a/248127 for why setuid is ignored when
> running under strace.
>
> Given that you run i3lock on linux, it might be PAM which uses setuid
> in some of its modules.
>
> On Fri, Apr 17, 2015 at 1:20 AM, Jeff Abrahamson  wrote:
> > Interesting.  How does setuid have this effect on i3lock but only under
> > strace?
> >
> > Any idea where the setuid is coming from or how to find out?  The system
> is
> > pretty vanilla ubuntu 14.10 (they have a good installer) aside from
> running
> > i3 instead of gnome.
> >
> > The exec path that's visible once I'm logged in is lightdm -> lightdm
> > --sesion-child -> i3.  I see that i3 parents what is executed due to
> > .xsessionrc.
> >
> > I'll try to gather traces with -p, but this will depend on me thinking to
> > trace i3lock from a vt before unlocking the screen.  My apologies in
> advance
> > if I take a long time to catch the occasional errant process that way.
> >
> > And thanks for your ever prompt assistance and insights.
> >
> > Jeff Abrahamson
> > +33 6 24 40 01 57
> > +44 7920 594 255<-- only if I'm in the UK
> >
> > http://jeff.purple.com/
> > http://blog.purple.com/jeff/
> >
> > On 17 April 2015 at 10:09, Michael Stapelberg  wrote:
> >>
> >> Ugh, then you’re running it in a setuid setup. You’ll need to start
> i3lock
> >> and then attach strace afterwards using -p.
> >>
> >> On Fri, Apr 17, 2015 at 9:56 AM, Jeff Abrahamson 
> wrote:
> >>>
> >>> I invoke i3lock at the commandline thus:
> >>>
> >>> [S-18]jeff@siegfried:gtd $ strace -o/tmp/i3lock-log-$(date +%s) -f -s
> >>> 2048 -tt  i3lock --dpms --inactivity-timeout 10 --color=220022
> >>> [S-18]jeff@siegfried:gtd $
> >>>
> >>> and the result is that i3lock does not recognize my password.  It does
> >>> echo my typing, it just always says fail.  I switch to a vt, login,
> and kill
> >>> it.
> >>>
> >>> Jeff Abrahamson
> >>> +33 6 24 40 01 57
> >>> +44 7920 594 255<-- only if I'm in the UK
> >>>
> >>> http://jeff.purple.com/
> >>> http://blog.purple.com/jeff/
> >>>
> >>> On 17 April 2015 at 09:39, Michael Stapelberg 
> wrote:
> 
>  Yes, but also use -f (to follow child processes) and -s 2048 (to
>  increase the size of strings) and -tt (to get timing).
> 
>  On Fri, Apr 17, 2015 at 9:23 AM, Jeff Abrahamson 
>  wrote:
> >
> > Sure thing.
> >
> > Just to be clear, do you mean that instead of launching "i3lock .." I
> > substitute "strace -o/tmp/i3lock-log-$(date +%s) i3lock ..."?
> >
> > Jeff Abrahamson
> > +33 6 24 40 01 57
> > +44 7920 594 255<-- only if I'm in the UK
> >
> > http://jeff.purple.com/
> > http://blog.purple.com/jeff/
> >
> > On 17 April 2015 at 09:19, Michael Stapelberg 
> wrote:
> >>
> >> i3lock shouldn’t hang around. Can you start stracing all your i3lock
> >> instances automatically and provide the corresponding strace output
> of a
> >> hung instance in a bugreport?
> >>
> >> On Fri, Apr 17, 2015 at 9:04 AM, Jeff Abrahamson 
> >> wrote:
> >>>
> >>> I have a maintenance function that ought not bother spinning the
> CPU
> >>> if the screen is locked.  It checks this thus:
> >>>
> >>> if pidof i3lock >/dev/null; then
> >>> ...
> >>>
> >>> This is i3-specific, which is sad, but not a huge problem.  What
> is a
> >>> problem is that i3lock sometimes hangs around even though I think
> it should
> >>> exit on unlock.  And, indeed, most of the time it does exit on
> unlock.  Once
> >>> in a while, I find I have one or even several i3lock processes
> hanging
> >>> around.
> >>>
> >>

Re: [i3] Detecting screen locked

2015-04-17 Thread Michael Stapelberg
See http://superuser.com/a/248127 for why setuid is ignored when
running under strace.

Given that you run i3lock on linux, it might be PAM which uses setuid
in some of its modules.

On Fri, Apr 17, 2015 at 1:20 AM, Jeff Abrahamson  wrote:
> Interesting.  How does setuid have this effect on i3lock but only under
> strace?
>
> Any idea where the setuid is coming from or how to find out?  The system is
> pretty vanilla ubuntu 14.10 (they have a good installer) aside from running
> i3 instead of gnome.
>
> The exec path that's visible once I'm logged in is lightdm -> lightdm
> --sesion-child -> i3.  I see that i3 parents what is executed due to
> .xsessionrc.
>
> I'll try to gather traces with -p, but this will depend on me thinking to
> trace i3lock from a vt before unlocking the screen.  My apologies in advance
> if I take a long time to catch the occasional errant process that way.
>
> And thanks for your ever prompt assistance and insights.
>
> Jeff Abrahamson
> +33 6 24 40 01 57
> +44 7920 594 255<-- only if I'm in the UK
>
> http://jeff.purple.com/
> http://blog.purple.com/jeff/
>
> On 17 April 2015 at 10:09, Michael Stapelberg  wrote:
>>
>> Ugh, then you’re running it in a setuid setup. You’ll need to start i3lock
>> and then attach strace afterwards using -p.
>>
>> On Fri, Apr 17, 2015 at 9:56 AM, Jeff Abrahamson  wrote:
>>>
>>> I invoke i3lock at the commandline thus:
>>>
>>> [S-18]jeff@siegfried:gtd $ strace -o/tmp/i3lock-log-$(date +%s) -f -s
>>> 2048 -tt  i3lock --dpms --inactivity-timeout 10 --color=220022
>>> [S-18]jeff@siegfried:gtd $
>>>
>>> and the result is that i3lock does not recognize my password.  It does
>>> echo my typing, it just always says fail.  I switch to a vt, login, and kill
>>> it.
>>>
>>> Jeff Abrahamson
>>> +33 6 24 40 01 57
>>> +44 7920 594 255<-- only if I'm in the UK
>>>
>>> http://jeff.purple.com/
>>> http://blog.purple.com/jeff/
>>>
>>> On 17 April 2015 at 09:39, Michael Stapelberg  wrote:

 Yes, but also use -f (to follow child processes) and -s 2048 (to
 increase the size of strings) and -tt (to get timing).

 On Fri, Apr 17, 2015 at 9:23 AM, Jeff Abrahamson 
 wrote:
>
> Sure thing.
>
> Just to be clear, do you mean that instead of launching "i3lock .." I
> substitute "strace -o/tmp/i3lock-log-$(date +%s) i3lock ..."?
>
> Jeff Abrahamson
> +33 6 24 40 01 57
> +44 7920 594 255<-- only if I'm in the UK
>
> http://jeff.purple.com/
> http://blog.purple.com/jeff/
>
> On 17 April 2015 at 09:19, Michael Stapelberg  wrote:
>>
>> i3lock shouldn’t hang around. Can you start stracing all your i3lock
>> instances automatically and provide the corresponding strace output of a
>> hung instance in a bugreport?
>>
>> On Fri, Apr 17, 2015 at 9:04 AM, Jeff Abrahamson 
>> wrote:
>>>
>>> I have a maintenance function that ought not bother spinning the CPU
>>> if the screen is locked.  It checks this thus:
>>>
>>> if pidof i3lock >/dev/null; then
>>> ...
>>>
>>> This is i3-specific, which is sad, but not a huge problem.  What is a
>>> problem is that i3lock sometimes hangs around even though I think it 
>>> should
>>> exit on unlock.  And, indeed, most of the time it does exit on unlock.  
>>> Once
>>> in a while, I find I have one or even several i3lock processes hanging
>>> around.
>>>
>>> I either lock my screen explicitly
>>>
>>> bindsym $mod+Control+L exec i3lock --dpms --inactivity-timeout 10
>>> --color=220022
>>>
>>> or else it's done by inactivity
>>>
>>> xautolock -detectsleep \
>>> -time 3 -locker "i3lock --dpms --color=220022
>>> --inactivity-timeout 10 --nofork"
>>>
>>> This question thus has two parts:
>>>
>>> 1. Am I doing something wrong that I sometimes have multiple i3lock
>>> instances?
>>> 2. Is there a better way to detect screen lock than pidof i3lock?
>>>
>>> Jeff Abrahamson
>>> +33 6 24 40 01 57
>>> +44 7920 594 255<-- only if I'm in the UK
>>>
>>> http://jeff.purple.com/
>>> http://blog.purple.com/jeff/
>>
>>
>>
>>
>> --
>> Best regards,
>> Michael
>
>



 --
 Best regards,
 Michael
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Michael
>
>



-- 
Best regards,
Michael


Re: [i3] Detecting screen locked

2015-04-17 Thread Jeff Abrahamson
Interesting.  How does setuid have this effect on i3lock but only under
strace?

Any idea where the setuid is coming from or how to find out?  The system is
pretty vanilla ubuntu 14.10 (they have a good installer) aside from running
i3 instead of gnome.

The exec path that's visible once I'm logged in is lightdm -> lightdm
--sesion-child -> i3.  I see that i3 parents what is executed due to
.xsessionrc.

I'll try to gather traces with -p, but this will depend on me thinking to
trace i3lock from a vt before unlocking the screen.  My apologies in
advance if I take a long time to catch the occasional errant process that
way.

And thanks for your ever prompt assistance and insights.

Jeff Abrahamson
+33 6 24 40 01 57
+44 7920 594 255<-- only if I'm in the UK

http://jeff.purple.com/
http://blog.purple.com/jeff/

On 17 April 2015 at 10:09, Michael Stapelberg  wrote:

> Ugh, then you’re running it in a setuid setup. You’ll need to start i3lock
> and then attach strace afterwards using -p.
>
> On Fri, Apr 17, 2015 at 9:56 AM, Jeff Abrahamson  wrote:
>
>> I invoke i3lock at the commandline thus:
>>
>> [S-18]jeff@siegfried:gtd $ strace -o/tmp/i3lock-log-$(date +%s) -f -s
>> 2048 -tt  i3lock --dpms --inactivity-timeout 10 --color=220022
>> [S-18]jeff@siegfried:gtd $
>>
>> and the result is that i3lock does not recognize my password.  It does
>> echo my typing, it just always says fail.  I switch to a vt, login, and
>> kill it.
>>
>> Jeff Abrahamson
>> +33 6 24 40 01 57
>> +44 7920 594 255<-- only if I'm in the UK
>>
>> http://jeff.purple.com/
>> http://blog.purple.com/jeff/
>>
>> On 17 April 2015 at 09:39, Michael Stapelberg  wrote:
>>
>>> Yes, but also use -f (to follow child processes) and -s 2048 (to
>>> increase the size of strings) and -tt (to get timing).
>>>
>>> On Fri, Apr 17, 2015 at 9:23 AM, Jeff Abrahamson 
>>> wrote:
>>>
 Sure thing.

 Just to be clear, do you mean that instead of launching "i3lock .." I
 substitute "strace -o/tmp/i3lock-log-$(date +%s) i3lock ..."?

 Jeff Abrahamson
 +33 6 24 40 01 57
 +44 7920 594 255<-- only if I'm in the UK

 http://jeff.purple.com/
 http://blog.purple.com/jeff/

 On 17 April 2015 at 09:19, Michael Stapelberg  wrote:

> i3lock shouldn’t hang around. Can you start stracing all your i3lock
> instances automatically and provide the corresponding strace output of a
> hung instance in a bugreport?
>
> On Fri, Apr 17, 2015 at 9:04 AM, Jeff Abrahamson 
> wrote:
>
>> I have a maintenance function that ought not bother spinning the CPU
>> if the screen is locked.  It checks this thus:
>>
>> if pidof i3lock >/dev/null; then
>> ...
>>
>> This is i3-specific, which is sad, but not a huge problem.  What is a
>> problem is that i3lock sometimes hangs around even though I think it 
>> should
>> exit on unlock.  And, indeed, most of the time it does exit on unlock.
>> Once in a while, I find I have one or even several i3lock processes 
>> hanging
>> around.
>>
>> I either lock my screen explicitly
>>
>> bindsym $mod+Control+L exec i3lock --dpms --inactivity-timeout 10
>> --color=220022
>>
>> or else it's done by inactivity
>>
>> xautolock -detectsleep \
>> -time 3 -locker "i3lock --dpms --color=220022
>> --inactivity-timeout 10 --nofork"
>>
>> This question thus has two parts:
>>
>> 1. Am I doing something wrong that I sometimes have multiple i3lock
>> instances?
>> 2. Is there a better way to detect screen lock than pidof i3lock?
>>
>> Jeff Abrahamson
>> +33 6 24 40 01 57
>> +44 7920 594 255<-- only if I'm in the UK
>>
>> http://jeff.purple.com/
>> http://blog.purple.com/jeff/
>>
>
>
>
> --
> Best regards,
> Michael
>


>>>
>>>
>>> --
>>> Best regards,
>>> Michael
>>>
>>
>>
>
>
> --
> Best regards,
> Michael
>


Re: [i3] Detecting screen locked

2015-04-17 Thread Michael Stapelberg
Ugh, then you’re running it in a setuid setup. You’ll need to start i3lock
and then attach strace afterwards using -p.

On Fri, Apr 17, 2015 at 9:56 AM, Jeff Abrahamson  wrote:

> I invoke i3lock at the commandline thus:
>
> [S-18]jeff@siegfried:gtd $ strace -o/tmp/i3lock-log-$(date +%s) -f -s
> 2048 -tt  i3lock --dpms --inactivity-timeout 10 --color=220022
> [S-18]jeff@siegfried:gtd $
>
> and the result is that i3lock does not recognize my password.  It does
> echo my typing, it just always says fail.  I switch to a vt, login, and
> kill it.
>
> Jeff Abrahamson
> +33 6 24 40 01 57
> +44 7920 594 255<-- only if I'm in the UK
>
> http://jeff.purple.com/
> http://blog.purple.com/jeff/
>
> On 17 April 2015 at 09:39, Michael Stapelberg  wrote:
>
>> Yes, but also use -f (to follow child processes) and -s 2048 (to increase
>> the size of strings) and -tt (to get timing).
>>
>> On Fri, Apr 17, 2015 at 9:23 AM, Jeff Abrahamson  wrote:
>>
>>> Sure thing.
>>>
>>> Just to be clear, do you mean that instead of launching "i3lock .." I
>>> substitute "strace -o/tmp/i3lock-log-$(date +%s) i3lock ..."?
>>>
>>> Jeff Abrahamson
>>> +33 6 24 40 01 57
>>> +44 7920 594 255<-- only if I'm in the UK
>>>
>>> http://jeff.purple.com/
>>> http://blog.purple.com/jeff/
>>>
>>> On 17 April 2015 at 09:19, Michael Stapelberg  wrote:
>>>
 i3lock shouldn’t hang around. Can you start stracing all your i3lock
 instances automatically and provide the corresponding strace output of a
 hung instance in a bugreport?

 On Fri, Apr 17, 2015 at 9:04 AM, Jeff Abrahamson 
 wrote:

> I have a maintenance function that ought not bother spinning the CPU
> if the screen is locked.  It checks this thus:
>
> if pidof i3lock >/dev/null; then
> ...
>
> This is i3-specific, which is sad, but not a huge problem.  What is a
> problem is that i3lock sometimes hangs around even though I think it 
> should
> exit on unlock.  And, indeed, most of the time it does exit on unlock.
> Once in a while, I find I have one or even several i3lock processes 
> hanging
> around.
>
> I either lock my screen explicitly
>
> bindsym $mod+Control+L exec i3lock --dpms --inactivity-timeout 10
> --color=220022
>
> or else it's done by inactivity
>
> xautolock -detectsleep \
> -time 3 -locker "i3lock --dpms --color=220022 --inactivity-timeout
> 10 --nofork"
>
> This question thus has two parts:
>
> 1. Am I doing something wrong that I sometimes have multiple i3lock
> instances?
> 2. Is there a better way to detect screen lock than pidof i3lock?
>
> Jeff Abrahamson
> +33 6 24 40 01 57
> +44 7920 594 255<-- only if I'm in the UK
>
> http://jeff.purple.com/
> http://blog.purple.com/jeff/
>



 --
 Best regards,
 Michael

>>>
>>>
>>
>>
>> --
>> Best regards,
>> Michael
>>
>
>


-- 
Best regards,
Michael


Re: [i3] Detecting screen locked

2015-04-17 Thread Jeff Abrahamson
I invoke i3lock at the commandline thus:

[S-18]jeff@siegfried:gtd $ strace -o/tmp/i3lock-log-$(date +%s) -f -s 2048
-tt  i3lock --dpms --inactivity-timeout 10 --color=220022
[S-18]jeff@siegfried:gtd $

and the result is that i3lock does not recognize my password.  It does echo
my typing, it just always says fail.  I switch to a vt, login, and kill it.

Jeff Abrahamson
+33 6 24 40 01 57
+44 7920 594 255<-- only if I'm in the UK

http://jeff.purple.com/
http://blog.purple.com/jeff/

On 17 April 2015 at 09:39, Michael Stapelberg  wrote:

> Yes, but also use -f (to follow child processes) and -s 2048 (to increase
> the size of strings) and -tt (to get timing).
>
> On Fri, Apr 17, 2015 at 9:23 AM, Jeff Abrahamson  wrote:
>
>> Sure thing.
>>
>> Just to be clear, do you mean that instead of launching "i3lock .." I
>> substitute "strace -o/tmp/i3lock-log-$(date +%s) i3lock ..."?
>>
>> Jeff Abrahamson
>> +33 6 24 40 01 57
>> +44 7920 594 255<-- only if I'm in the UK
>>
>> http://jeff.purple.com/
>> http://blog.purple.com/jeff/
>>
>> On 17 April 2015 at 09:19, Michael Stapelberg  wrote:
>>
>>> i3lock shouldn’t hang around. Can you start stracing all your i3lock
>>> instances automatically and provide the corresponding strace output of a
>>> hung instance in a bugreport?
>>>
>>> On Fri, Apr 17, 2015 at 9:04 AM, Jeff Abrahamson 
>>> wrote:
>>>
 I have a maintenance function that ought not bother spinning the CPU if
 the screen is locked.  It checks this thus:

 if pidof i3lock >/dev/null; then
 ...

 This is i3-specific, which is sad, but not a huge problem.  What is a
 problem is that i3lock sometimes hangs around even though I think it should
 exit on unlock.  And, indeed, most of the time it does exit on unlock.
 Once in a while, I find I have one or even several i3lock processes hanging
 around.

 I either lock my screen explicitly

 bindsym $mod+Control+L exec i3lock --dpms --inactivity-timeout 10
 --color=220022

 or else it's done by inactivity

 xautolock -detectsleep \
 -time 3 -locker "i3lock --dpms --color=220022 --inactivity-timeout
 10 --nofork"

 This question thus has two parts:

 1. Am I doing something wrong that I sometimes have multiple i3lock
 instances?
 2. Is there a better way to detect screen lock than pidof i3lock?

 Jeff Abrahamson
 +33 6 24 40 01 57
 +44 7920 594 255<-- only if I'm in the UK

 http://jeff.purple.com/
 http://blog.purple.com/jeff/

>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Michael
>>>
>>
>>
>
>
> --
> Best regards,
> Michael
>


Re: [i3] Detecting screen locked

2015-04-17 Thread Michael Stapelberg
Yes, but also use -f (to follow child processes) and -s 2048 (to increase
the size of strings) and -tt (to get timing).

On Fri, Apr 17, 2015 at 9:23 AM, Jeff Abrahamson  wrote:

> Sure thing.
>
> Just to be clear, do you mean that instead of launching "i3lock .." I
> substitute "strace -o/tmp/i3lock-log-$(date +%s) i3lock ..."?
>
> Jeff Abrahamson
> +33 6 24 40 01 57
> +44 7920 594 255<-- only if I'm in the UK
>
> http://jeff.purple.com/
> http://blog.purple.com/jeff/
>
> On 17 April 2015 at 09:19, Michael Stapelberg  wrote:
>
>> i3lock shouldn’t hang around. Can you start stracing all your i3lock
>> instances automatically and provide the corresponding strace output of a
>> hung instance in a bugreport?
>>
>> On Fri, Apr 17, 2015 at 9:04 AM, Jeff Abrahamson  wrote:
>>
>>> I have a maintenance function that ought not bother spinning the CPU if
>>> the screen is locked.  It checks this thus:
>>>
>>> if pidof i3lock >/dev/null; then
>>> ...
>>>
>>> This is i3-specific, which is sad, but not a huge problem.  What is a
>>> problem is that i3lock sometimes hangs around even though I think it should
>>> exit on unlock.  And, indeed, most of the time it does exit on unlock.
>>> Once in a while, I find I have one or even several i3lock processes hanging
>>> around.
>>>
>>> I either lock my screen explicitly
>>>
>>> bindsym $mod+Control+L exec i3lock --dpms --inactivity-timeout 10
>>> --color=220022
>>>
>>> or else it's done by inactivity
>>>
>>> xautolock -detectsleep \
>>> -time 3 -locker "i3lock --dpms --color=220022 --inactivity-timeout
>>> 10 --nofork"
>>>
>>> This question thus has two parts:
>>>
>>> 1. Am I doing something wrong that I sometimes have multiple i3lock
>>> instances?
>>> 2. Is there a better way to detect screen lock than pidof i3lock?
>>>
>>> Jeff Abrahamson
>>> +33 6 24 40 01 57
>>> +44 7920 594 255<-- only if I'm in the UK
>>>
>>> http://jeff.purple.com/
>>> http://blog.purple.com/jeff/
>>>
>>
>>
>>
>> --
>> Best regards,
>> Michael
>>
>
>


-- 
Best regards,
Michael


Re: [i3] Detecting screen locked

2015-04-17 Thread Jeff Abrahamson
Sure thing.

Just to be clear, do you mean that instead of launching "i3lock .." I
substitute "strace -o/tmp/i3lock-log-$(date +%s) i3lock ..."?

Jeff Abrahamson
+33 6 24 40 01 57
+44 7920 594 255<-- only if I'm in the UK

http://jeff.purple.com/
http://blog.purple.com/jeff/

On 17 April 2015 at 09:19, Michael Stapelberg  wrote:

> i3lock shouldn’t hang around. Can you start stracing all your i3lock
> instances automatically and provide the corresponding strace output of a
> hung instance in a bugreport?
>
> On Fri, Apr 17, 2015 at 9:04 AM, Jeff Abrahamson  wrote:
>
>> I have a maintenance function that ought not bother spinning the CPU if
>> the screen is locked.  It checks this thus:
>>
>> if pidof i3lock >/dev/null; then
>> ...
>>
>> This is i3-specific, which is sad, but not a huge problem.  What is a
>> problem is that i3lock sometimes hangs around even though I think it should
>> exit on unlock.  And, indeed, most of the time it does exit on unlock.
>> Once in a while, I find I have one or even several i3lock processes hanging
>> around.
>>
>> I either lock my screen explicitly
>>
>> bindsym $mod+Control+L exec i3lock --dpms --inactivity-timeout 10
>> --color=220022
>>
>> or else it's done by inactivity
>>
>> xautolock -detectsleep \
>> -time 3 -locker "i3lock --dpms --color=220022 --inactivity-timeout 10
>> --nofork"
>>
>> This question thus has two parts:
>>
>> 1. Am I doing something wrong that I sometimes have multiple i3lock
>> instances?
>> 2. Is there a better way to detect screen lock than pidof i3lock?
>>
>> Jeff Abrahamson
>> +33 6 24 40 01 57
>> +44 7920 594 255<-- only if I'm in the UK
>>
>> http://jeff.purple.com/
>> http://blog.purple.com/jeff/
>>
>
>
>
> --
> Best regards,
> Michael
>


Re: [i3] Detecting screen locked

2015-04-17 Thread Michael Stapelberg
i3lock shouldn’t hang around. Can you start stracing all your i3lock
instances automatically and provide the corresponding strace output of a
hung instance in a bugreport?

On Fri, Apr 17, 2015 at 9:04 AM, Jeff Abrahamson  wrote:

> I have a maintenance function that ought not bother spinning the CPU if
> the screen is locked.  It checks this thus:
>
> if pidof i3lock >/dev/null; then
> ...
>
> This is i3-specific, which is sad, but not a huge problem.  What is a
> problem is that i3lock sometimes hangs around even though I think it should
> exit on unlock.  And, indeed, most of the time it does exit on unlock.
> Once in a while, I find I have one or even several i3lock processes hanging
> around.
>
> I either lock my screen explicitly
>
> bindsym $mod+Control+L exec i3lock --dpms --inactivity-timeout 10
> --color=220022
>
> or else it's done by inactivity
>
> xautolock -detectsleep \
> -time 3 -locker "i3lock --dpms --color=220022 --inactivity-timeout 10
> --nofork"
>
> This question thus has two parts:
>
> 1. Am I doing something wrong that I sometimes have multiple i3lock
> instances?
> 2. Is there a better way to detect screen lock than pidof i3lock?
>
> Jeff Abrahamson
> +33 6 24 40 01 57
> +44 7920 594 255<-- only if I'm in the UK
>
> http://jeff.purple.com/
> http://blog.purple.com/jeff/
>



-- 
Best regards,
Michael