Re: nagios-plugins 2.1.1 segmentation fault
+--On 10 septembre 2015 17:26:46 +0200 Albert Shih wrote: | Hi, | | I find a bug about nagios-plugins-2.1.1 I don't known if it's the | freebsd-ports version or it's about the plugins himself. Anyway if you do | a | | check_http host | | where the host didn't answer but can be reach (apache not running) you get | a Segmentation fault and a core dump. | | Easy to try | | check_http 127.0.0.1 | | Regards. Hi, I can't reproduce this: # /usr/local/libexec/nagios/check_http 127.0.0.1 HTTP OK: HTTP/1.1 301 Moved Permanently - 491 bytes in 0.001 second response time |time=0.000816s;;;0.00 size=491B;;;0 Note that using check_http that way is some old legacy way of doing it, you should run it as: # /usr/local/libexec/nagios/check_http -H 127.0.0.1 HTTP OK: HTTP/1.1 301 Moved Permanently - 491 bytes in 0.000 second response time |time=0.000367s;;;0.00 size=491B;;;0 Regards, -- Mathieu Arnold pgpJR45KuTHZ2.pgp Description: PGP signature
Looking for a commiter: Bug in Mk/Uses/pgsql.mk ?
Hi all, I have USES= pgsql:9.0+ in my port www/calendarserver . This works for me with DEFAULT_VERSIONS= pgsql=9.4 in /etc/make.conf, but users of the port report various dependency errors like - - - py27-calendarserver-5.1_3 cannot install: the port wants postgresql-client version 9.0 9.1 9.2 9.3 9.4 and you have version 9.4 installed. - - - See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201613 Please, can a committer have a look at this? Axel --- PGP-Key:29E99DD6 ☀ +49 160 9945 7889 ☀ computing @ chaos claudius ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Anyone got RethinkDB working in FreeBSD?
Hello!
http://www.rethinkdb.com/
I tried compiling it in FreeBSD 9.3, and managed
to get past configure and the start of gmake, but
then got a lot of these:
./src/errors.hpp:103:9: error: 'BREAKPOINT' was not declared in this scope
BREAKPOINT; \
^
./src/errors.hpp:123:13: note: in expansion of macro 'crash_or_trap'
crash_or_trap(format_assert_message("Guarantee", cond) msg); \
^
./src/rdb_protocol/changefeed.hpp:267:13: note: in expansion of macro
'guarantee'
guarantee(k == p.first->second.first);
^
./src/errors.hpp:103:9: error: 'BREAKPOINT' was not declared in this scope
BREAKPOINT; \
^
./src/errors.hpp:123:13: note: in expansion of macro 'crash_or_trap'
crash_or_trap(format_assert_message("Guarantee", cond) msg); \
^
./src/rdb_protocol/changefeed.hpp:269:13: note: in expansion of macro
'guarantee'
guarantee(it != index.end());
^
Any ideas how to fix this?
(Or if there is a FreeBSD port of RethinkDB in someones pipe? :) )
Thanks!
--
Peter
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
rc script problem - pidfile not being recognised
I've been trying to work on a new port and it's my first that uses an rc script
so I've been expecting a few bumps, but there's one thing I can't seem to fix
and it's a blocker. I can't stop the daemon!
It dopes create a pidfile so I have the following line in my script:
pidfile="/var/run/${name}.pid"
Alas...
# service fuglu stop
fuglu not running? (check /var/run/fuglu.pid).
# cat /var/run/fuglu.pid
24013
I don't get it. It is the right process ID:
# ps -waux | grep fuglu
nobody 24013 0.0 0.5 139532 37372 - I 3:57PM 0:01.03
/usr/local/bin/python2.7 /usr/local/bin/fuglu --pidfile /var/r
root 26179 0.0 0.0 18824 1976 0 S+4:30PM 0:00.00 grep fuglu
I'm at a loss as to what to try, I feel I'm missing something blindingly
obvious but it's a mystery to me so if anyone can wave the big red arrow at my
mistake I'd be a happy chappy!
Full fuglu.in below:
#!/bin/sh
# $FreeBSD$
#
# PROVIDE: fuglu
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add these lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# fuglu_enable (bool): Set to NO by default.
# Set it to YES to enable fuglu.
. /etc/rc.subr
name="fuglu"
rcvar=fuglu_enable
load_rc_config $name
: ${fuglu_enable:=no}
command=%%PREFIX%%/bin/${name}
pidfile="/var/run/${name}.pid"
run_rc_command "$1"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: rc script problem - pidfile not being recognised
- Original Message -
> From: "Michelle Sullivan"
> To: "Kevin Golding"
> Cc: freebsd-ports@freebsd.org
> Sent: Friday, 11 September, 2015 3:58:58 PM
> Subject: Re: rc script problem - pidfile not being recognised
>
> Kevin Golding wrote:
> > It dopes create a pidfile so I have the following line in my
> > script:
> >
> > pidfile="/var/run/${name}.pid"
> >
> > Alas...
> >
> > # service fuglu stop
> > fuglu not running? (check /var/run/fuglu.pid).
> > # cat /var/run/fuglu.pid
> > 24013
> >
> > I don't get it. It is the right process ID:
> >
> > # ps -waux | grep fuglu
> > nobody 24013 0.0 0.5 139532 37372 - I 3:57PM
> > 0:01.03 /usr/local/bin/python2.7 /usr/local/bin/fuglu
> > --pidfile /var/r
> > root 26179 0.0 0.0 18824 1976 0 S+4:30PM
> > 0:00.00 grep fuglu
> >
>
> I'd take a bet as it's running as a user the process is being called
> to
> shutdown and there is some permissions issue on the PID file (I see
> the
> same thing with bucardo when running bucardo as non root)
I did wonder about that but the pidfile is world readable:
-rw-r--r-- 1 root wheel6 Sep 11 15:57 /var/run/fuglu.pid
And certainly the process's user can read the file
# sudo -u nobody cat /var/run/fuglu.pid
24013
Which isn't to say that isn't the problem, just that if it is I think I'm even
more confused.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: rc script problem - pidfile not being recognised
On Fri, 11 Sep 2015 15:42:18 +0100 (BST) Kevin Golding wrote
> I've been trying to work on a new port and it's my first that uses an rc
> script so I've been expecting a few bumps, but there's one thing I can't seem
> to fix and it's a blocker. I can't stop the daemon!
>
> It dopes create a pidfile so I have the following line in my script:
>
> pidfile="/var/run/${name}.pid"
>
> Alas...
>
> # service fuglu stop
> fuglu not running? (check /var/run/fuglu.pid).
> # cat /var/run/fuglu.pid
> 24013
>
> I don't get it. It is the right process ID:
>
> # ps -waux | grep fuglu
> nobody 24013 0.0 0.5 139532 37372 - I 3:57PM 0:01.03
> /usr/local/bin/python2.7 /usr/local/bin/fuglu --pidfile /var/r root 26179
> 0.0 0.0 18824 1976 0 S+4:30PM 0:00.00 grep fuglu
>
> I'm at a loss as to what to try, I feel I'm missing something blindingly
> obvious but it's a mystery to me so if anyone can wave the big red arrow at
> my mistake I'd be a happy chappy!
>
> Full fuglu.in below:
>
> #!/bin/sh
>
> # $FreeBSD$
> #
> # PROVIDE: fuglu
> # REQUIRE: LOGIN
> # KEYWORD: shutdown
> #
> # Add these lines to /etc/rc.conf.local or /etc/rc.conf
> # to enable this service:
> #
> # fuglu_enable (bool):Set to NO by default.
> #Set it to YES to enable fuglu.
>
> . /etc/rc.subr
>
> name="fuglu"
> rcvar=fuglu_enable
>
> load_rc_config $name
> : ${fuglu_enable:=no}
>
> command=%%PREFIX%%/bin/${name}
> pidfile="/var/run/${name}.pid"
>
> run_rc_command "$1"
This question might have been better directed at freebsd-hackers@
but...
See if this get's it for you:
/etc/rc.subr
name=fuglu
rcvar=fuglu_enable
load_rc_config $name
: ${fuglu_enable="NO"}
: ${fuglu_pidfile="/var/run/${name}.pid"}
command="/usr/local/sbin/${name}"
pidfile="${fuglu_pidfile}"
run_rc_command $*
--Chris
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: rc script problem - pidfile not being recognised
On Fri, 11 Sep 2015 15:42:18 +0100 (BST)
Kevin Golding wrote:
> I've been trying to work on a new port and it's my first that uses an
> rc script so I've been expecting a few bumps, but there's one thing I
> can't seem to fix and it's a blocker. I can't stop the daemon!
>
> It dopes create a pidfile so I have the following line in my script:
>
> pidfile="/var/run/${name}.pid"
>
..
> # ps -waux | grep fuglu
> nobody 24013 0.0 0.5 139532 37372 - I 3:57PM
> 0:01.03 /usr/local/bin/python2.7 /usr/local/bin/fuglu
did you set the command_interpreter variable, probably you need
command_interpreter=/usr/local/bin/python2.7
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Anyone got RethinkDB working in FreeBSD?
Hi! > http://www.rethinkdb.com/ > > I tried compiling it in FreeBSD 9.3, and managed > to get past configure and the start of gmake, but > then got a lot of these: Here's a shar file, which overcomes the BREAKPOINT stuff and quite a bit more, but still needs more patching. So it's still a work in progress, but feel free to try it. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203043 -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: rc script problem - pidfile not being recognised
- Original Message -
> From: "RW via freebsd-ports"
> Sent: Friday, 11 September, 2015 4:18:50 PM
>
> On Fri, 11 Sep 2015 15:42:18 +0100 (BST)
> Kevin Golding wrote:
>
> > I've been trying to work on a new port and it's my first that uses
> > an
> > rc script so I've been expecting a few bumps, but there's one thing
> > I
> > can't seem to fix and it's a blocker. I can't stop the daemon!
> >
> > It dopes create a pidfile so I have the following line in my
> > script:
> >
> > pidfile="/var/run/${name}.pid"
> >
> ..
> > # ps -waux | grep fuglu
> > nobody 24013 0.0 0.5 139532 37372 - I 3:57PM
> > 0:01.03 /usr/local/bin/python2.7 /usr/local/bin/fuglu
>
> did you set the command_interpreter variable, probably you need
>
> command_interpreter=/usr/local/bin/python2.7
And that seems to have fixed it - thank you.
I still think there's an error in reading the pidfile since I think this means
I'm using the process name rather than the pid but it does the job so I won't
worry too much for today. Maybe I'll venture over to freebsd-hackers@ to solve
that one when I feel I know my script a little better.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: rc script problem - pidfile not being recognised
Kevin Golding wrote:
> I've been trying to work on a new port and it's my first that uses an rc
> script so I've been expecting a few bumps, but there's one thing I can't seem
> to fix and it's a blocker. I can't stop the daemon!
>
> It dopes create a pidfile so I have the following line in my script:
>
> pidfile="/var/run/${name}.pid"
>
> Alas...
>
> # service fuglu stop
> fuglu not running? (check /var/run/fuglu.pid).
> # cat /var/run/fuglu.pid
> 24013
>
> I don't get it. It is the right process ID:
>
> # ps -waux | grep fuglu
> nobody 24013 0.0 0.5 139532 37372 - I 3:57PM 0:01.03
> /usr/local/bin/python2.7 /usr/local/bin/fuglu --pidfile /var/r
> root 26179 0.0 0.0 18824 1976 0 S+4:30PM 0:00.00 grep
> fuglu
>
I'd take a bet as it's running as a user the process is being called to
shutdown and there is some permissions issue on the PID file (I see the
same thing with bucardo when running bucardo as non root)
Regards,
Michelle
--
Michelle Sullivan
http://www.mhix.org/
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: nagios-plugins 2.1.1 segmentation fault
On 09/11/15 03:18, Mathieu Arnold wrote: > > > +--On 10 septembre 2015 17:26:46 +0200 Albert Shih > wrote: > | Hi, > | > | I find a bug about nagios-plugins-2.1.1 I don't known if it's the > | freebsd-ports version or it's about the plugins himself. Anyway if you do > | a > | > | check_http host > | > | where the host didn't answer but can be reach (apache not running) you get > | a Segmentation fault and a core dump. > | > | Easy to try > | > | check_http 127.0.0.1 > | > | Regards. > > Hi, > > I can't reproduce this: > > # /usr/local/libexec/nagios/check_http 127.0.0.1 > HTTP OK: HTTP/1.1 301 Moved Permanently - 491 bytes in 0.001 second > response time |time=0.000816s;;;0.00 size=491B;;;0 > > Note that using check_http that way is some old legacy way of doing it, you > should run it as: > > # /usr/local/libexec/nagios/check_http -H 127.0.0.1 > HTTP OK: HTTP/1.1 301 Moved Permanently - 491 bytes in 0.000 second > response time |time=0.000367s;;;0.00 size=491B;;;0 Try it on a machine that *isn't* listening on port 80 .. imb ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: rc script problem - pidfile not being recognised
On Fri, 11 Sep 2015 16:55:58 +0100 (BST) Kevin Golding wrote: > - Original Message - > > From: "RW via freebsd-ports" > > Sent: Friday, 11 September, 2015 4:18:50 PM > > > > did you set the command_interpreter variable, probably you need > > > > command_interpreter=/usr/local/bin/python2.7 > > And that seems to have fixed it - thank you. > > I still think there's an error in reading the pidfile since I think > this means I'm using the process name rather than the pid but it does > the job so I won't worry too much for today. It needs both. It won't use just the pid file because the pid might have been reassigned to another process if the original daemon died without deleting its pid file. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Anyone got RethinkDB working in FreeBSD?
On Fri, Sep 11, 2015 at 05:21:18PM +0200, Kurt Jaeger wrote:
> Hi!
>
> > http://www.rethinkdb.com/
> >
> > I tried compiling it in FreeBSD 9.3, and managed
> > to get past configure and the start of gmake, but
> > then got a lot of these:
>
> Here's a shar file, which overcomes the BREAKPOINT stuff
> and quite a bit more, but still needs more patching. So
> it's still a work in progress, but feel free to try it.
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203043
>
> --
> p...@opsec.eu+49 171 3101372 5 years to
> go !
Thanks!
I tried your file, but didn't get very far unfortunately.
I had to do these two changes to your Makefile to get past
the configure step:
Add CXX=c++48
Comment cd ${WRKSRC} && ${PATCH} < ${FILESDIR}/extra-patch-config.mk
And I moved extra-patch-config.mk out of the files directory.
The addition of CXX is because otherwise configure finds
gcc in base, which is too old to be accepted.
The removal of extra-patch-config.mk is because that patch
failed, probably because I don't have LDFLAGS anywhere in
my generated config.mk. I tried adding LDFLAGS, CXXFLAGS
and CFLAGS manually to config.mk, but that didn't help.
I get this error after a couple of successful compile lines:
test -e ./build/external/v8_3.30.33.16/include && touch
./build/external/v8_3.30.33.16/include || true
mkdir -p build/release_system/obj/rdb_protocol/
./build/release_system/dep/rdb_protocol/
c++48 -O2 -pipe -fstack-protector -fno-strict-aliasing -isystem
./build/external/re2_20140111/include -isystem
./build/external/v8_3.30.33.16/include -I./src -pthread
"-DPRODUCT_NAME=\"RethinkDB\"" "-D__STDC_LIMIT_MACROS" "-D__STDC_FORMAT_MACROS"
-Wall -Wextra "-DRAPIDJSON_HAS_STDSTRING"
"-DRAPIDJSON_PARSE_DEFAULT_FLAGS=kParseFullPrecisionFlag" -Wnon-virtual-dtor
-Wno-deprecated-declarations -std=gnu++0x -Wformat=2 -Wswitch-enum
-Wno-array-bounds -O3 -DNDEBUG -fno-strict-aliasing -g -DHAS_TERMCAP
-I./build/release_system/proto -DRETHINKDB_VERSION=\"2.1.3\"
-DRETHINKDB_CODE_VERSION=\"2.1.3\" -isystem
./build/external/gtest_1.6.0/include -c -o
build/release_system/obj/rdb_protocol/erase_range.o
src/rdb_protocol/erase_range.cc \
-MP -MQ build/release_system/obj/rdb_protocol/erase_range.o -MD -MF
./build/release_system/dep/rdb_protocol/erase_range.d
In file included from ./src/utils.hpp:11:0,
from ./src/containers/scoped.hpp:10,
from ./src/containers/counted.hpp:10,
from ./src/serializer/types.hpp:11,
from ./src/buffer_cache/types.hpp:9,
from ./src/rdb_protocol/erase_range.hpp:10,
from src/rdb_protocol/erase_range.cc:2:
/src/debug.hpp: In function 'typename
std::enable_if::value>::type
debug_print(printf_buffer_t*, T)':
./src/debug.hpp:32:22: error: 'to_string' is not a member of 'std'
debug_print(buf, std::to_string(x));
^
Peter
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [HEADSUP] portmaster/portupgrade support for new features
On 6/29/2015 2:22 AM, Baptiste Daroussin wrote:
> hi all,
>
> A couple of new features are coming to the ports tree. The first of which has
> landed in the ports tree and should not be used before a while, still before
> we
> start using it, it would be a very good idea to bring support for it to
> portmaster/portupgrade. (I have already done the change in poudriere and it
> will
> be in te next version.)
>
> So since recently we can remove the ${PORTSDIR} from all the dependency lines.
> (Please do not use that syntax before all the tools are able to handle it!)
>
> Aka BLA_DEPENDS= pattern:${PORTSDIR}/category/port can now become
> pattern:category/ports
>
> I haven't checked portmaster/portupgrade code so I have no idea if they will
> support that out of box or if they will need some changes.
>
> I would really appreciate to see people testing that and provide patches if
> necessary so that the day we adopt this syntax those tools are already ready
> to
> use it ootb.
>
> FYI: https://github.com/freebsd/portmaster and
> https://github.com/freebsd/portupgrade
>
> Later more changes will be necessary to support upcoming VARIANTS (formerly
> known as FLAVOURS) and sub packages.
>
> This first step would allow you to step into the code of those tools before
> the
> having to deal with more intrusive changes :)
>
I have not forgotten about this. I plan to look into it in the next few
weeks.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: rc script problem - pidfile not being recognised
RW via freebsd-ports wrote: It needs both. It won't use just the pid file because the pid might have been reassigned to another process if the original daemon died without deleting its pid file. Why would this rc script *require* a command_interpreter variable to use the pidfile variable? I'm curious because this violates KIS, the principle of least surprise and few rc scripts seem to have this variable defined. Using command_interpreter is good to be sure, for for the reason listed, but rc scripts should not fail if it is undefined. IMO, Roger Marquis ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: rc script problem - pidfile not being recognised
On Fri, 11 Sep 2015 09:46:31 -0700 (PDT) Roger Marquis wrote: > RW via freebsd-ports wrote: > > It needs both. It won't use just the pid file because the pid > > might have been reassigned to another process if the original daemon > > died without deleting its pid file. > > Why would this rc script *require* a command_interpreter variable to > use the pidfile variable? I'm curious because this violates KIS, the > principle of least surprise and few rc scripts seem to have this > variable defined. > > Using command_interpreter is good to be sure, for for the reason > listed, but rc scripts should not fail if it is undefined. IIRC the name is always checked. When an interpreted script is run using a shebang the command in the output of ps doesn't match the command used to start the script, so command_interpreter is needed to get a match. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Anyone got RethinkDB working in FreeBSD?
Hi! > I tried your file, but didn't get very far unfortunately. > > I had to do these two changes to your Makefile to get past > the configure step: > > Add CXX=c++48 I suggest you go straight to clang, I'm not sure if USES= compiler:c++11-lib would do the trick, but I'll try as soon as I get a building version on 11-CURRENT. -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Anyone got RethinkDB working in FreeBSD?
Hi! Right now, I'm in the part where it tries to link the build/external/v8_3.30.33.16/build/out stuff and fails because the clang loader does not handle liba files 8-( -- p...@opsec.eu+49 171 3101372 5 years to go ! ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: nagios-plugins 2.1.1 segmentation fault
Le 11/09/2015 à 12:20:04-0400, Michael Butler a écrit > On 09/11/15 03:18, Mathieu Arnold wrote: > > > > > > +--On 10 septembre 2015 17:26:46 +0200 Albert Shih > > wrote: > > | Hi, > > | > > | I find a bug about nagios-plugins-2.1.1 I don't known if it's the > > | freebsd-ports version or it's about the plugins himself. Anyway if you do > > | a > > | > > | check_http host > > | > > | where the host didn't answer but can be reach (apache not running) you get > > | a Segmentation fault and a core dump. > > | > > | Easy to try > > | > > | check_http 127.0.0.1 > > | > > | Regards. > > > > Hi, > > > > I can't reproduce this: > > > > # /usr/local/libexec/nagios/check_http 127.0.0.1 > > HTTP OK: HTTP/1.1 301 Moved Permanently - 491 bytes in 0.001 second > > response time |time=0.000816s;;;0.00 size=491B;;;0 > > > > Note that using check_http that way is some old legacy way of doing it, you > > should run it as: > > > > # /usr/local/libexec/nagios/check_http -H 127.0.0.1 > > HTTP OK: HTTP/1.1 301 Moved Permanently - 491 bytes in 0.000 second > > response time |time=0.000367s;;;0.00 size=491B;;;0 > > Try it on a machine that *isn't* listening on port 80 .. I just create a bug report on github https://github.com/nagios-plugins/nagios-plugins/issues/104 Regards. -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: j...@obspm.fr Heure local/Local time: ven 11 sep 2015 21:38:51 CEST ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: rc script problem - pidfile not being recognised
Roger Marquis wrote: > RW via freebsd-ports wrote: >> It needs both. It won't use just the pid file because the pid >> might have been reassigned to another process if the original daemon >> died without deleting its pid file. > > Why would this rc script *require* a command_interpreter variable to use > the pidfile variable? I'm curious because this violates KIS, the > principle of least surprise and few rc scripts seem to have this variable > defined. > > Using command_interpreter is good to be sure, for for the reason listed, > but rc scripts should not fail if it is undefined. +1 to that. -- Michelle Sullivan http://www.mhix.org/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
