The file nsdc.sh.in have a wrong line.
Old:
lock() {
(umask 222; echo "database locked bij PID: $$") >${lockfile}) ||
(cat ${lockfile} ; "echo aborting..." ; exit 1)
}
Error Message:
/usr/local/nsd/sbin/nsdc: line 56: syntax error near unexpected token `)'
/usr/local/nsd/sbin/nsdc: line 56: ` (umask 222; echo "database locked bij PID: $$") >${lockfile}) ||'
New:
lock() {
((umask 222; echo "database locked bij PID: $$") >${lockfile}) ||
(cat ${lockfile} ; "echo aborting..." ; exit 1)
}
Greet
Sebastian Schikora
[On 05 Dec, @12:15, sebastian wrote in "NSD 2.3.2 error at nsdc.sh.in ..."]
Error Message:
/usr/local/nsd/sbin/nsdc: line 56: syntax error near unexpected token `)'
/usr/local/nsd/sbin/nsdc: line 56: ` (umask 222; echo "database
locked bij PID: $$") >${lockfile}) ||'
damn! 
New:
lock() {
((umask 222; echo "database locked bij PID: $$") >${lockfile}) ||
(cat ${lockfile} ; "echo aborting..." ; exit 1)
}
thanks. For completeness, the patch is:
Index: nsdc.sh.in
sebastian wrote:
The file nsdc.sh.in have a wrong line.
Old:
lock() {
(umask 222; echo "database locked bij PID: $$") >${lockfile}) ||
(cat ${lockfile} ; "echo aborting..." ; exit 1)
}
Error Message:
/usr/local/nsd/sbin/nsdc: line 56: syntax error near unexpected token `)'
/usr/local/nsd/sbin/nsdc: line 56: ` (umask 222; echo "database locked bij PID: $$") >${lockfile}) ||'
New:
lock() {
((umask 222; echo "database locked bij PID: $$") >${lockfile}) ||
(cat ${lockfile} ; "echo aborting..." ; exit 1)
}
Even better (s/bij/by/):
lock() {
((umask 222; echo "database locked by PID: $$") >${lockfile}) ||
(cat ${lockfile} ; "echo aborting..." ; exit 1)
}
[On 05 Dec, @12:23, Ondrej Sury wrote in "Re: NSD 2.3.2 error at nsdc.sh ..."]
Even better (s/bij/by/):
lock() {
((umask 222; echo "database locked by PID: $$") >${lockfile}) ||
(cat ${lockfile} ; "echo aborting..." ; exit 1)
}
yep... I've _silently_ updated the 2.3.2 release, with these 2 fixes
added.
An extra test to the testsuite was also added.
Thanks,
grtz Miek
I'm curious.. What's the point of setting the umask before echoing
something? The way I see it the $lockfile is created by the "parent"
(i.e. not by the subshell)?
And if the umask 222 would work, would the file ever have more than 0
octets in it? As I see it, the file would be created so the shell can't
write to it.
-- robert
Why? Version numbers are cheap.
[On 06 Dec, @12:35, Michael Wood wrote in "Re: NSD 2.3.2 error at nsdc.sh ..."]
> yep... I've _silently_ updated the 2.3.2 release, with these 2
> fixes added.
Why? Version numbers are cheap.
I might do another release fairly quick. There is a possible issue
on Solaris 10. So I'm waiting to see how real that is.
To give a little peek in the short term NSD 2.3.X roadmap: 2.3.3 will
contain only a few fixes. That will give us a stable base to refactor
the sig_handler() function. This way 2.3.4 will only have this new
sig_handler and nothing else.
> > yep... I've _silently_ updated the 2.3.2 release, with these 2
> > fixes added.
>
> Why? Version numbers are cheap.
I might do another release fairly quick. There is a possible issue
on Solaris 10. So I'm waiting to see how real that is.
Please just increase the serial. Having multiple releases with the same
number is a security nightmare.
To give a little peek in the short term NSD 2.3.X roadmap: 2.3.3 will
contain only a few fixes. That will give us a stable base to refactor
the sig_handler() function. This way 2.3.4 will only have this new
sig_handler and nothing else.
Then call this next release 2.3.2.1 or something?
Paul
[On 06 Dec, @22:41, Paul Wouters wrote in "Re: NSD 2.3.2 error at nsdc.sh ..."]
> I might do another release fairly quick. There is a possible issue
> on Solaris 10. So I'm waiting to see how real that is.
Please just increase the serial. Having multiple releases with the same
number is a security nightmare.
> To give a little peek in the short term NSD 2.3.X roadmap: 2.3.3 will
> contain only a few fixes. That will give us a stable base to refactor
> the sig_handler() function. This way 2.3.4 will only have this new
> sig_handler and nothing else.
Then call this next release 2.3.2.1 or something?
No, the policy is to use the last number as a patch level. So 2.3.3
will be next (even if the changes are fairly small),
[On 06 Dec, @22:41, Paul Wouters wrote in "Re: NSD 2.3.2 error at nsdc.sh ..."]
Please just increase the serial. Having multiple releases with the same
number is a security nightmare.
To clear up any confusion I will release NSD 2.3.3 later today. This
release will include the correct patch for the locking in nsdc.
Thanks,