Mailing List Archive

Hi Dim,

yapp, I noticed this errors today, simply to much spaces in there.
Please have a look at the patch.

On Thu, 14 Dec 2000, you wrote:
> Today (14 Dec) I have downloaded the latest CVS snapshot.
> It works quit well, but at /var/log/ha-debug I have found error msg from
> datadisk script
> /etc/ha.d/resourse.d/datadisk: [: too many arguments
>
> And for datadsik stop:
> datadisk: [: !=: unary operator expected
>
>
> And also
> for question about Continue/Reboot
> any key leads to rebooting of the system with msg
> datadisk: [: too many arguments
>
> Guys !!!
> What is Postpone packet messages ?
> Why these messages come with protocol C only ?
> What should I do to eliminate messages about Postpone from my console ?

I'm also interested in the answer, I saw this messages,too, but I don't
know what they mean.

Bye,
Sven

Hi,

sorry, please forget my last patch. It's completly bullshit, sorry again.

> > datadisk: [: !=: unary operator expected
This seems to be a problem in datadisk, because setLocale wasn't called in
stop), so $SAFE never got defined. Fixed.

--- drbd/scripts/datadisk Fri Dec 15 10:21:50 2000
+++ /etc/ha.d/resource.d/datadisk Sat Dec 16 01:11:42 2000
@@ -147,6 +147,7 @@
exit $RETVAL
fi

+ setLocal $CONFIG $RESOURCE
if [ "$SAFE" != "false" ]; then
logger -t "datadisk" "Safe mode : Clean shutdown for $RESOURCE"
rm -f $STATE/"$RESOURCE"_safe 2> /dev/null


> > datadisk: [: too many arguments
Not too sure from where this error come. I assumed a problem in drbd_common,
see patch. If this doesn't fix the problem, please give me feedback.

--- drbd/scripts/drbd_common Mon Dec 11 16:08:13 2000
+++ /etc/ha.d/resource.d/drbd_common Sat Dec 16 00:48:18 2000
@@ -288,7 +288,7 @@
{
for NAME in $*
do
- if [ ! `which $NAME 2>/dev/null` ]; then
+ if ! which $NAME 1>/dev/null ; then
failed "$0 needs the command '$NAME'"
exit 1
fi

Bye, Sven

On Mon, 18 Dec 2000, you wrote:

> > + if ! which $NAME 1>/dev/null ; then

> I think you are wrong for this one. Give a try to CVS and let me know
>
> It must work. Otherwise I think
>
> + if [ ! "`which $NAME 2>/dev/null`" ]; then
>
> would be better ..
>

Hi,

hmm I think I was right, lets see ...

sunder2:~$ NAME=fuser; `which $NAME`
usage: fuser [ -a | -s ] [ -n space ] [ -signal ] [ -kimuv ] name ...

[snip, this is the normal usage information]

Fine, if the command is there, there's no problem, but

sunder2:~$ NAME=foobar; `which $NAME`
bash: which:: command not found

This is the error the surrounding test command cant handle, in contrast:
sunder2:~$ NAME=foobar; which $NAME
which: no foobar in ([searchpath])

will result in exitcode 1 which will be handled correctly by the normal if
statement.

Why do you think it should be necessary to execute the command the "which"
found ?

And, last :
sunder2:~$ NAME=foobar; if [ ! "`which $NAME 2>/dev/null`" ]; then echo "no"; else echo "yes"; fi
yes
sunder2:~$ NAME=fuser; if [ ! "`which $NAME 2>/dev/null`" ]; then echo "no"; else echo "yes"; fi
yes
sunder2:~$ NAME=foobar; if [ ! `which $NAME 2>/dev/null` ]; then echo "no"; else echo "yes"; fi
[.: too many arguments
yes
sunder2:~$ NAME=fuser; if [ ! `which $NAME 2>/dev/null` ]; then echo "no"; else echo "yes"; fi
yes

sunder2:~$ NAME=foobar; if ! which "$NAME" 1>/dev/null; then echo "no"; else echo "yes"; fi
no
sunder2:~$ NAME=fuser; if ! which "$NAME" 1>/dev/null; then echo "no"; else echo "yes"; fi
yes

I think my solution leads to the expected answer, didn't ist ?

Bye,
Sven

On Mon, Dec 18, 2000 at 09:18:44PM +0100, Sven Sunder wrote:
> On Mon, 18 Dec 2000, you wrote:
>
> > > + if ! which $NAME 1>/dev/null ; then
>
> > I think you are wrong for this one. Give a try to CVS and let me know
> >
> > It must work. Otherwise I think
> >
> > + if [ ! "`which $NAME 2>/dev/null`" ]; then
> >
> > would be better ..
> >
>
> Hi,
>
> hmm I think I was right, lets see ...
>
> sunder2:~$ NAME=fuser; `which $NAME`
> usage: fuser [ -a | -s ] [ -n space ] [ -signal ] [ -kimuv ] name ...
>
> [snip, this is the normal usage information]
>
> Fine, if the command is there, there's no problem, but
>
> sunder2:~$ NAME=foobar; `which $NAME`
> bash: which:: command not found
>
> This is the error the surrounding test command cant handle, in contrast:
> sunder2:~$ NAME=foobar; which $NAME
> which: no foobar in ([searchpath])
>
> will result in exitcode 1 which will be handled correctly by the normal if
> statement.
>
> Why do you think it should be necessary to execute the command the "which"
> found ?
>
> And, last :
> sunder2:~$ NAME=foobar; if [ ! "`which $NAME 2>/dev/null`" ]; then echo "no"; else echo "yes"; fi
> yes
> sunder2:~$ NAME=fuser; if [ ! "`which $NAME 2>/dev/null`" ]; then echo "no"; else echo "yes"; fi
> yes
> sunder2:~$ NAME=foobar; if [ ! `which $NAME 2>/dev/null` ]; then echo "no"; else echo "yes"; fi
> [.: too many arguments
> yes
> sunder2:~$ NAME=fuser; if [ ! `which $NAME 2>/dev/null` ]; then echo "no"; else echo "yes"; fi
> yes
>
> sunder2:~$ NAME=foobar; if ! which "$NAME" 1>/dev/null; then echo "no"; else echo "yes"; fi
> no
> sunder2:~$ NAME=fuser; if ! which "$NAME" 1>/dev/null; then echo "no"; else echo "yes"; fi
> yes
>
> I think my solution leads to the expected answer, didn't ist ?
>
> Bye,
> Sven

You are both scaring me. I don't think "which" is a good idea at all, not
least because it is confusing.

First, in many systems which is redefined for you as something other than
what you expect, that is, is it "/usr/bin/which" or is it "type -p".

Second, root should not be running tools that depend on path overmuch. There
are only so many places fuser could be, just use "[ -x /bin/fuser ]" which
avoids path problems.

-dg

--
David Gould dg@example.com
SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380
why would you want to own /dev/null? "ooo! ooo! look! i stole nothing!
i'm the thief of nihilism! i'm the new god of zen monks."

David Gould wrote:
>
[snip]

> You are both scaring me. I don't think "which" is a good idea at all, not
> least because it is confusing.
>
[snip]
>
> Second, root should not be running tools that depend on path overmuch. There
> are only so many places fuser could be, just use "[ -x /bin/fuser ]" which
> avoids path problems.

I agree heartily. Before networks became the main focus of security
concerns, PATH issues for root were the main way to hack a system. They're
still potent trouble sources if you're not careful.

-- Alan Robertson
alanr@example.com