pconklin: 22:30 Jan 05, 2013
when accessing the SSL side of the web interface, cupsd appears to hang and can not be stopped with service cups stop.
[root@localhost ~]# ps -ef | grep cups | grep -v grep
root 2103 1 0 00:23 ? 00:00:00 /usr/sbin/cupsd -C /etc/cups/cupsd.conf
[root@localhost ~]# strace -p 2103
Process 2103 attached - interrupt to quit
select(16, [15], NULL, NULL, {1, 611000}) = 0 (Timeout)
select(16, [15], NULL, NULL, {3, 0}) = 0 (Timeout)
select(16, [15], NULL, NULL, {3, 0}) = 0 (Timeout)
select(16, [15], NULL, NULL, {3, 0}) = 0 (Timeout)
select(16, [15], NULL, NULL, {3, 0} <unfinished ...>
Process 2103 detached
[root@localhost ~]# service cups stop
cups: stopped scheduler. [ OK ]
[root@localhost ~]# strace -p 2103
Process 2103 attached - interrupt to quit
select(16, [15], NULL, NULL, {1, 286000}) = 0 (Timeout)
select(16, [15], NULL, NULL, {3, 0}) = 0 (Timeout)
select(16, [15], NULL, NULL, {3, 0}) = 0 (Timeout)
select(16, [15], NULL, NULL, {3, 0}) = 0 (Timeout)
select(16, [15], NULL, NULL, {3, 0}) = 0 (Timeout)
select(16, [15], NULL, NULL, {3, 0} <unfinished ...>
Process 2103 detached
[root@localhost ~]# tail /var/log/cups/error_log
d [06/Jan/2013:00:23:40 -0600] select_timeout: JobHistoryUpdate=0
d [06/Jan/2013:00:23:40 -0600] select_timeout(0): 86400 seconds to do nothing
d [06/Jan/2013:00:23:47 -0600] cupsdAcceptClient(lis=0x2b125a03cce0(10)) Clients=0
D [06/Jan/2013:00:23:47 -0600] [Client 14] Accepted from 192.168.1.133:631 (IPv4)
d [06/Jan/2013:00:23:47 -0600] cupsdAddSelect(fd=14, read_cb=0x2b1240f2b3c0, write_cb=(nil), data=0x2b125a08fe80)
d [06/Jan/2013:00:23:47 -0600] select_timeout: JobHistoryUpdate=0
d [06/Jan/2013:00:23:47 -0600] [Client 14] cupsdReadClient error=0, used=0, state=HTTP_WAITING, data_encoding=HTTP_ENCODE_LENGTH, data_remaining=0, request=(nil)(), file=-1
d [06/Jan/2013:00:23:47 -0600] [Client 14] Saw first byte 16, auto-negotiating SSL/TLS session.
D [06/Jan/2013:00:23:47 -0600] [Client 14] Encrypting connection.
I [06/Jan/2013:00:23:47 -0600] Generating SSL server key...
[root@localhost ~]# date
Sun Jan 6 00:29:39 CST 2013
[root@localhost ~]# ps -ef | grep cups | grep -v grep
root 2103 1 0 00:23 ? 00:00:00 /usr/sbin/cupsd -C /etc/cups/cupsd.conf
|
pconklin: 22:37 Jan 05, 2013
this is in there occasionally too
select(16, [15], NULL, NULL, {3, 0}) = 1 (in [15], left {0, 295000})
read(15, "\251\200\337\347\212e#H=", 164) = 9
|
mike: 08:57 Jan 06, 2013
What OS, what SSL library?
|
pconklin: 10:13 Jan 06, 2013
CentOS 5.8. OpenSSL sorry, I always forget to post that
|
pconklin: 19:25 Jan 06, 2013
[root@localhost ~]# rpm -qa | grep ssl
openssl-devel-0.9.8e-22.el5_8.4
openssl-0.9.8e-22.el5_8.4
openssl-devel-0.9.8e-22.el5_8.4
openssl-0.9.8e-22.el5_8.4
|
mike: 12:57 Jan 11, 2013
OK, I'm guessing your system doesn't have enough entropy to generate the self-signed key, which is blocking things.
If you just create your own SSL certificate and private key (just follow any Apache tutorial for making a self-signed cert) and tell cupsd to use it (ServerCertificate and ServerKey directives) then this problem should just go away.
Unfortunately, OpenSSL does not provide any way to protect against this, unlike GNU TLS on Linux... :(
|
pconklin: 13:00 Jan 11, 2013
I can try that, however why is it that all of the pre 1.6.1 versions do not have this issue?
|
pconklin: 16:01 Jan 11, 2013
generating the Self Signed Certificate did resolve the issue, however I was able to get the same issue on several CentOS and RHEL installs (5.5 - 5.8) on several different machines, chipsets, etc) so I do at least have it functional, but i am curious why this wasn't an issue until 1.6.
|
pconklin: 18:38 Jan 11, 2013
I went back and checked, i do have gnutls
[root@localhost cups-1.6.1.1]# rpm -qa | grep tls
gnutls-devel-1.4.1-7.el5_8.2
gnutls-devel-1.4.1-7.el5_8.2
gnutls-1.4.1-7.el5_8.2
gnutls-1.4.1-7.el5_8.2
|
mike: 06:56 Jan 14, 2013
Back to active for a moment; what does:
ldd /usr/sbin/cupsd
report?
The commands we use with OpenSSL/GNU TLS changed in 1.6, so it is possible that has exposed an issue.
|
pconklin: 08:35 Jan 14, 2013
[root@localhost ~]# ldd /usr/sbin/cupsd
linux-vdso.so.1 => (0x00007fffea2ae000)
libcupsmime.so.1 => /usr/lib64/libcupsmime.so.1 (0x00002ac64a451000)
libz.so.1 => /lib64/libz.so.1 (0x00002ac64a656000)
libgnutls.so.13 => /usr/lib64/libgnutls.so.13 (0x00002ac64a86b000)
libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x00002ac64aaef000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002ac64ad61000)
libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00002ac64af66000)
libpam.so.0 => /lib64/libpam.so.0 (0x00002ac64b169000)
libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00002ac64b374000)
libavahi-common.so.3 => /usr/lib64/libavahi-common.so.3 (0x00002ac64b5b0000)
libavahi-client.so.3 => /usr/lib64/libavahi-client.so.3 (0x00002ac64b7bb000)
libcups.so.2 => /usr/lib64/libcups.so.2 (0x00002ac64b9cb000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002ac64bc2b000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002ac64be59000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002ac64c0ee000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002ac64c314000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ac64c516000)
libm.so.6 => /lib64/libm.so.6 (0x00002ac64c731000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002ac64c9b5000)
libc.so.6 => /lib64/libc.so.6 (0x00002ac64cbed000)
/lib64/ld-linux-x86-64.so.2 (0x000000305f600000)
libaudit.so.0 => /lib64/libaudit.so.0 (0x00002ac64cf45000)
libcap.so.1 => /lib64/libcap.so.1 (0x00002ac64d15d000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002ac64d362000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002ac64d56a000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00002ac64d76c000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00002ac64d982000)
libsepol.so.1 => /lib64/libsepol.so.1 (0x00002ac64db9a000)
|
mike: 10:46 Jan 18, 2013
OK, so your cupsd is linked to GNU TLS, so it should be using the same cert generation code as before. What version of GNU TLS is on the systems that do not hang?
|
pconklin: 10:48 Jan 18, 2013
It hangs on all of them. I go back to 1.4.8 and it works like a champ every time. 1 in 100 times i can get it to work for 1.6.1
|
mike: 15:45 Jan 18, 2013
This is strange - the GNU TLS cert generation code is the same on 1.4.8 and 1.6.1.
I can't reproduce this on my Linux VM right now, but will keep this open in case I can figure out why this might be happening.
|