[Bug 1320982] Re: amd64 ltsp fat client keyring daemon hangs

[Charlie Ott]

This is also in the /var/log/auth.log:

May 21 13:07:19 ltsp550 gnome-keyring-daemon[3892]: couldn't connect to control socket at: /run/user/59319/keyring-rkuE0o/control: Connection refused
May 21 13:07:19 ltsp550 gnome-keyring-daemon[3892]: couldn't set environment variable in session: Setenv interface is only available during the Initialization phase
May 21 13:07:19 ltsp550 gnome-keyring-daemon[3892]: keyring alias directory: /home/cott/.local/share/keyrings

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ltsp in Ubuntu.
https://bugs.launchpad.net/bugs/1320982

Title:
  amd64 ltsp fat client keyring daemon hangs

Status in “ltsp” package in Ubuntu:
  New

Bug description:
  Using Ubuntu 14.04 LTSP amd64 fat client with gnome-keyring
  3.10.1-1ubuntu4

  When launching something like Google Chrome (Which attempts to utilize
  the gnome keyring), Creating a 'new' keyring password causes the tool
  to hang.  It also creates thousands of files labeled
  Default.temp.keyring-#####, where the numbers seemed to be a sequence
  that is being automatically generated.

  when the daemon tries to create the first(new) keyring from the google
  chrome initiated prompt, the files are created in the user home
  folder: ~/.local/share/keyrings/

  There were so many temp files that I had to kill the keyring daemon
  (-start -components=secret) and use 'find . -type f -delete' since the
  rm command was taking too long attempting to delete so many files.  So
  now I just hit 'cancel' whenever the keyring pops up.  However, I
  would like to get this working for my end users.

  Here is some information about how the /run folder is mounted and what
  the environment variables are.  This is likely an LTSP issue, but I am
  not sure what to report to the LTSP team.

  cott at ltsp550:~$ mount
  overlayfs on / type overlayfs (rw)
  proc on /proc type proc (rw,noexec,nosuid,nodev)
  sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
  udev on /dev type devtmpfs (rw,mode=0755)
  devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
  tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
  /dev/nbd0 on /rofs type squashfs (ro,relatime)
  tmpfs on /cow type tmpfs (rw,relatime,mode=755)
  none on /sys/fs/cgroup type tmpfs (rw)
  none on /sys/fs/fuse/connections type fusectl (rw)
  none on /sys/kernel/debug type debugfs (rw)
  none on /sys/kernel/security type securityfs (rw)
  none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
  none on /run/shm type tmpfs (rw,nosuid,nodev)
  none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
  none on /sys/fs/pstore type pstore (rw)
  systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
  server:/home/cott on /home/cott type fuse.sshfs (rw,nosuid,nodev,allow_other)
  gvfsd-fuse on /run/user/59319/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=cott)

  cott at ltsp550:~$ env | grep keyring
  GPG_AGENT_INFO=/run/user/59319/keyring-ypJP2X/gpg:0:1
  GNOME_KEYRING_CONTROL=/run/user/59319/keyring-ypJP2X
  SSH_AUTH_SOCK=/run/user/59319/keyring-ypJP2X/ssh
  OLDPWD=/run/user/59319/keyring-ypJP2X

  
  I have also recently found out that LTSP thick clients do not have access to the shadow file.  Which is not an issue in my case since my users are authenticated against an external directory server using the LDAP for sssd.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1320982/+subscriptions