Waiki Wright píše v Út 06. 09. 2011 v 18:27 -0400:
Hello Dan, I saw your name in one of the bugs related to device_cio_free.conf and hope that you may be able to answer my question. If you prefer me to send my inquire to a mailing list, please let me know.
I'm sending the reply to mailing list, so more people can comment.
I am using s390utils-1.8.2-28.el6.s390x package and I am wondering if there will be a race condition between rcS and device_cio_free.
The device_cio_free.conf file said that it will start when rcS.conf is starting: # # free all devices on startup #
start on starting rcS
task
console output
exec /sbin/device_cio_free
However, in the /sbin/device_cio_free script, it depends on /proc is mounted before the script is called:
BLACKLIST=/proc/cio_ignore . . . if [ ! -f $BLACKLIST ]; then echo "Error: $BLACKLIST kernel interface doesn't exist" exit 2 fi
If the file system is mounted later (from rcS), then device_cio_free script will fail. So should it be better if device_cio_free.conf to start on after /proc is mounted?
Your thought?
Your conclusion looks logical. However this upstart job was proposed by our upstart maintainer when I asked him for a solution to the following problem: need to start an action before the system will try to mount non-root filesystem devices or bring network interfaces up. Also it shouldn't interfere with the startup process on primary arches.
Staring with Fedora 15 there is a systemd solution, see device_cio_free.service in s390utils-1.14.0-1.fc16 [1]
Dan
[1] http://s390.koji.fedoraproject.org/koji/buildinfo?buildID=74738
On 09/07/2011 05:17 AM, Dan Horák wrote:
Waiki Wright píše v Út 06. 09. 2011 v 18:27 -0400:
Hello Dan, I saw your name in one of the bugs related to device_cio_free.conf and hope that you may be able to answer my question. If you prefer me to send my inquire to a mailing list, please let me know.
I'm sending the reply to mailing list, so more people can comment.
I am using s390utils-1.8.2-28.el6.s390x package and I am wondering if there will be a race condition between rcS and device_cio_free.
The device_cio_free.conf file said that it will start when rcS.conf is starting: # # free all devices on startup #
start on starting rcS
task
console output
exec /sbin/device_cio_free
However, in the /sbin/device_cio_free script, it depends on /proc is mounted before the script is called:
BLACKLIST=/proc/cio_ignore . . . if [ ! -f $BLACKLIST ]; then echo "Error: $BLACKLIST kernel interface doesn't exist" exit 2 fi
If the file system is mounted later (from rcS), then device_cio_free script will fail. So should it be better if device_cio_free.conf to start on after /proc is mounted?
Your thought?
Your conclusion looks logical. However this upstart job was proposed by our upstart maintainer when I asked him for a solution to the following problem: need to start an action before the system will try to mount non-root filesystem devices or bring network interfaces up. Also it shouldn't interfere with the startup process on primary arches.
Staring with Fedora 15 there is a systemd solution, see device_cio_free.service in s390utils-1.14.0-1.fc16 [1]
Dan
[1] http://s390.koji.fedoraproject.org/koji/buildinfo?buildID=74738
Hi Dan, Even with the systemd implementation, there is still a possibility for the race condition that I mentioned above(let me know if I am wrong). I haven't seen any response for my question and I wonder if this is a potential problem that worth for a fix.
Waiki
Dan, During the start up sequence, I encountered this error message (which came from device_cio_free script)
Error: /proc/cio_ignore kernel interface doesn't exist
And it is certainly comes from the race condition that I mentioned before.
I applied the following "in-house" patches and the error message went away:
diff -Npur rcS.conf.orig rcS.conf --- rcS.conf.orig 2011-08-18 19:58:06.998420543 +0200 +++ rcS.conf 2011-10-04 23:04:35.385850069 +0200 @@ -14,6 +14,7 @@ task console output exec /etc/rc.d/rc.sysinit post-stop script + initctl emit --no-wait procmounted if [ "$UPSTART_EVENTS" = "startup" ]; then [ -f /etc/inittab ] && runlevel=$(/bin/awk -F ':' '$3 == "initdefault" && $1 !~ "^#" { print $2 }' /etc/inittab) [ -z "$runlevel" ] && runlevel="3"
diff -Npur device_cio_free.conf.orig device_cio_free.conf --- device_cio_free.conf.orig 2011-08-18 19:57:54.568472020 +0200 +++ device_cio_free.conf 2011-08-18 20:00:23.478419433 +0200 @@ -2,7 +2,8 @@ # free all devices on startup #
-start on starting rcS +#Start when /proc is mounted +start on procmounted
task
Any comments? We are temporary using these "in-house" patches until we hear more from you in regard to a possible solution.
Thanks! Waiki
Waiki Wright píše v Út 04. 10. 2011 v 17:20 -0400:
Dan, During the start up sequence, I encountered this error message (which came from device_cio_free script)
Error: /proc/cio_ignore kernel interface doesn't exist
And it is certainly comes from the race condition that I mentioned before.
I applied the following "in-house" patches and the error message went away:
diff -Npur rcS.conf.orig rcS.conf --- rcS.conf.orig 2011-08-18 19:58:06.998420543 +0200 +++ rcS.conf 2011-10-04 23:04:35.385850069 +0200 @@ -14,6 +14,7 @@ task console output exec /etc/rc.d/rc.sysinit post-stop script
initctl emit --no-wait procmounted if [ "$UPSTART_EVENTS" = "startup" ]; then [ -f /etc/inittab ] && runlevel=$(/bin/awk -F ':' '$3
== "initdefault" && $1 !~ "^#" { print $2 }' /etc/inittab) [ -z "$runlevel" ] && runlevel="3"
diff -Npur device_cio_free.conf.orig device_cio_free.conf --- device_cio_free.conf.orig 2011-08-18 19:57:54.568472020 +0200 +++ device_cio_free.conf 2011-08-18 20:00:23.478419433 +0200 @@ -2,7 +2,8 @@ # free all devices on startup #
-start on starting rcS +#Start when /proc is mounted +start on procmounted
task
Any comments? We are temporary using these "in-house" patches until we hear more from you in regard to a possible solution.
I will point our upstart/initscripts maintainer to this, but for me the proposed fix makes sense.
Dan
Waiki Wright píše v Pá 23. 09. 2011 v 14:16 -0400:
On 09/07/2011 05:17 AM, Dan Horák wrote:
Waiki Wright píše v Út 06. 09. 2011 v 18:27 -0400:
Hello Dan, I saw your name in one of the bugs related to device_cio_free.conf and hope that you may be able to answer my question. If you prefer me to send my inquire to a mailing list, please let me know.
I'm sending the reply to mailing list, so more people can comment.
I am using s390utils-1.8.2-28.el6.s390x package and I am wondering if there will be a race condition between rcS and device_cio_free.
The device_cio_free.conf file said that it will start when rcS.conf is starting: # # free all devices on startup #
start on starting rcS
task
console output
exec /sbin/device_cio_free
However, in the /sbin/device_cio_free script, it depends on /proc is mounted before the script is called:
BLACKLIST=/proc/cio_ignore . . . if [ ! -f $BLACKLIST ]; then echo "Error: $BLACKLIST kernel interface doesn't exist" exit 2 fi
If the file system is mounted later (from rcS), then device_cio_free script will fail. So should it be better if device_cio_free.conf to start on after /proc is mounted?
Your thought?
Your conclusion looks logical. However this upstart job was proposed by our upstart maintainer when I asked him for a solution to the following problem: need to start an action before the system will try to mount non-root filesystem devices or bring network interfaces up. Also it shouldn't interfere with the startup process on primary arches.
Staring with Fedora 15 there is a systemd solution, see device_cio_free.service in s390utils-1.14.0-1.fc16 [1]
Dan
[1] http://s390.koji.fedoraproject.org/koji/buildinfo?buildID=74738
Hi Dan, Even with the systemd implementation, there is still a possibility for the race condition that I mentioned above(let me know if I am wrong). I haven't seen any response for my question and I wonder if this is a potential problem that worth for a fix.
race conditions are always serious issue and when they can be reproduced it's definitely worth to open a bugzilla. I'd suggest to fill one against both RHEL-6 and Fedora.
Dan