I'm having this same issue with lab computers I'm administering. In both cases (so far), the commonalities are:
- the systems run 9.04
- the home directory for the user is mounted via CIFS (samba) from a fileserver
Notably, there are around 5 or so 9.04 systems in the lab -- which do not mount the home directory via CIFS -- that do not exhibit this problem. Only the CIFS-mounting systems.
My "breakthrough" in troubleshooting this was to run an strace(1) on the fileserver against the user's smbd process. Upon login, the following looped interminably:
Note the critical line showing that file .pulse/7692...blahblah...bebb23:runtime cannot be found. Looking at this file on disk, it turns out to be a symlink to a file such as /tmp/pulse-6yCwltbxKn5h, the latter which doesn't exist, thus creating a broken symlink situation. So it seems that Pulse gets hung up on this and stalls the entire login process.
The workaround for me was to remove the symlink, which would then force a new /tmp/pulse-XXX file to be created with a proper symlink in the user's home directory, and the login would proceed successfully!
I've confirmed that this workaround works on both affected systems.
I'm not sure what the underlying _cause_ is, however, and am worried whether this will pop up in the future or not, thus any help is appreciated.
I'm having this same issue with lab computers I'm administering. In both cases (so far), the commonalities are:
- the systems run 9.04
- the home directory for the user is mounted via CIFS (samba) from a fileserver
Notably, there are around 5 or so 9.04 systems in the lab -- which do not mount the home directory via CIFS -- that do not exhibit this problem. Only the CIFS-mounting systems.
My "breakthrough" in troubleshooting this was to run an strace(1) on the fileserver against the user's smbd process. Upon login, the following looped interminably:
" 0\0\0\0\ 0\1\300\ 0\0\0\0\ 0\0\0\0\ 0\0\0\0\ 1\0\1ld\ 0\271A\ 17"..., 170) = 170 pulse/7692ed27d 65b84c17c3cdda4 49bebb23: runtime" , 0x7fffffc94f00) = -1 ENOENT (No such file or directory) .pulse/ 7692ed27d65b84c 17c3cdda449bebb 23:runtime" , {st_mode= S_IFLNK| 0777, st_size=23, ...}) = 0 ".pulse/ 7692ed27d65b84c 17c3cdda449bebb 23:runtime" , "/tmp/pulse- 6yCwltbxKn5h" ..., 4096) = 23 377SMB2\ 0\0\0\0\ 200\1\300\ 0\0\0\0\ 0\0\0\0\ 0\0\0\0\ 1\0\1ld" ..., 112) = 112
read(23, "\0\0\0\252"..., 4) = 4
read(23, "\377SMB2\
stat(".
lstat("
fcntl(11, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=17872, len=1}) = 0
fcntl(11, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=17872, len=1}) = 0
readlink(
write(23, "\0\0\0l\
select(24, [19 23], [], NULL, {57, 81589}) = 1 (in [23], left {57, 72000})
"
Note the critical line showing that file .pulse/ 7692... blahblah. ..bebb23: runtime cannot be found. Looking at this file on disk, it turns out to be a symlink to a file such as /tmp/pulse- 6yCwltbxKn5h, the latter which doesn't exist, thus creating a broken symlink situation. So it seems that Pulse gets hung up on this and stalls the entire login process.
The workaround for me was to remove the symlink, which would then force a new /tmp/pulse-XXX file to be created with a proper symlink in the user's home directory, and the login would proceed successfully!
I've confirmed that this workaround works on both affected systems.
I'm not sure what the underlying _cause_ is, however, and am worried whether this will pop up in the future or not, thus any help is appreciated.