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

[Alkis Georgopoulos]

*** This bug is a duplicate of bug 1321922 ***
    https://bugs.launchpad.net/bugs/1321922

** This bug has been marked a duplicate of bug 1321922
   gnome-keyring-daemon failing of sshfs

-- 
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:
  Invalid

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