[15:37:48]  halfline, are you around? [15:42:44]  i was wanting to ask you some questions about bug 607861. [15:43:17]  I notice in gdm-session-worker.c that MESSAGE_REPLY_TIMEOUT is set to (10 * 60 * 1000), or 10 minutes [15:43:31]  it seems that this timeout should be longer, perhaps MAX_INT? [15:44:00]  also, it seems that it would be nice if GDM could just silently restart the PAM conversation when timeouts do happen, rather than complaining about them being a "Conversation failure" [15:44:18]  though I'm not really sure how to make this work since the problem is noticed in the conversation function [15:45:07]  and I'm guessing the only way to pass data back to the worker is via the pam_authenticate return code, which doesn't really provide a possible value to indicate that this isn't really an error. [15:47:32]  though it does seem that the GdmSessionWorker structure is passed into the conversation function, so if we modified the code to not reset worker->priv->timed_out in the conversation function back to FALSE and instead dealt with it in gdm_session_worker_uninitialize_pam, this might work. [15:47:34]  Thoughts? [15:47:52]  right now, GDM generates failed login audit records for each failure caused by a timeout, which is ugly [15:48:16]  so we really want to catch this and avoid displaying the error message and avoid calling audit when this problem happens [15:59:11]  yippi: yea probably better to just set it MAX_INT [15:59:31]  you sort of side step the problem there [15:59:39]  and really it's not something that should have a timeout [15:59:54]  who are we to say how long a pam conversation should take? [16:00:17]  my guess is the only reason there's a timeout there is because dbus didn't used to have the concept of messages without a timeout [16:00:32]  being able to use MAX_INT is pretty new [16:06:50]  halfline, right, it is likely not uncommon for a machine to sit idle a few days before someone logs in [16:07:02]  but setting it to MAX_INT would be better since it wouldn't happen after just 10 minutes [16:07:58]  but does it make sense to move the handling of worker->priv->timed_out to handle this [16:08:06]  right now it gets reset back to FALSE in the conversation function [16:08:40]  perhaps if we left it TRUE and handled resetting it back to FALSE in gdm_session_worker_uninitialize_pam, then we could just avoid displaying the error message and avoid the audit [16:09:07]  and reset it back to FALSE there.  I'm not really familiar with how the GdmSessionWorker structure is passed between the worker and the conversation function [16:09:13]  so I'm not sure this would work, but wanted to hear your thoughts? [16:09:20]  why don't we remove timed_out ? [16:09:40]  and do what instead? [16:09:57]  nothing? it's handling a case we're eliminating now, right? [16:10:13]  MAX_INT is a magic value in dbus that means "don't ever time out" [16:10:16]  you mean just put the dbus_connection_send_with_reply_and_block in a do loop so it keeps calling it as long as it gets a timeout error? [16:10:21]  no MAX_INT does not mean never time out [16:10:29]  huh? [16:10:49]  i could be wrong, but look here [16:10:54]  you're saying "no" and i'm saying "yes". one of us must be confused [16:10:56]  http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html [16:11:23]  http://dbus.freedesktop.org/doc/dbus/api/html/group__DBusConnection.html#g077734c6c9f922be07ce8b7b23a57b9e [16:11:32]  oh i see [16:11:34]  well [16:11:37]  i don't think that's true anymore [16:11:41]  but we can look [16:11:43]  it says MAX_INT is not really infinite [16:11:48]  and is instead "a few hours" [16:12:02]  pretty sure a combination of patches between davidz and scott james remenant made that documentation false [16:12:24]  under "dbus_connection_send_with_reply" it says: [16:12:30]  here is no way to avoid a timeout entirely, other than passing INT_MAX for the timeout to mean "very long timeout." libdbus clamps an INT_MAX timeout down to a few hours timeout though. [16:12:48]  it would be nice if it is false.  [16:13:14]  but wouldn't it be reasonable to just put the call to dbus_connection_send_with_reply_and_block in a do-loop? [16:13:43]  so it just keeps calling it if it would otherwise set timed_out to TRUE? [16:14:02]  that seems a better fix, along with MAX_INT [16:14:21]  and would avoid the conversation function ending, and the problems that causes [16:14:39]  and it would work with older versions of D-Bus that might not have the latest fixes [16:14:58]  to make MAX_INT really infinite.  Perhaps I should send an email to the dbus list to get clarification on how MAX_INT works [16:15:01]  thoughts? [16:15:20]  sounds reasonable [16:15:27]  hang on [16:15:29]  which part?  all of it? [16:15:32]  yes [16:15:39]  right now i'm looking through the dbus history [16:15:41]  so you think i should create a patch to add the do-loop and get rid of the timeout? [16:15:44]  we can probably save ourselves a mail [16:15:53]  thanks [16:16:15]  but do you think adding a do-loop and getting rid of the timed_out variable makes sense, then? [16:16:46]  pretty much [16:16:49]  my only concern is [16:17:11]  there are other times besides tmeout that dbus won't reply [16:17:15]  like if the security policy is wrong [16:17:31]  i see. [16:17:38]  but probably not something we should be designing for [16:17:47]  since that's sort of indicative of a broken installation [16:18:07]  true.  having it mess up by calling over and over is probably just as bad as displaying a useless error message and auditing a failed login over and over [16:18:24]  if not worse [16:18:47]  i suppose we could do something like check to see if the failures are happening quickly and log an error in that case [16:19:24]  http://cgit.freedesktop.org/dbus/dbus/commit/?id=390aa0 [16:19:34]  docs just haven't been updated on freedesktop.org i guess [16:19:59]  i see.  so you think just MAX_INT is enough? [16:20:18]  probably [16:20:20]  thing is [16:20:24]  there have been security holes too [16:20:32]  so users really shouldn't be running old versions of dbus [16:20:36]  is that fix in the 1.2 branch or only the 1.3 branch? [16:20:59]  true, we probably don't need to care so much about supporting old dbus as long as the fix is in the 1.2 branch [16:21:12]  the 1.3 branch is still experimental, so it isn't nice to only support a feature that is 1.3 only [16:21:42]  let me look [16:22:01]  ***  yippi has left chat #gdm (Remote closed the connection). [16:23:21]  hrmm he disappeared [16:26:29]  sorry, got bumped [16:26:35]  it's all good [16:26:35]  what did you find? [16:26:48]  i notice that patch is not in dbus 1.2.16 [16:26:48]  1.2.16 has already been released [16:26:50]  with that fix [16:26:53]  huh? [16:27:00]  again we're already contradicting ourselves [16:27:08]  lol [16:27:23]  i'm looking at the 1.2.16 code, and the docs patch you pointed me towards doesn't seem to be applied [16:27:31]  hmm [16:27:38]  maybe git is failing me [16:27:40]  perhaps the code to make MAX_INT work as you describe is there, but the docs seem to say the old stuff on the website [16:27:53]  if i go to the 1.2 branch [16:27:54]  no sorry, you are right [16:28:07]  i can't read straight [16:28:08]  and type git describe 390aa0344 it tells me it went in after 1.2.14 [16:28:11]  the patch is in 1.2.16 [16:28:14]  oka [16:28:15]  y [16:28:21]  so i think we're probably set [16:28:41]  so great.  I'll provide a patch after I verify it works reasonably.  I'll probably let me computer sit overnight on the loginscreen and let you know if it worked okay [16:28:49]  sounds good [16:28:58]  thanks for talking me through this.  [16:29:04]  sure [16:29:16]  any update on when ConsoleKit MultiSeat stuff might get reviewed? [16:29:40]  so we had a meeting with davidz [16:29:46]  great news [16:29:49]  i was supposed to do a write up about it an send it to the list [16:29:54]  but i got side-tracked [16:30:03]  by my own looming deadlines [16:30:06]  how did the review go.  Mostly okay, or we have months of rewriting code again ahead of us? [16:30:43]  probably somewhere between those two end points [16:30:53]  mccann and davidz don't like the display template stuff [16:31:31]  and mccann would like the hand off between display manager and console kit to be via the existing call outs mechanism [16:31:42]  instead of having the SeatManager interface [16:32:21]  i'll do a write up and of the meeting and send to gdm-list [16:32:32]  as soon as i get above water on this rhel6 stuff i'm working on [16:32:36]  it's a bit disappointing to hear it won't be so easy [16:32:43]  thanks, sounds good [16:33:32]  yea i feel a little bad because some of the design decisions i came up with were off base [16:34:04]  anyway, it will work out [16:34:08]  great [16:34:17]  i'm mostly glad that we're making some progress [16:35:29]  alright i'm going to jump back into this code i'm working on so i can get it commited and build before the bus leaves today [16:35:35]  *built [16:35:58]  okay, good luck