Have only seen this on Ubuntu 13.10 so far, but it means that tl-setup never completes when adding the printer queues. The issue seems to be the following section: --- # # Restart CUPS # echo "Restarting CUPS to make it aware of changes..." for file in /etc/init.d/cups /etc/init.d/cupsd /etc/init.d/cupsys; do [ -f "${file}" ] && "${file}" stop [ -f "${file}" ] && "${file}" start done echo "Waiting for CUPS to start..." for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30; do OUTPUT=$("${CUPS_PREFIX}/sbin/lpinfo" -h localhost -v 2>/dev/null) --- Sometimes $OUTPUT ends up being "Password for root on localhost?" with an associated input prompt, and this is where it hangs. When this happens, in CUPS' error_log you get: --- E [11/Oct/2013:11:10:49 +0200] [Client 15] Local authentication certificate not found. -- Strangely enough I can only seem to provoke this using the restart_cups script - restarting CUPS and running lpinfo by hand seems to work reliably. Needs more investigation.
Apparently calling init scripts directly is just not fashionable anymore. Restarting cups in this way results in a *second* cupsd process being launched, without killing the first one started by upstart. Further, the new cupsd process is launched without the proper "-c <config_file>" flag, so it has no hope of working. tl;dr: we need to start/stop services via upstart instead, using the "service" command.
Clarification: The initial description for this bug refers to the script /opt/thinlinc/libexec/restart_cups. I'm changing the title of this bug since the problem is more general. We need to make sure our scripts use upstart for starting/stopping services on Ubuntu.
Since tl-setup won't complete on Ubuntu 13.10, we should probably document this in Platform Specific Notes. The documentation should be removed once this bug is closed.
(In reply to comment #3) > Since tl-setup won't complete on Ubuntu 13.10, we should probably document this > in Platform Specific Notes. The documentation should be removed once this bug > is closed. r28028
(In reply to comment #1) > Apparently calling init scripts directly is just not fashionable anymore. > Restarting cups in this way results in a *second* cupsd process being launched, > without killing the first one started by upstart. Further, the new cupsd > process is launched without the proper "-c <config_file>" flag, so it has no > hope of working. > > tl;dr: we need to start/stop services via upstart instead, using the "service" > command. Things are changing rapidly. From http://askubuntu.com/questions/58404/how-to-start-and-stop-a-service: "The new and preferred way to stop start and restart services is through /etc/init.d" Written by a person with "7 gold medals"... However, using the "service" command looks like an interesting option. That should work on systemd distros as well. From http://fedoraproject.org/wiki/Systemd#Does_service_command_work_with_systemd.3F: "Does service command work with systemd? Yes. It has been modified to call systemctl automatically when dealing with systemd service files" However, then question is then: * Can we always use the service command, or do we need to fallback on /etc/init.d sometimes? In our distribution-compatibility.txt we have this text: "Do not use the "service" command. It is not available on SuSE, for example." However, this was a while - perhaps this is no longer a problem on all relevant distros. * Use the "service" command from the PATH, or with some hardcoded path? Ubuntu uses /usr/sbin/service, but RHEL6 /sbin/service.
According to http://rpmfind.net/, we have: /sbin/service: OpenSuse 11.2 - 12.3 CentOS 5-6 Fedora 13-18 Mageia Mandriva /usr/sbin/service: OpenSuse 12.3 Fedora 19 Ubuntu also uses /usr/sbin. IOW, the path may vary.
Fixed in r28040. Docu patch reversed.
No more hang during installation of printer queues on Ubuntu 13.10, and VSM services seem to be installed/started correctly. Closing.
We've decided to call our own services through the new wrapper script as well.
(In reply to comment #9) > We've decided to call our own services through the new wrapper script as well. Fixed in 28050. Tester needs to check: * Basic installation through tl-setup * Log rotation * Status and restart in tlwebadm * Doc * Package uninstall
Testing on SLED11 Sp2 2013-10-18 13:24:42,774: Adding 'nearest' printer queue... 2013-10-18 13:24:42,857: Failed to run printer script '/opt/thinlinc/libexec/add_nearest_printer.sh' 2013-10-18 13:24:42,858: Output (stdout): 2013-10-18 13:24:42,858: Using CUPS installed at prefix /usr 2013-10-18 13:24:42,858: Using CUPS_SERVERBIN=/usr/lib64/cups 2013-10-18 13:24:42,859: Adding CUPS backend nearest 2013-10-18 13:24:42,859: Restarting CUPS to make it aware of changes... 2013-10-18 13:24:42,859: Output (stderr): 2013-10-18 13:24:42,859: /opt/thinlinc/libexec/restart_cups: line 23: syntax error near unexpected token `>' 2013-10-18 13:24:42,859: /opt/thinlinc/libexec/restart_cups: line 23: ` ${ORIGIN}/service "${name}" restart &>>${errors} && break'
(In reply to comment #11) > Testing on SLED11 Sp2 > > 2013-10-18 13:24:42,774: Adding 'nearest' printer queue... > 2013-10-18 13:24:42,857: Failed to run printer script > '/opt/thinlinc/libexec/add_nearest_printer.sh' > 2013-10-18 13:24:42,858: Output (stdout): > 2013-10-18 13:24:42,858: Using CUPS installed at prefix /usr > 2013-10-18 13:24:42,858: Using CUPS_SERVERBIN=/usr/lib64/cups > 2013-10-18 13:24:42,859: Adding CUPS backend nearest > 2013-10-18 13:24:42,859: Restarting CUPS to make it aware of changes... > 2013-10-18 13:24:42,859: Output (stderr): > 2013-10-18 13:24:42,859: /opt/thinlinc/libexec/restart_cups: line 23: > syntax error near unexpected token `>' > 2013-10-18 13:24:42,859: /opt/thinlinc/libexec/restart_cups: line 23: ` > ${ORIGIN}/service "${name}" restart &>>${errors} && break' Testing on Fedora 19 (systemd), restart_cups does not have the above problem.
(In reply to comment #11) > 2013-10-18 13:24:42,859: /opt/thinlinc/libexec/restart_cups: line 23: > syntax error near unexpected token `>' The &>> notation was added in Bash 4, and SLED has bash 3.2. Converted to the older, more compatible syntax in r28057.
Works fine now on RHEL6. Aaron, still fine on Ubuntu?
(In reply to comment #14) > Works fine now on RHEL6. Aaron, still fine on Ubuntu? Just finished installing the nightly build on Ubuntu 13.10, no errors during printer queue installation or starting of services.
