Bug 4843 - Calling init scripts directly is deprecated on Ubuntu 13.10
Summary: Calling init scripts directly is deprecated on Ubuntu 13.10
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Printing (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.1.1
Assignee: Peter Åstrand
URL:
Keywords: aaron_tester, astrand_tester, prosaic
Depends on:
Blocks:
 
Reported: 2013-10-11 11:31 CEST by Aaron Sowry
Modified: 2013-10-24 11:08 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Aaron Sowry cendio 2013-10-11 11:31:41 CEST
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.
Comment 1 Aaron Sowry cendio 2013-10-11 15:46:16 CEST
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.
Comment 2 Aaron Sowry cendio 2013-10-11 15:59:34 CEST
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.
Comment 3 Aaron Sowry cendio 2013-10-14 11:22:10 CEST
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.
Comment 4 Aaron Sowry cendio 2013-10-14 12:26:21 CEST
(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
Comment 5 Peter Åstrand cendio 2013-10-15 14:06:57 CEST
(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.
Comment 6 Peter Åstrand cendio 2013-10-15 14:26:23 CEST
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.
Comment 7 Peter Åstrand cendio 2013-10-15 16:48:12 CEST
Fixed in r28040. Docu patch reversed.
Comment 8 Aaron Sowry cendio 2013-10-17 09:28:28 CEST
No more hang during installation of printer queues on Ubuntu 13.10, and VSM services seem to be installed/started correctly. Closing.
Comment 9 Peter Åstrand cendio 2013-10-17 12:37:46 CEST
We've decided to call our own services through the new wrapper script as well.
Comment 10 Peter Åstrand cendio 2013-10-17 12:40:36 CEST
(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
Comment 11 Henrik Andersson cendio 2013-10-18 12:30:14 CEST
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'
Comment 12 Henrik Andersson cendio 2013-10-18 13:03:07 CEST
(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.
Comment 13 Pierre Ossman cendio 2013-10-18 13:51:01 CEST
(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.
Comment 14 Peter Åstrand cendio 2013-10-21 13:12:31 CEST
Works fine now on RHEL6. Aaron, still fine on Ubuntu?
Comment 15 Aaron Sowry cendio 2013-10-21 13:17:21 CEST
(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.

Note You need to log in before you can comment on or make changes to this bug.