Bug 738281

Summary: Upgrading from openSUSE 11.4 to openSUSE 12.1 breaks third-party LSB-compliant System V style init scripts
Product: [openSUSE] openSUSE 12.1 Reporter: Bart Van Assche <bart.vanassche>
Component: BasesystemAssignee: Frederic Crozat <fcrozat>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Major    
Priority: P5 - None    
Version: Final   
Target Milestone: ---   
Hardware: x86-64   
OS: SUSE Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: dmesg output
System log since boot

Description Bart Van Assche 2011-12-22 13:41:57 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0

See below.

Reproducible: Always

Steps to Reproduce:
1. Install openSUSE 11.4.
2. Install SCST from the trunk of the SourceForge Subversion repository (see e.g. http://iscsi-scst.sourceforge.net/iscsi-scst-howto.txt for detailed instructions). The most important step with regard to this bug report is "make -C scstadmin install"
3. Comment out SYSTEMD_NO_WRAP="true" in /etc/init.d/scst
4. Verify that starting and stopping SCST via /etc/init.d/scst works fine.
5. Upgrade to openSUSE 12.1
6. Try to start SCST via "/etc/init.d/scst start".
Actual Results:  
SCST not started. The following message is printed:

redirecting to systemctl

Expected Results:  
SCST being started, as before the upgrade.

Apparently the "redirecting to systemctl" message is printed from inside /etc/rc.status.
Comment 1 Bart Van Assche 2011-12-22 13:43:47 UTC
Filed this as a new bug as asked in comment 28 of http://bugzilla.novell.com/show_bug.cgi?id=725917.
Comment 2 Frederic Crozat 2012-01-13 11:47:59 UTC
could you check /var/log/messages for error message ?

what is the output of systemctl status scst ?
Comment 3 Bart Van Assche 2012-01-13 17:50:19 UTC
Haven't found any error messages in /var/log/messages.

Regarding the systemctl output:

# systemctl status scst
Failed to issue method call: Unit name scst is not valid.
Comment 4 Frederic Crozat 2012-01-16 08:54:17 UTC
try systemctl status scst.service
Comment 5 Bart Van Assche 2012-01-22 18:49:52 UTC
# systemctl status scst.service
scst.service - LSB: SCST - A Generic SCSI Target Subsystem
          Loaded: loaded (/etc/init.d/scst)
          Active: inactive (dead)
          CGroup: name=systemd:/system/scst.service
Comment 6 Frederic Crozat 2012-01-23 10:15:50 UTC
could you reboot with adding "systemd.log_level=debug systemd.log_target=kmsg" on your kernel command line and attach dmesg output after rebooting ?
Comment 7 Bart Van Assche 2012-01-23 17:48:53 UTC
After having run "zypper update" I see different behavior than what was reported in #0: without systemd the script still works fine and with systemd it does now something but still not what it should do.

# SYSTEMD_NO_WRAP=true /etc/init.d/scst stop; echo $?
Stopping SCST                                                                    done
0
# SYSTEMD_NO_WRAP=true /etc/init.d/scst start; echo $?
Loading and configuring SCST                                                     done
0
# /etc/init.d/scst stop; echo $?
redirecting to systemctl
0
# /etc/init.d/scst start; echo $?
redirecting to systemctl
Job failed. See system logs and 'systemctl status' for details.
1
Comment 8 Bart Van Assche 2012-01-23 17:54:12 UTC
Created attachment 472342 [details]
dmesg output

The attached file is the output of:

# SYSTEMD_NO_WRAP=true /etc/init.d/scst stop; dmesg -c >/dev/null; /etc/init.d/scst start; dmesg -c > dmesg-scst.txt
Comment 9 Frederic Crozat 2012-01-23 18:06:12 UTC
I need the full log of dmesg, since your system was started (and it would be great if you could ensure SYSTEMD_NO_WRAP is not set when you reboot, so the trace would be complete when dmesg is called the first time).
Comment 10 Bart Van Assche 2012-01-23 18:34:52 UTC
Created attachment 472349 [details]
System log since boot

System log since boot, with SYSTEMD_NO_WRAP not set.
Comment 11 Bart Van Assche 2012-01-23 18:42:12 UTC
Regarding the kernel I'm running: it's a 3.2.1 kernel + srp-ha patches + scst_exec_req_fifo-3.2.patch + 3.3-rc1 commit 625cbfa + 3.3-rc1 commit 2cd094f. The reported issue also occurs with SUSE's kernel-desktop-3.1.0-1.2.1.x86_64 kernel by the way.
Comment 12 Frederic Crozat 2012-01-24 08:46:24 UTC
it seems scst wasn't started at startup, since I don't see it at all in the trace you posted.

Please, make sure the service was started before doing dmesg and don't compress the trace when attaching it to bugzilla.
Comment 13 Bart Van Assche 2012-01-24 19:32:56 UTC
Correct, SCST wasn't started at startup - I start that service manually.

The /etc/init.d/scst script seems to work now with the latest openSUSE 12.1 userspace packages. It's still not clear to me though what has been causing the failure. I'll keep an eye on this, and thanks for looking into this.
Comment 14 Frederic Crozat 2012-01-25 14:28:18 UTC
there were some changes in 12.1 maintenance update for systemd, which might have fixed scst script handling.

Let's close this as "fixed", feel free to reopen if you have the issue.