[arch-general] [PATCH] rc.sysinit: Get rid of grep
In my opinion there is no need to use grep in rc.sysinit. From 30b0a63ab9cbc93f79876e2ca7b2526d00ef6107 Mon Sep 17 00:00:00 2001 From: Kurt J. Bosch Date: Mon, 20 Sep 2010 23:31:44 +0200 Subject: [PATCH] rc.sysinit: Get rid of grep --- rc.sysinit |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/rc.sysinit b/rc.sysinit index 09d5e97..5b9864e 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -21,7 +21,7 @@ run_hook sysinit_start /bin/mountpoint -q /sys || /bin/mount -n -t sysfs none /sys if ! /bin/mountpoint -q /dev; then - if grep -q devtmpfs /proc/filesystems 2>/dev/null; then + if [[ $(
Re: [arch-general] [PATCH] rc.sysinit: only call modprobe once
2010-09-20 22:51, Dave Reisner:
Your echo is redundant. Just quote the expansion and assign it.
NAK. Try this:
MODULES=( '!foo' '!bar' )
modules="${modul...@]/#\!*}"
[[ $modules ]]&& echo "'$modules' is not a null string"
' ' is not a null string
modules="${modul...@]/#\!*}"
I think we're a long way away from the day when there's a '!' as
part of a module name, but I think it's probably best to anchor the
expression to the start of each element regardless.
OK, but the quotes aren't needed because word splitting is not
performed here. So we finally get:
modules=$( echo ${modul...@]/#\!*} )
--
Kurt
We're going to have to agree that we're both right, and we're both
wrong. The echo is _still_ unnecessary. I've learned to quote everything in
bash, and now it's working against me.
$ MODULES=( '!foo' '!bar' )
$ modules=${modul...@]/#\!*/}
$ [[ -z $modules ]]&& echo null
null
d
Wow, that's really true :)
Re: [arch-general] [PATCH] rc.sysinit: only call modprobe once
2010-09-20 22:22, Kurt J. Bosch:
2010-09-20 17:56, Dave Reisner:
On Mon, Sep 20, 2010 at 05:39:25PM +0200, Kurt J. Bosch wrote:
2010-09-20 04:10, Dave Reisner:
On Mon, Sep 20, 2010 at 11:57:06AM +1000, Allan McRae wrote:
On 20/09/10 11:54, Dave Reisner wrote:
Use modprobe -a and a bash PE to filter the MODULES array.
Signed-off-by: Dave Reisner
---
rc.sysinit | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 09d5e97..4b6e1e7 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -92,14 +92,10 @@ if /bin/pidof -o %PPID /sbin/udevd>/dev/null;
then
fi
# Load modules from the MODULES array defined in rc.conf
-if [[ $load_modules != off&& -f /proc/modules ]]; then
- stat_busy "Loading Modules"
- for mod in "${modul...@]}"; do
- if [[ $mod = ${mod#!} ]]; then
- /sbin/modprobe $mod
- fi
- done
- stat_done
+if [[ $load_modules != off&& -f /proc/modules ]]&& ((
${#modul...@]}> 0 )); then
+ stat_busy "Loading Modules"
+ /sbin/modprobe -a "${modul...@]/#\!*/}"
+ stat_done
fi
# Wait for udev uevents
Does this still work in the "null" case where there is only modules
specified with "!" in the front?
Allan
Excellent observation -- it would not. Counting the size of the array
with the PE in place isn't possible (or desirable), either. Perhaps a
more graceful solution is to reassign the output of the PE to a new
array and operate based on that. Certainly still beats calling modprobe
for every element in the array, imo.
d
I think it could be done like so:
From 6465c90fc851b12cfce791228415ae1c2823e050 Mon Sep 17 00:00:00 2001
From: Kurt J. Bosch
Date: Mon, 20 Sep 2010 17:31:54 +0200
Subject: [PATCH] rc.sysinit: only call modprobe once (as proposed by
Dave Reisner)
---
rc.sysinit | 9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 09d5e97..07b3f67 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -92,13 +92,10 @@ if /bin/pidof -o %PPID /sbin/udevd>/dev/null; then
fi
# Load modules from the MODULES array defined in rc.conf
-if [[ $load_modules != off&& -f /proc/modules ]]; then
+modules=$( echo ${MODULES[*]/\!*/} )
+if [[ $modules&& $load_modules != off&& -f /proc/modules ]]; then
stat_busy "Loading Modules"
- for mod in "${modul...@]}"; do
- if [[ $mod = ${mod#!} ]]; then
- /sbin/modprobe $mod
- fi
- done
+ /sbin/modprobe -a $modules
stat_done
fi
--
1.7.0.3
Your echo is redundant. Just quote the expansion and assign it.
NAK. Try this:
MODULES=( '!foo' '!bar' )
modules="${modul...@]/#\!*}"
[[ $modules ]] && echo "'$modules' is not a null string"
' ' is not a null string
modules="${modul...@]/#\!*}"
I think we're a long way away from the day when there's a '!' as
part of a module name, but I think it's probably best to anchor the
expression to the start of each element regardless.
OK, but the quotes aren't needed because word splitting is not performed
here. So we finally get:
modules=$( echo ${modul...@]/#\!*} )
--
Kurt
P.S. To clarify this a bit: Word splitting is not performed on variable
assignment, but actually intended on parameter expansion to get rid of
extra blanks by using echo.
Re: [arch-general] [PATCH] rc.sysinit: only call modprobe once
2010-09-20 17:56, Dave Reisner:
On Mon, Sep 20, 2010 at 05:39:25PM +0200, Kurt J. Bosch wrote:
2010-09-20 04:10, Dave Reisner:
On Mon, Sep 20, 2010 at 11:57:06AM +1000, Allan McRae wrote:
On 20/09/10 11:54, Dave Reisner wrote:
Use modprobe -a and a bash PE to filter the MODULES array.
Signed-off-by: Dave Reisner
---
rc.sysinit | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 09d5e97..4b6e1e7 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -92,14 +92,10 @@ if /bin/pidof -o %PPID /sbin/udevd>/dev/null; then
fi
# Load modules from the MODULES array defined in rc.conf
-if [[ $load_modules != off&&-f /proc/modules ]]; then
-stat_busy "Loading Modules"
-for mod in "${modul...@]}"; do
- if [[ $mod = ${mod#!} ]]; then
- /sbin/modprobe $mod
- fi
-done
-stat_done
+if [[ $load_modules != off&&-f /proc/modules ]]&&(( ${#modul...@]}>
0 )); then
+ stat_busy "Loading Modules"
+ /sbin/modprobe -a "${modul...@]/#\!*/}"
+ stat_done
fi
# Wait for udev uevents
Does this still work in the "null" case where there is only modules
specified with "!" in the front?
Allan
Excellent observation -- it would not. Counting the size of the array
with the PE in place isn't possible (or desirable), either. Perhaps a
more graceful solution is to reassign the output of the PE to a new
array and operate based on that. Certainly still beats calling modprobe
for every element in the array, imo.
d
I think it could be done like so:
From 6465c90fc851b12cfce791228415ae1c2823e050 Mon Sep 17 00:00:00 2001
From: Kurt J. Bosch
Date: Mon, 20 Sep 2010 17:31:54 +0200
Subject: [PATCH] rc.sysinit: only call modprobe once (as proposed by
Dave Reisner)
---
rc.sysinit |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 09d5e97..07b3f67 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -92,13 +92,10 @@ if /bin/pidof -o %PPID /sbin/udevd>/dev/null; then
fi
# Load modules from the MODULES array defined in rc.conf
-if [[ $load_modules != off&& -f /proc/modules ]]; then
+modules=$( echo ${MODULES[*]/\!*/} )
+if [[ $modules&& $load_modules != off&& -f /proc/modules ]]; then
stat_busy "Loading Modules"
-for mod in "${modul...@]}"; do
- if [[ $mod = ${mod#!} ]]; then
- /sbin/modprobe $mod
- fi
-done
+/sbin/modprobe -a $modules
stat_done
fi
--
1.7.0.3
Your echo is redundant. Just quote the expansion and assign it.
NAK. Try this:
MODULES=( '!foo' '!bar' )
modules="${modul...@]/#\!*}"
[[ $modules ]] && echo "'$modules' is not a null string"
' ' is not a null string
modules="${modul...@]/#\!*}"
I think we're a long way away from the day when there's a '!' as
part of a module name, but I think it's probably best to anchor the
expression to the start of each element regardless.
OK, but the quotes aren't needed because word splitting is not performed
here. So we finally get:
modules=$( echo ${modul...@]/#\!*} )
--
Kurt
Re: [arch-general] [PATCH] rc.sysinit: only call modprobe once
2010-09-20 04:10, Dave Reisner:
On Mon, Sep 20, 2010 at 11:57:06AM +1000, Allan McRae wrote:
On 20/09/10 11:54, Dave Reisner wrote:
Use modprobe -a and a bash PE to filter the MODULES array.
Signed-off-by: Dave Reisner
---
rc.sysinit | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 09d5e97..4b6e1e7 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -92,14 +92,10 @@ if /bin/pidof -o %PPID /sbin/udevd>/dev/null; then
fi
# Load modules from the MODULES array defined in rc.conf
-if [[ $load_modules != off&& -f /proc/modules ]]; then
-stat_busy "Loading Modules"
-for mod in "${modul...@]}"; do
- if [[ $mod = ${mod#!} ]]; then
- /sbin/modprobe $mod
- fi
-done
-stat_done
+if [[ $load_modules != off&& -f /proc/modules ]]&& (( ${#modul...@]}> 0
)); then
+ stat_busy "Loading Modules"
+ /sbin/modprobe -a "${modul...@]/#\!*/}"
+ stat_done
fi
# Wait for udev uevents
Does this still work in the "null" case where there is only modules
specified with "!" in the front?
Allan
Excellent observation -- it would not. Counting the size of the array
with the PE in place isn't possible (or desirable), either. Perhaps a
more graceful solution is to reassign the output of the PE to a new
array and operate based on that. Certainly still beats calling modprobe
for every element in the array, imo.
d
I think it could be done like so:
From 6465c90fc851b12cfce791228415ae1c2823e050 Mon Sep 17 00:00:00 2001
From: Kurt J. Bosch
Date: Mon, 20 Sep 2010 17:31:54 +0200
Subject: [PATCH] rc.sysinit: only call modprobe once (as proposed by
Dave Reisner)
---
rc.sysinit |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 09d5e97..07b3f67 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -92,13 +92,10 @@ if /bin/pidof -o %PPID /sbin/udevd >/dev/null; then
fi
# Load modules from the MODULES array defined in rc.conf
-if [[ $load_modules != off && -f /proc/modules ]]; then
+modules=$( echo ${MODULES[*]/\!*/} )
+if [[ $modules && $load_modules != off && -f /proc/modules ]]; then
stat_busy "Loading Modules"
-for mod in "${modul...@]}"; do
- if [[ $mod = ${mod#!} ]]; then
- /sbin/modprobe $mod
- fi
-done
+/sbin/modprobe -a $modules
stat_done
fi
--
1.7.0.3
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
2010-09-01 17:29, Victor Lowther: Bash globbing cannot handle it, but bash knows how to test file timestamps, so we could code something up that handles killing the daemons in reverse timestamp order if we had to. ls -l --full-time healthd fancontrol -rw-r--r-- 1 root root 0 2010-09-02 00:51:28.680006529 +0200 fancontrol -rw-r--r-- 1 root root 0 2010-09-02 00:51:28.736673174 +0200 healthd [[ healthd -nt fancontrol || healthd -ot fancontrol ]] || echo equal equal It appears as if bash doesn't recognise fractions of a second :/
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
2010-09-01 22:52, Dave Reisner: On Wed, Sep 01, 2010 at 07:30:45PM +0200, Kurt J. Bosch wrote: 2010-09-01 13:03, Dave Reisner: The _current_ behavior doesn't define an order unless its in DAEMONS. I've reverted _your_ behavior, which I don't feel has proper justification. I referred to extras/initscripts which indeed does. Please read the code: http://projects.archlinux.org/initscripts.git/tree/rc.shutdown?id=2010.07-1 Indeed, I was mistaken. However, I still stand by the idea that trying to parse the output of /bin/ls is flawed from the ground up. ls is made for human parsing, not programatical parsing. Suppose I start daemons foo, bar and baz (in that order) after Arch boots. Why then, should the shutdown order of these daemons change merely because I had to restart bar, which is independent of foo and baz? Because you know which is the right order and rc.shutdown just rolls back what you did. ^^ No, rc.shutdown does _not_ know the right order. The current behavior is broken. Example: 1) start network 2) start rpcbind 3) start nfs-common 4) restart network network now shuts down first, rendering the OS unable to cleanly close any outstanding nfs shares. This commonly results in a long hang at shutdown and the possibility of truncated files. That's exactly what I meant. _You_ should now what you're doing and rc.shutdown tries its best afterwards. There is no real daemons dependency handling in Arch (probably because of KISS) so we can't expect it does always the right thing, but at least without the restart it would do in your example and that's better than nothing (random order) isn't it? :)
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
2010-09-01 17:29, Victor Lowther: Bash globbing cannot handle it, but bash knows how to test file timestamps, so we could code something up that handles killing the daemons in reverse timestamp order if we had to. However, there is no reason to think that the order is significant for daemons not in $DAEMONS. If there are any dependencies that this code does not handle gracefully, the offending daemons will be killed when we kill -15 and then kill -9 the rest of the processes. If a daemon does not handle SIGTERM gracefully because of dependency issues, it has other, more significant problems. I really don't know if this 'feature' is actually still wanted or needed, but I feel it should be dropped in a separate commit if ever. :)
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
2010-09-01 13:03, Dave Reisner: The _current_ behavior doesn't define an order unless its in DAEMONS. I've reverted _your_ behavior, which I don't feel has proper justification. I referred to extras/initscripts which indeed does. Please read the code: http://projects.archlinux.org/initscripts.git/tree/rc.shutdown?id=2010.07-1 Suppose I start daemons foo, bar and baz (in that order) after Arch boots. Why then, should the shutdown order of these daemons change merely because I had to restart bar, which is independent of foo and baz? Because you know which is the right order and rc.shutdown just rolls back what you did. ^^
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
2010-08-31 13:16, Dave Reisner:
On Tue, Aug 31, 2010 at 10:07:52AM +0200, Kurt J. Bosch wrote:
--snip--
I suggest:
From b202be97f8dc1c0c68aaea792d4457c674c673f3 Mon Sep 17 00:00:00 2001
From: Kurt J. Bosch
Date: Tue, 31 Aug 2010 09:57:47 +0200
Subject: [PATCH 17/17] Correct behaviour of kill_everything()
---
functions | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/functions b/functions
index b9ba718..3ca7324 100644
--- a/functions
+++ b/functions
@@ -205,10 +205,9 @@ ck_status() {
kill_everything() {
# $1 = where we are being called from.
# This is used to determine which hooks to run.
-# Find daemons NOT in the DAEMONS array. Shut these down first
-for daemon in /var/run/daemons/*; do
-[[ -f $daemon ]] || continue
-daemon=${daemon##*/}
+# Find daemons NOT in the DAEMONS array.
+# Shut these down first in reverse order.
+for daemon in $( /bin/ls -t /var/run/daemons ); do
in_array "$daemon" "${daemo...@]}" || stop_daemon "$daemon"
done
@@ -220,7 +219,7 @@ kill_everything() {
# Terminate all processes
stat_busy "Sending SIGTERM To Processes"
-run_hook "$1_prekillall"
+run_hook "${1}_prekillall"
/sbin/killall5 -15&> /dev/null
/bin/sleep 5
stat_done
@@ -230,7 +229,7 @@ kill_everything() {
/bin/sleep 1
stat_done
-run_hook "$1_postkillall"
+run_hook "${1}_postkillall"
}
activate_vgs() {
--
1.7.0.3
Parsing the output of ls will never be better than using shell globbing
no matter how much simpler it might make the code appear to be. Not only
are you avoiding a fork, but the shell glob will properly handle any odd
characters thrown into the mix. You'll see breakage on something as
simple as a space in your suggestion. While I'm inclined to believe that
there will never be a space in the name of a daemon in Arch, if we're
going for pure Bash in this rewrite, let's use Bash instead of
mindlessly forking.
NAK. The patch just reverts breaking of the current behaviour which is
shutdown daemons in reverse order of start. AFAIK bash globbing is
unable to sort on timestamps, right? p
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
2010-07-02 11:27, Thomas Bächler:
First of all, sorry for not continuing the review yesterday, time is
short :(
Still, I'll finish this, as I'd like to have this applied eventually.
Am 02.07.2010 11:21, schrieb Kurt J. Bosch:
Am 2010-06-30 23:47, schrieb Victor Lowther:
Move that shared code into functions.
+run_hook single_prekillall
This line should be run_hook "${0##*/rc.}"_prekillall IMHO
Kurt is right here. We call this code from rc.single and rc.shutdown I
think. We use two distinct hooks, you can register functions for these
hooks independently!
Hmm, git bashification-redux has now:
kill_everything() {
# $1 = where we are being called from.
# This is used to determine which hooks to run.
# Find daemons NOT in the DAEMONS array. Shut these down first
for daemon in /var/run/daemons/*; do
[[ -f $daemon ]] || continue
daemon=${daemon##*/}
in_array "$daemon" "${daemo...@]}" || stop_daemon "$daemon"
done
# Shutdown daemons in reverse order
for ((i=${#daemo...@]}-1; i>=0; i--)); do
[[ ${DAEMONS[$i]:0:1} = '!' ]] && continue
ck_daemon ${daemons[$...@} || stop_daemon ${daemons[$...@}
done
# Terminate all processes
stat_busy "Sending SIGTERM To Processes"
run_hook "$1_prekillall"
/sbin/killall5 -15 &> /dev/null
/bin/sleep 5
stat_done
stat_busy "Sending SIGKILL To Processes"
/sbin/killall5 -9 &> /dev/null
/bin/sleep 1
stat_done
run_hook "$1_postkillall"
}
I suggest:
From b202be97f8dc1c0c68aaea792d4457c674c673f3 Mon Sep 17 00:00:00 2001
From: Kurt J. Bosch
Date: Tue, 31 Aug 2010 09:57:47 +0200
Subject: [PATCH 17/17] Correct behaviour of kill_everything()
---
functions | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/functions b/functions
index b9ba718..3ca7324 100644
--- a/functions
+++ b/functions
@@ -205,10 +205,9 @@ ck_status() {
kill_everything() {
# $1 = where we are being called from.
# This is used to determine which hooks to run.
-# Find daemons NOT in the DAEMONS array. Shut these down first
-for daemon in /var/run/daemons/*; do
-[[ -f $daemon ]] || continue
-daemon=${daemon##*/}
+# Find daemons NOT in the DAEMONS array.
+# Shut these down first in reverse order.
+for daemon in $( /bin/ls -t /var/run/daemons ); do
in_array "$daemon" "${daemo...@]}" || stop_daemon "$daemon"
done
@@ -220,7 +219,7 @@ kill_everything() {
# Terminate all processes
stat_busy "Sending SIGTERM To Processes"
-run_hook "$1_prekillall"
+run_hook "${1}_prekillall"
/sbin/killall5 -15 &> /dev/null
/bin/sleep 5
stat_done
@@ -230,7 +229,7 @@ kill_everything() {
/bin/sleep 1
stat_done
-run_hook "$1_postkillall"
+run_hook "${1}_postkillall"
}
activate_vgs() {
--
1.7.0.3
Re: [arch-general] [PATCH] restrict NETWORK_PERSIST to runlevel 0 and 6
2010-08-22 18:50, Florian Pritz:
Signed-off-by: Florian Pritz
---
network |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/network b/network
index 977e81e..1f3d3db 100755
--- a/network
+++ b/network
@@ -233,7 +233,7 @@ case "$1" in
# exit
#fi
- if [ "${NETWORK_PERSIST}" = "yes" -o "${NETWORK_PERSIST}" =
"YES" ]; then
+ if [ "${NETWORK_PERSIST}" = "yes" -o "${NETWORK_PERSIST}" = "YES"
]&& [[ $RUNLEVEL == [06] ]] ; then
status "Skipping Network Shutdown" true
exit 0
fi
Looks good to me now apart the white space coding style could be fixed:
if [ "${NETWORK_PERSIST}" = "yes" -o "${NETWORK_PERSIST}" = "YES" ] &&
[[ $RUNLEVEL == [06] ]]; then
Maybe you should file a bug report?
--
Kurt
Re: [arch-general] [PATCH] restrict NETWORK_PERSIST to runlevel 0 and 6
Am 2010-08-22 17:52, schrieb Florian Pritz:
On 22.08.2010 17:49, Kurt J. Bosch wrote:
Am 2010-08-22 17:40, schrieb Kurt J. Bosch:
if [[ ${NETWORK_PERSIST,,} = yes&& $RUNLEVEL == [06] ]] ; then
would look a bit nicer IMHO :)
... and RUNLEVEL PREVLEVEL should already be marked for export.
Well I haven't tested that, but I can't access them from my X or tty
session so I guess they aren't.
That is because you try from within a login shell which sets up its own
environment AFAIK. I wrote the scripts for fbsplash and fbsplash-extras
which use these variables with stock initscripts.
Re: [arch-general] [PATCH] restrict NETWORK_PERSIST to runlevel 0 and 6
Am 2010-08-22 17:40, schrieb Kurt J. Bosch:
if [[ ${NETWORK_PERSIST,,} = yes && $RUNLEVEL == [06] ]] ; then
would look a bit nicer IMHO :)
... and RUNLEVEL PREVLEVEL should already be marked for export.
Re: [arch-general] [PATCH] restrict NETWORK_PERSIST to runlevel 0 and 6
if [[ ${NETWORK_PERSIST,,} = yes && $RUNLEVEL == [06] ]] ; then
would look a bit nicer IMHO :)
Re: [arch-general] [PATCH] restrict NETWORK_PERSIST to runlevel 0 and 6
if [[ ${NETWORK_PERSIST,,} = yes && $RUNLEVEL = [06] ]] ; then
would look a bit nicer IMHO :)
Re: [arch-general] [PATCH 28/48] Use bash-style conditionals when setting up the hardware clock.
On 2010-08-19 23:12, Victor Lowther wrote: On Aug 19, 2010 10:08 AM, "Kurt J. Bosch" wrote: On 2010-08-19 10:19, Jan de Groot wrote: On Thu, 2010-08-19 at 00:56 -0400, Dave Reisner wrote: Couldn't we avoid all this by just flipping a switch in the kernel? CONFIG_RTC_DRV_CMOS=y If it's compiled into the kernel, udev picks it up and creates the /dev nodes for us. Which still locks out the people who use a custom kernel with this driver compiled as module. IMHO the init scripts should work with both module and built-in. So why not let udev do the job? Patch below. I modified my initcpio to get rid of the devtmpfs. A ls -l /dev/rtc* added between the new /sbin/udevadm settle and the initial clock setting showed /dev/rtc0 and /dev/rtc -> rtc0. So I think this should work. I did *not* move the sysinit_udevlaunched hook together with udev start to avoid insane creation times of dev nodes because this hook is used for some early udev triggering in fbsplash-extras (AUR). Patch against bashification-redux: From 22d410a2566964d58752d443a1312a6eb552660a Mon Sep 17 00:00:00 2001 From: Kurt J. Bosch Date: Thu, 19 Aug 2010 16:46:23 +0200 Subject: [PATCH 17/17] Correct rtc dev nodes creation using udev --- rc.sysinit | 22 +++--- 1 files changed, 7 insertions(+), 15 deletions(-) diff --git a/rc.sysinit b/rc.sysinit index 4421def..2415967 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -46,6 +46,12 @@ else /bin/dmesg -n 3 fi +echo> /proc/sys/kernel/hotplug + +stat_busy "Starting UDev Daemon" +/sbin/udevd --daemon +stat_done + HWCLOCK_PARAMS="--hctosys" case $HARDWARECLOCK in UTC) HWCLOCK_PARAMS+=" --utc";; @@ -56,15 +62,7 @@ esac if [[ $HWCLOCK_PARAMS ]]; then # enable rtc access /sbin/modprobe -q -a rtc-cmos rtc genrtc - # If devtmpfs is used, the required RTC device already exists now - # Otherwise, create whatever device is available - if ! [[ -c /dev/rtc || -c /dev/rtc0 ]]; then - for dev in /sys/class/rtc/rtc0/dev /sys/class/misc/rtc/dev; do - [[ -e $dev ]] || continue - IFS=: read -r major minor< "$dev" - /bin/mknod /dev/rtc c $major $minor - done - fi + /sbin/udevadm settle # Do a clock set here for a few reasons: # 1. Make creation time on udev nodes sane (FS#8665) @@ -79,12 +77,6 @@ if [[ $HWCLOCK_PARAMS ]]; then fi fi -echo> /proc/sys/kernel/hotplug - -stat_busy "Starting UDev Daemon" -/sbin/udevd --daemon -stat_done - run_hook sysinit_udevlaunched # Trigger udev uevents -- 1.7.2.1 > I like this one the best. > > Sent from my Nexus One. Sorry for top posting. > Corrected Hmm, the patch might break things with custom non modular kernels without devtmpfs though. No modules loading no uevents and no dev nodes. On the other hand reading the hwclock man page, I'm a bit uncertain whether that piece will ever use /dev/rtc0 without a symlink from /dev/rtc. Instead it might actually fall back to direct I/O with the current code and with the patched one too. Moreover I found a couple of interesting things: * The system clock is already set (by the kernel - in spite of CONFIG_RTC_HCTOSYS not set) even without doing anything. Weird, but with UTC hardware clock I even get correct mtimes in early user space. * man hwclock: > −−systz > Reset the System Time based on the current timezone. > ... > This is an alternate option to −−hctosys that does not read the > hardware clock, and may be used in system startup scripts for recent > 2.6 kernels where you know the System Time contains the Hardware > Clock time. I switched my hardware clock to localtime, reverted my patch and modified rc.sysinit to use −systz instead of --hctosys for the first hwclock call and also disabled the entire rtc modprobe and mknod code. A date command inserted for testing spit out the correct time. From the util-linux-ng list: > Indeed, we may be running hwclock --systz before /dev is mounted. Getting rid of the pre fsck hwclock --hctosys would also on the average save another half second of boot up time beside removing some ugly code. AFAIKS we can go one of three ways: * Use udev expecting CONFIG_RTC_DRV_CMOS=m or fall back to direct I/O * Use −−systz, drop the ugly code and expect some help from the kernel * Use an even more ugly code creating the missing symlink: Corrected non udev patch against bashification-redux: From 4e5d6a763af8f45c63ad53aa99b82246f90c0b43 Mon Sep 17 00:00:00 2001 From: Kurt J. Bosch Date: Fri, 20 Aug 2010 09:04:46 +0200 Subject: [PATCH 17/17] Really correct rtc dev nodes creation --- rc.sysinit | 15 +-- 1 files changed, 9 insertions(+), 6 deletions(-) diff --git a/rc.sysinit b/rc.sysinit index 4421def..1ff37cc 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -58,12 +58,15 @@ if [[ $HWCLOCK_PARAMS ]]; then /sbin/modprobe -q -a rtc-cmos rtc genrtc # If devtmpfs is used, the required RTC device already exists now
Re: [arch-general] [PATCH 28/48] Use bash-style conditionals when setting up the hardware clock.
Am 2010-08-19 06:23, schrieb Victor Lowther:
I am missing the difference. Diff please?
/dev/rtc vs. /dev/{rtc,rtc0} as already said in the other replies.
Patch against bashification-redux:
From 5d3ac218c3e05bf9735bb49826bee0b393418699 Mon Sep 17 00:00:00 2001
From: Kurt J. Bosch
Date: Thu, 19 Aug 2010 18:17:01 +0200
Subject: [PATCH 17/17] Correct rtc dev nodes creation
---
rc.sysinit |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 4421def..9fb10af 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -59,10 +59,10 @@ if [[ $HWCLOCK_PARAMS ]]; then
# If devtmpfs is used, the required RTC device already exists now
# Otherwise, create whatever device is available
if ! [[ -c /dev/rtc || -c /dev/rtc0 ]]; then
-for dev in /sys/class/rtc/rtc0/dev /sys/class/misc/rtc/dev; do
-[[ -e $dev ]] || continue
- IFS=: read -r major minor < "$dev"
- /bin/mknod /dev/rtc c $major $minor
+ for dev in /sys/class/rtc/rtc0 /sys/class/misc/rtc; do
+ [[ -e $dev/dev ]] || continue
+ IFS=: read -r major minor< "$dev/dev"
+ /bin/mknod /dev/${dev##*/} c $major $minor
done
fi
--
1.7.2.1
Re: [arch-general] [PATCH 28/48] Use bash-style conditionals when setting up the hardware clock.
Am 2010-08-19 10:19, schrieb Jan de Groot: On Thu, 2010-08-19 at 00:56 -0400, Dave Reisner wrote: Couldn't we avoid all this by just flipping a switch in the kernel? CONFIG_RTC_DRV_CMOS=y If it's compiled into the kernel, udev picks it up and creates the /dev nodes for us. Which still locks out the people who use a custom kernel with this driver compiled as module. IMHO the init scripts should work with both module and built-in. So why not let udev do the job? Patch below. I modified my initcpio to get rid of the devtmpfs. A ls -l /dev/rtc* added between the new /sbin/udevadm settle and the initial clock setting showed /dev/rtc0 and /dev/rtc -> rtc0. So I think this should work. I did *not* move the sysinit_udevlaunched hook together with udev start to avoid insane creation times of dev nodes because this hook is used for some early udev triggering in fbsplash-extras (AUR). Patch against bashification-redux: From 22d410a2566964d58752d443a1312a6eb552660a Mon Sep 17 00:00:00 2001 From: Kurt J. Bosch Date: Thu, 19 Aug 2010 16:46:23 +0200 Subject: [PATCH 17/17] Correct rtc dev nodes creation using udev --- rc.sysinit | 22 +++--- 1 files changed, 7 insertions(+), 15 deletions(-) diff --git a/rc.sysinit b/rc.sysinit index 4421def..2415967 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -46,6 +46,12 @@ else /bin/dmesg -n 3 fi +echo > /proc/sys/kernel/hotplug + +stat_busy "Starting UDev Daemon" +/sbin/udevd --daemon +stat_done + HWCLOCK_PARAMS="--hctosys" case $HARDWARECLOCK in UTC) HWCLOCK_PARAMS+=" --utc";; @@ -56,15 +62,7 @@ esac if [[ $HWCLOCK_PARAMS ]]; then # enable rtc access /sbin/modprobe -q -a rtc-cmos rtc genrtc - # If devtmpfs is used, the required RTC device already exists now - # Otherwise, create whatever device is available - if ! [[ -c /dev/rtc || -c /dev/rtc0 ]]; then -for dev in /sys/class/rtc/rtc0/dev /sys/class/misc/rtc/dev; do -[[ -e $dev ]] || continue - IFS=: read -r major minor < "$dev" - /bin/mknod /dev/rtc c $major $minor - done - fi + /sbin/udevadm settle # Do a clock set here for a few reasons: # 1. Make creation time on udev nodes sane (FS#8665) @@ -79,12 +77,6 @@ if [[ $HWCLOCK_PARAMS ]]; then fi fi -echo > /proc/sys/kernel/hotplug - -stat_busy "Starting UDev Daemon" -/sbin/udevd --daemon -stat_done - run_hook sysinit_udevlaunched # Trigger udev uevents -- 1.7.2.1
Re: [arch-general] [PATCH 28/48] Use bash-style conditionals when setting up the hardware clock.
Am 2010-06-30 23:47, schrieb Victor Lowther:
Trying to stick with POSIX syntax only just slows things down.
---
rc.sysinit | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 29adeca..f3e60b7 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -44,27 +44,22 @@ fi
HWCLOCK_PARAMS="--hctosys"
case $HARDWARECLOCK in
-UTC) "$HWCLOCK_PARAMS --utc";;
-localtime) HWCLOCK_PARAMS="$HWCLOCK_PARAMS --localtime";;
+UTC) HWCLOCK_PARAMS+=" --utc";;
+localtime) HWCLOCK_PARAMS+=" --localtime";;
*) HWCLOCK_PARAMS="";;
esac
-if [ -n "$HWCLOCK_PARAMS" ]; then
+if [[ $HWCLOCK_PARAMS ]]; then
# enable rtc access
- /sbin/modprobe -q rtc-cmos
- # some custom kernels use rtc/genrtc, try to load those too
- /sbin/modprobe -q rtc
- /sbin/modprobe -q genrtc
+ /sbin/modprobe -q -a rtc-cmos rtc genrtc
# If devtmpfs is used, the required RTC device already exists now
# Otherwise, create whatever device is available
- if [ ! -c /dev/rtc -a ! -c /dev/rtc0 ]; then
- if [ -f /sys/class/rtc/rtc0/dev ]; then
- IFS=: read -r major minor< /sys/class/rtc/rtc0/dev
- /bin/mknod /dev/rtc0 c $major $minor
- elif [ -f /sys/class/misc/rtc/dev ]; then
- IFS=: read -r major minor< /sys/class/misc/rtc/dev
- /bin/mknod /dev/rtc c $major $minor
- fi
+ if ! [[ -c /dev/rtc || -c /dev/rtc0 ]]; then
+for dev in /sys/class/rtc/rtc0/dev /sys/class/misc/rtc/dev; do
+[[ -e $dev ]] || continue
+ IFS=: read -r major minor< "$dev"
+ /bin/mknod /dev/rtc c $major $minor
+ done
fi
Actually this doesn't do the same. What about the following?
if ! [[ -c /dev/rtc || -c /dev/rtc0 ]]; then
for dev in /sys/class/rtc/rtc0 /sys/class/misc/rtc; do
[[ -e $dev/dev ]] || continue
IFS=: read -r major minor< "$dev/dev"
/bin/mknod /dev/${dev##*/} c $major $minor
done
fi
Re: [arch-general] lcms - needs upgrade because of security
Am 2010-08-14 23:10, schrieb Xavier Chantry: On Sat, Aug 14, 2010 at 9:54 PM, Kurt J. Bosch wrote: Am 2010-08-14 21:48, schrieb Laurent Carlier: You should fill a bugreport as there is security issues No. Last time I did this it was rejected - http://bugs.archlinux.org/task/10679 That reject was plain wrong, we should encourage users to give visibility to security updates. However that was 2 years ago, so please let me know if this happens again. http://bugs.archlinux.org/task/20483
Re: [arch-general] lcms - needs upgrade because of security
Am 2010-08-14 23:10, schrieb Xavier Chantry: On Sat, Aug 14, 2010 at 9:54 PM, Kurt J. Bosch wrote: Am 2010-08-14 21:48, schrieb Laurent Carlier: You should fill a bugreport as there is security issues No. Last time I did this it was rejected - http://bugs.archlinux.org/task/10679 That reject was plain wrong, Hmm, what about http://bugs.archlinux.org/ -> http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines -> Reasons_for_not_being_a_bug -> "A bug already fixed upstream but not in Arch because the package is not up-to-date." then ? > we should encourage users to give visibility to security updates. I agree, you should. However that was 2 years ago, so please let me know if this happens again. I also violated the bug guidelines with FS# 20475, 20476 and 20477 yesterday, but two of them are already fixed now. So I will give it a try.
Re: [arch-general] lcms - needs upgrade because of security
Am 2010-08-14 21:48, schrieb Laurent Carlier: You should fill a bugreport as there is security issues No. Last time I did this it was rejected - http://bugs.archlinux.org/task/10679 - but I filed three other including patches right before I wrote about this one here. :)
[arch-general] lcms - needs upgrade because of security
Hi, package lcms in extra is out of date for a long time now. Please upgrade at least to 1.19 to solve security issues: Multiple errors in LittleCMS allow for attacks including the remote execution of arbitrary code. http://www.gentoo.org/security/en/glsa/glsa-200904-19.xml -- kujub
Re: [arch-general] Bashification of initscripts for moderate speedup
2010-06-28 05:10, Victor Lowther: You can browse changes I have made in the git repo @ http://git.fnordovax.org/arch-initscripts/log/?h=bashification The feed link appears broken to me. href='http://git.fnordovax.orghttp://git.fnordovax.org/arch-initscripts/atom/?h=bashification' type='application/atom+xml'/> -- kujub (whining)
Re: [arch-general] [PATCH 45/48] Sleep instead of rebooting or shutting down when debugging initscripts
Am 2010-06-30 23:47, schrieb Victor Lowther:
---
functions |2 +-
rc.shutdown |3 +++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/functions b/functions
index f1dce8a..2c80a59 100644
--- a/functions
+++ b/functions
@@ -4,7 +4,7 @@
# width:
-grep -q initdebug&& {
+grep -q initdebug /proc/cmdline&& {
exec 2>/dev/tty9
}
OK that fixes the stdin problem :) - but /proc won't be mounted when
this is sourced in rc.sysinit if someone doesn't use an initcpio.
diff --git a/rc.shutdown b/rc.shutdown
index 1081970..96b10f0 100755
--- a/rc.shutdown
+++ b/rc.shutdown
@@ -93,6 +93,9 @@ run_hook shutdown_poweroff
# Power off or reboot
printsep
+
+grep -q initdebug /proc/cmdline&& sleep
+
if [[ $RUNLEVEL = 0 ]]; then
printhl "${C_H2}POWER OFF"
/sbin/poweroff -d -f -h -i
Re: [arch-general] [PATCH 44/48] Save error messages to /dev/tty9.
Am 2010-06-30 23:47, schrieb Victor Lowther:
---
functions |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/functions b/functions
index 9ec8b5e..f1dce8a 100644
--- a/functions
+++ b/functions
@@ -4,6 +4,10 @@
# width:
+grep -q initdebug&& {
+exec 2>/dev/tty9
+}
+
Hmm, won't this cause a read from stdin when starting/stopping daemons
manually in a terminal?
STAT_COL=80
if [[ ! -t 1 ]]; then
USECOLOR=""
Re: [arch-general] [PATCH 21/48] Both rc.single and rc.shutdown use the same code to kill everything.
Am 2010-06-30 23:47, schrieb Victor Lowther:
Move that shared code into functions.
---
functions | 29 +
rc.shutdown | 32 +---
rc.single | 27 +--
3 files changed, 31 insertions(+), 57 deletions(-)
diff --git a/functions b/functions
index d8e8e54..bf6ed45 100644
--- a/functions
+++ b/functions
@@ -203,6 +203,35 @@ ck_status() {
fi
}
+kill_everything() {
+# Find daemons NOT in the DAEMONS array. Shut these down first
+for daemon in /var/run/daemons/*; do
+[[ -f $daemon ]] || continue
+daemon=${daemon##*/}
+ in_array "$daemon" "${daemo...@]}" || stop_daemon "$daemon"
+done
+
+# Shutdown daemons in reverse order
+for ((i=${#daemo...@]}-1; i>=0; i--)); do
+ [[ ${DAEMONS[$i]:0:1} = '!' ]]&& continue
+ ck_daemon ${daemons[$...@} || stop_daemon ${daemons[$...@}
+done
+
+ # Terminate all processes
+stat_busy "Sending SIGTERM To Processes"
+run_hook single_prekillall
This line should be run_hook "${0##*/rc.}"_prekillall IMHO
+/sbin/killall5 -15&> /dev/null
+/bin/sleep 5
+stat_done
+
+stat_busy "Sending SIGKILL To Processes"
+/sbin/killall5 -9&> /dev/null
+/bin/sleep 1
+stat_done
+
+run_hook single_postkillall
Similar as above.
+}
+
###
# Custom hooks in initscripts #
###
diff --git a/rc.shutdown b/rc.shutdown
index 002a45d..ef9b16d 100755
--- a/rc.shutdown
+++ b/rc.shutdown
@@ -19,37 +19,7 @@ echo " "
[[ -x /bin/domainname ]]&& /bin/domainname ""
[[ -x /etc/rc.local.shutdown ]]&& /etc/rc.local.shutdown
-
-# Find daemons NOT in the DAEMONS array. Shut these down first
-if [ -d /var/run/daemons ]; then
- for daemon in $(/bin/ls -1t /var/run/daemons); do
- if ! in_array $daemon ${daemo...@]}; then
- stop_daemon $daemon
- fi
- done
-fi
-# Shutdown daemons in reverse order
-let i=${#daemo...@]}-1
-while [ $i -ge 0 ]; do
- if [ "${DAEMONS[$i]:0:1}" != '!' ]; then
- ck_daemon ${daemons[$...@} || stop_daemon ${daemons[$...@}
- fi
- let i=i-1
-done
-
-# Terminate all processes
-stat_busy "Sending SIGTERM To Processes"
-run_hook shutdown_prekillall
-/sbin/killall5 -15&> /dev/null
-/bin/sleep 5
-stat_done
-
-stat_busy "Sending SIGKILL To Processes"
-/sbin/killall5 -9&> /dev/null
-/bin/sleep 1
-stat_done
-
-run_hook shutdown_postkillall
+kill_everything
stat_busy "Saving Random Seed"
RANDOM_SEED=/var/lib/misc/random-seed
diff --git a/rc.single b/rc.single
index aa27be0..a84ece8 100755
--- a/rc.single
+++ b/rc.single
@@ -9,33 +9,8 @@
run_hook single_start
if [[ $PREVLEVEL != N ]]; then
-# Find daemons NOT in the DAEMONS array. Shut these down first
-for daemon in /var/run/daemons/*; do
-[[ -f $daemon ]] || continue
-daemon=${daemon##*/}
- in_array "$daemon" "${daemo...@]}" || stop_daemon "$daemon"
-done
-
-# Shutdown daemons in reverse order
-for ((i=${#daemo...@]}-1; i>=0; i--)); do
- [[ ${DAEMONS[$i]:0:1} = '!' ]]&& continue
- ck_daemon ${daemons[$...@} || stop_daemon ${daemons[$...@}
-done
-
- # Terminate all processes
- stat_busy "Sending SIGTERM To Processes"
- run_hook single_prekillall
- /sbin/killall5 -15&> /dev/null
- /bin/sleep 5
- stat_done
-
- stat_busy "Sending SIGKILL To Processes"
- /sbin/killall5 -9&> /dev/null
- /bin/sleep 1
- stat_done
-
- run_hook single_postkillall
+kill_everything
stat_busy "Starting UDev Daemon"
/sbin/udevd --daemon
stat_done
Re: [arch-general] Hibernation
Am 2010-06-07 15:58, schrieb Ng Oon-Ee: On Mon, 2010-06-07 at 19:09 +0530, Nilesh Govindarajan wrote: The wiki article says I need a swap partition, is not possible with a swap file ? My disk setup: disk0: / 10 GB ext4 + 30 GB LVM disk1: 160 GB LVM swap is on LVM 500 MB. As previously mentioned, if you want a swap file you need TOI, which involves a patched kernel. ... or uswsusp, or uswsusp-fbsplash from AUR which even support compression ;)
Re: [arch-general] A little weirdness at boot time
Heiko Baums wrote: But it's not that easy with evdev devices like mouse and remote control. Unfortunately flyspray is still down. But the /dev/input/eventX bug with the inconsistent device naming for the mouse and the IR remote control is back since the latest initscripts update to 2009.08-1, even if the device naming is not switching at every reboot this time. Sometimes (usually) the mouse is /dev/input/event5 and the remote control is /dev/input/event4 and sometimes it's vice versa. Here is my /etc/conf.d/lircd - maybe it helps in your case too (: ## Configuration for Technisat USB remote TTS35AI LIRC_DRIVER="devinput" ## Using dev/input device by name (description) ## because event device node my change. ## To get the 'name' for your USB device ## look at dmesg|tail after pluging it in for a line like: ## input: USB IR Receiver USB IR Receiver as ## /devices/pci:00/:00:10.0/usb1/1-2/1-2:1.0/input/input8 ## or use cat /proc/bus/input/devices ## Make shure you have -d "$LIRC_DEVICE" (with quotes !) in your ## init script because of blanks! LIRC_DEVICE="name=USB IR Receiver USB IR Receiver" LIRC_EXTRAOPTS="" LIRC_CONFIGFILE=""
Re: [arch-general] Firefox bug that may be Arch specific
On 2009-05-19 04:50, Emmanuel Benisty wrote: Hi List, Just for information, there has been already two bug reports in Bugzilla that mention a bug in the display size of textboxes. Until now, only Archers seems to suffer from this bug and one of the mozilla developers has marked this issue as specific to Arch. Therefore, I thought it could be interesting to let Arch developers and users to be informed about this. https://bugzilla.mozilla.org/show_bug.cgi?id=491114 Hi, i tried the URL from the first screenshot provided there with my vanilla Firefox on Arch. The textboxes look normal here.
Re: [arch-general] Policykit, uid like a service, and gid like a user
On 2009-04-28 23:42, Magnus Therning wrote: I noticed after installing policykit that it created a new user and group (both called policykit). The thing that surprised me was the uid was 102 while the uid was 1001. Should a system service like that really have a uid below 1000 (like other service accounts) and a gid above 1000 (which is what users are given). Looks to me like it might be a bug, but thought I'd get some input on it before raising my first bug against an Arch package :-) /M +1 Same here :)
Re: [arch-general] Makefile to build all packages
On 2009-04-04 15:06, Baho Utot wrote: find returns the directory entry with ./ in front of the directory name Anyone know how to make find return abs instead of ./abs man find suggests -printf %P for this :)
