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 <mich...@i3wm.org> wrote: > On Fri, Apr 17, 2015 at 3:00 AM, Jeff Abrahamson <j...@purple.com> 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/64513d Inode: 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.000000000 +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 <mich...@i3wm.org> 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 <j...@purple.com> > 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 <mich...@i3wm.org> > 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 <j...@purple.com> > >> >> 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 <mich...@i3wm.org> > >> >>> 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 <j...@purple.com> > >> >>>> 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 <mich...@i3wm.org> > >> >>>>> 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 < > j...@purple.com> > >> >>>>>> 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 > > > > > > > > -- > Best regards, > Michael >
