Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
2010/9/12 Ion-Mihai Tetcu : > On Sun, 12 Sep 2010 06:45:47 +0800 > Denny Lin wrote: > >> On Sat, Sep 11, 2010 at 11:35:43PM +0200, Torfinn Ingolfsen wrote: >> > On Sat, Sep 11, 2010 at 4:33 PM, Ion-Mihai Tetcu >> > wrote: >> > >> > > This 'stop the service before we install' seems to be a new >> > > fashion, usually unneeded/disruptive. >> > > IMO this should only happen when it's really needed, and with >> > > some big warning printed. >> > > >> > >> > And perhaps with a restart service attempt afterwards? (maybe >> > interactive as in "do you want me to restart the service y/n?") >> > Just my 0.02 euros. >> >> How about knobs like WITH_STOP_SERVICE and WITH_START_SERVICE for >> users who wish to avoid the y/n questions? > > We have a standard policy of not auto-starting anything. > We really don't want a service to be stated automatically after install > (think: I installed this today, I'll configure it how I need it > tomorrow, then start the service). > And you can't really know if it's a new install or an upgrade. > > -- > IOnut - Un^d^dregistered ;) FreeBSD "user" > "Intellectual Property" is nowhere near as valuable as "Intellect" > FreeBSD committer -> ite...@freebsd.org, PGP Key ID 057E9F8B493A297B > The the policy should to the same for stopping services and do not auto-stop them because we can't see if it's an upgrade neither. -- Demelier David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problem with textproc/py-lucene port on 8.1-RELEASE
12.09.2010 05:55, Gav... пишет: I take it the lack of reply means no-one else is having issues? Gav... Yes. I've tried to install this port to confirm it's brokenness, but it installs and runs fine for me on recent 8-stable i386. -Original Message- From: owner-freebsd-po...@freebsd.org [mailto:owner-freebsd- po...@freebsd.org] On Behalf Of Gav... Sent: Tuesday, 7 September 2010 7:18 PM To: freebsd-ports@freebsd.org Cc: cls...@freebsd.org Subject: Problem with textproc/py-lucene port on 8.1-RELEASE Hi All, I've just spent over 3 hours at the pc watching over a py-lucene install, accepting licenses, running off to other download sites to fetch stuff, that sort of fun. So I was not happy to be getting a stop error after 3 hours like I have got below. any ideas how to proceed please? Gav... /usr/local/bin/python2.6 -m jcc.__main__ --jar lucene-java-3.0.2/build/lucene-core-3.0.2.jar --jar lucene-java-3.0.2/build/contrib/snowball/lucene-snowball-3.0.2.jar -- jar lucene-java-3.0.2/build/contrib/analyzers/common/lucene-analyzers- 3.0.2.jar --jar lucene-java-3.0.2/build/contrib/regex/lucene-regex-3.0.2.jar -- jar lucene-java-3.0.2/build/contrib/memory/lucene-memory-3.0.2.jar --jar lucene-java-3.0.2/build/contrib/highlighter/lucene-highlighter- 3.0.2.jar --jar lucene-java-3.0.2/build/contrib/queries/lucene-queries-3.0.2.jar --jar build/jar/extensions.jar --package java.lang java.lang.System java.lang.Runtime --package java.util java.util.Arrays java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator --package java.io java.io.StringReader java.io.InputStreamReader java.io.FileInputStream --exclude org.apache.lucene.queryParser.Token --exclude org.apache.lucene.queryParser.TokenMgrError --exclude org.apache.lucene.queryParser.QueryParserTokenManager --exclude org.apache.lucene.queryParser.ParseException --exclude org.apache.lucene.search.regex.JakartaRegexpCapabilities --exclude org.apache.regexp.RegexpTunnel --python lucene --mapping org.apache.lucene.document.Document 'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping java.util.Properties 'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --rename org.apache.lucene.search.highlight.SpanScorer=HighlighterSpanScorer --version 3.0.2 --module python/collections.py --files 2 --build Exception in thread "main" java.lang.NoSuchMethodException: java.lang.Object.hasNext() at java.lang.Class.getMethod(Class.java:1605) Traceback (most recent call last): File "/usr/local/lib/python2.6/runpy.py", line 122, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/local/lib/python2.6/runpy.py", line 34, in _run_code exec code in run_globals File "/usr/local/lib/python2.6/site-packages/JCC-2.6-py2.6-freebsd-8.1-RC2- amd64. egg/jcc/__main__.py", line 102, in cpp.jcc(sys.argv) File "/usr/local/lib/python2.6/site-packages/JCC-2.6-py2.6-freebsd-8.1-RC2- amd64. egg/jcc/cpp.py", line 565, in jcc declares, typeset) File "/usr/local/lib/python2.6/site-packages/JCC-2.6-py2.6-freebsd-8.1-RC2- amd64. egg/jcc/cpp.py", line 1014, in code superMethod = find_method(superCls, methodName, params) File "/usr/local/lib/python2.6/site-packages/JCC-2.6-py2.6-freebsd-8.1-RC2- amd64. egg/jcc/cpp.py", line 218, in find_method if (e.getJavaException().getClass().getName() == 'java.lang.NoSuchMethodException'): File "/usr/local/lib/python2.6/site-packages/JCC-2.6-py2.6-freebsd-8.1-RC2- amd64. egg/jcc/cpp.py", line 51, in getJavaException return self.args[0] IndexError: tuple index out of range gmake: *** [compile] Error 255 *** Error code 1 Stop in /usr/ports/textproc/py-lucene. -- Regards, Ruslan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
On Saturday 11 September 2010 23:35:43 Torfinn Ingolfsen wrote:
> Hi,
>
> On Sat, Sep 11, 2010 at 4:33 PM, Ion-Mihai Tetcu wrote:
> > This 'stop the service before we install' seems to be a new fashion,
> > usually unneeded/disruptive.
> > IMO this should only happen when it's really needed, and with some big
> > warning printed.
>
> And perhaps with a restart service attempt afterwards? (maybe interactive
> as in "do you want me to restart the service y/n?")
> Just my 0.02 euros.
In general, the only safe method is to stop the service before deinstall and
to start it after the upgrade. If a service must not be interrupted, it
probably shouldn't be updated in first place.
Quite some time ago one daemon always ceased to work for me after a
portupgrade. I've added the following lines in my pkgtools.conf (taken from
the sample file) and everything worked fine afterwards.
BEFOREDEINSTALL = {
# Automatically stop the service for each package that has a
# rc script enabled
'*' => proc { |origin|
cmd_stop_rc(origin)
},
}
AFTERINSTALL = {
# Automatically start the server for each package that
# installs a rc file enabled
'*' => proc { |origin|
cmd_start_rc(origin)
},
}
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
On Sun, Sep 12, 2010 at 09:46:02AM +0300, Ion-Mihai Tetcu wrote: > On Sun, 12 Sep 2010 06:45:47 +0800 Denny Lin > wrote: > > On Sat, Sep 11, 2010 at 11:35:43PM +0200, Torfinn Ingolfsen wrote: > > > On Sat, Sep 11, 2010 at 4:33 PM, Ion-Mihai Tetcu > > > wrote: > > > > This 'stop the service before we install' seems to be a new > > > > fashion, usually unneeded/disruptive. > > > > IMO this should only happen when it's really needed, and with > > > > some big warning printed. > > > > > > > > > > And perhaps with a restart service attempt afterwards? (maybe > > > interactive as in "do you want me to restart the service y/n?") > > > Just my 0.02 euros. > > > > How about knobs like WITH_STOP_SERVICE and WITH_START_SERVICE for > > users who wish to avoid the y/n questions? > > We have a standard policy of not auto-starting anything. > We really don't want a service to be stated automatically after install > (think: I installed this today, I'll configure it how I need it > tomorrow, then start the service). > And you can't really know if it's a new install or an upgrade. Is this really a problem? It seems to me that the presence of 'dhcpd_enable="YES"' in /etc/rc.conf (or whatever similar entry is used for a given service) should answer the question of whether some service should be started after an upgrade. I always restart any services after an upgrade. The reason being, if by chance something does go wrong, I want to know about it at that time, while the server is maintenance (when I can be reasonably sure of the cause), not at some random time in the future (when someone will have to troubleshoot the problem -- on a server that is supposed to be live). -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Option in port depending on another port, how to handle ?
Hello,
I've locally added an option to www/nginx to add support for www/uwsgi.
I'm hardcoding uwsgi version in nginx makefile :
.if defined(WITH_HTTP_UWSGI_MODULE)
NGINX_UWSGI_MODULE_VERSION= 0.9.5.3
MASTER_SITES+= http://projects.unbit.it/downloads/:uwsgi
DISTFILES+= uwsgi-${NGINX_UWSGI_MODULE_VERSION}.tar.gz:zip
CONFIGURE_ARGS+=--add-module=${WRKDIR}/uwsgi-${NGINX_UWSGI_MODULE_VERSION}/nginx
.endif
Is there any proper way to retrieve NGINX_UWSGI_MODULE_VERSION from
www/uwsgi Makefile please ?
Regards
Eric Masson
--
Floriano veux détruire le ng , alors pour quoi ne pas le résusiter
juste après sa destruction je m'explique il ne veux plus de ce groupe
ben ont en recrée un nouveau du même nom
-+- L in GNU - Neuneu fait des miracles -+-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Option in port depending on another port, how to handle ?
Eric Masson writes:
> Hello,
>
> I've locally added an option to www/nginx to add support for www/uwsgi.
> I'm hardcoding uwsgi version in nginx makefile :
>
> .if defined(WITH_HTTP_UWSGI_MODULE)
> NGINX_UWSGI_MODULE_VERSION= 0.9.5.3
NGINX_UWSGI_MODULE_VERSION!= ${MAKE} -V PORTVERSION -C ${PORTSDIR}/www/uwsgi
> MASTER_SITES+= http://projects.unbit.it/downloads/:uwsgi
> DISTFILES+= uwsgi-${NGINX_UWSGI_MODULE_VERSION}.tar.gz:zip
> CONFIGURE_ARGS+=--add-module=${WRKDIR}/uwsgi-${NGINX_UWSGI_MODULE_VERSION}/nginx
> .endif
>
> Is there any proper way to retrieve NGINX_UWSGI_MODULE_VERSION from
> www/uwsgi Makefile please ?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
On 12/09/2010 07:46:02, Ion-Mihai Tetcu wrote: > And you can't really know if it's a new install or an upgrade. An app like portmaster or portupgrade would be able to know that. It's an oddity of the ports/pkg system that because 'upgrade' is implemented as 'delete' followed by 'install' that there is difficulty in making that distinction. In fact, portupgrade has a nifty feature you can enable which causes it to run '/usr/local/etc/rc.d/foo start' for any rc scripts installed by a port it is working on. Which is almost, but not quite, exactly what is wanted; it should issue 'restart' for services already running, or 'start' for services stopped during the upgrade process. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Option in port depending on another port, how to handle ?
Anonymous writes:
Hello,
> NGINX_UWSGI_MODULE_VERSION!= ${MAKE} -V PORTVERSION -C
> ${PORTSDIR}/www/uwsgi
Great. Seems I really need to improve my make-fu.
Thanks for your answer.
Regards
Éric Masson
--
FF>Tout le plaisir est pour moi.
FF>Vous payez par carte bancaire ?
Non, par inadvertance.
-+- OZ in : Reponse hamster à terre -+-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Option in port depending on another port, how to handle ?
Anonymous writes:
Hello again,
> NGINX_UWSGI_MODULE_VERSION!= ${MAKE} -V PORTVERSION -C
> ${PORTSDIR}/www/uwsgi
Subsidiary question, as uwsgi nginx module needs uwsgi tarball, nginx
distinfo must contain related checksums & size.
Is there any way to avoid duplicating distinfo entries in both ports ?
Regards
Éric Masson
--
si tu est hacker peut tu me donner des conseil ou minicier car je
suis debutant
PP> Je te conseil 2 bon boukin pour comancé: Bled et Grevisse
-+- MT In Pas minicier, complètement sciés -+-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Option in port depending on another port, how to handle ?
On 12/09/2010 15:23, Eric Masson wrote:
> Anonymous writes:
>> NGINX_UWSGI_MODULE_VERSION!= ${MAKE} -V PORTVERSION -C
>> ${PORTSDIR}/www/uwsgi
>
> Great. Seems I really need to improve my make-fu.
>
> Thanks for your answer.
This kind of thing can become a real performance burden if it
becomes commonly used.
Regards
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Option in port depending on another port, how to handle ?
Eric Masson writes:
> Anonymous writes:
>
> Hello again,
>
>> NGINX_UWSGI_MODULE_VERSION!= ${MAKE} -V PORTVERSION -C
>> ${PORTSDIR}/www/uwsgi
>
> Subsidiary question, as uwsgi nginx module needs uwsgi tarball, nginx
> distinfo must contain related checksums & size.
>
> Is there any way to avoid duplicating distinfo entries in both ports ?
Why not extract it as a dependency then?
.if defined(WITH_HTTP_UWSGI_MODULE)
CONFIGURE_ARGS+= --add-module=${UWSGI_WRKSRC}/nginx
BUILD_DEPENDS+= ${NONEXISTENT}:${PORTSDIR}/www/uwsgi:patch
UWSGI_WRKSRC!= ${MAKE} -V WRKSRC -C ${PORTSDIR}/www/uwsgi
.endif
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/12/2010 09:02, Matthew Seaman wrote: > On 12/09/2010 07:46:02, Ion-Mihai Tetcu wrote: >> And you can't really know if it's a new install or an upgrade. > > An app like portmaster or portupgrade would be able to know that. It's > an oddity of the ports/pkg system that because 'upgrade' is implemented > as 'delete' followed by 'install' that there is difficulty in making > that distinction. > > In fact, portupgrade has a nifty feature you can enable which causes it > to run '/usr/local/etc/rc.d/foo start' for any rc scripts installed by a > port it is working on. Which is almost, but not quite, exactly what is > wanted; it should issue 'restart' for services already running, or > 'start' for services stopped during the upgrade process. > If someone really wants to go for automation lets not leave it on the backs of every user that is involved with ports that offer network services but learn how to properly script out periodic(8) runs or a cron(8) job to check for the existence of that process. Line wrapage: */5 * * * * /usr/local/etc/rc.d/rcscript status \ ||/usr/local/etc/rc.d/rcscript start Or write your own periodic script that makes use of _enable etc... and put it in /usr/local/etc/periodic somewhere. People may also be interested in this, that I use for personal cron jobs that I need to schedule minutely hourly daily and such. http://bit.ly/9ODE56 Perfectly fine that tools like portmaster or portupgrade offer these things but lets not forget that its also really easy to figure out what services are going to be stopped before you start a upgrade and then restart them after using service(8) for example. Maybe it would not be such a bad idea to start a framework for a set of periodic checks that the user can configure simple by # 5 Minute Service checks minutely_check_enable="YES" # Allow disabling all 5 minute checks. minutely_check_rcscript_enable="YES" # Enable check for this rcscript. # Hourly checks # hourly_check_enable="YES" # See above hourly_check_rcscript2_enable="YES" # ... The rc.subr system should be able to handle this or service(8) by calling status and taking appropriate action for each script within an hourly_check_*_enable variable. Just some thoughts to be expanded, Regards, - -- jhell,v -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMjOe6AAoJEJBXh4mJ2FR+20cH/ReHJDra84J19WX0UJxvcA2v Z4QK/y/Tn5J3bjQ8EVOmkZIokX3EDunHrlufdIq/iaWWVKC4xhJ6DNFqJJ8zw5Mm 5zL59xO/m+uw3Fuxxc67semTvFbLhmCG/IiDTyePjfhU9rj/eV0EdAtO9auBGXgJ GNfn1QQrejoYPt/bStwBnbmPM2JHmiU1Qbu+A7MpGZRVH1flUBbIk0EQBluErEsK vvWa6LYqZsZPT3IKZvMEmIi6WQQLrEnIHgsjUNqnbw8FijPsi0fATdUxwVGUaR4T hmIfkHtLz/v0zg5nHFNcMniz+Og3nWAWP68ews0gWyYm/5gftfWobaFTRLnm4FA= =CvPi -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
On 12/09/2010 15:46:18, jhell wrote: > On 09/12/2010 09:02, Matthew Seaman wrote: >> On 12/09/2010 07:46:02, Ion-Mihai Tetcu wrote: >>> And you can't really know if it's a new install or an upgrade. > >> An app like portmaster or portupgrade would be able to know that. It's >> an oddity of the ports/pkg system that because 'upgrade' is implemented >> as 'delete' followed by 'install' that there is difficulty in making >> that distinction. > >> In fact, portupgrade has a nifty feature you can enable which causes it >> to run '/usr/local/etc/rc.d/foo start' for any rc scripts installed by a >> port it is working on. Which is almost, but not quite, exactly what is >> wanted; it should issue 'restart' for services already running, or >> 'start' for services stopped during the upgrade process. > > > > If someone really wants to go for automation lets not leave it on the > backs of every user that is involved with ports that offer network > services but learn how to properly script out periodic(8) runs or a > cron(8) job to check for the existence of that process. > > Line wrapage: > */5 * * * * /usr/local/etc/rc.d/rcscript status \ > ||/usr/local/etc/rc.d/rcscript start > > Or write your own periodic script that makes use of _enable etc... and > put it in /usr/local/etc/periodic somewhere. Heh. BTDT. Well, almost: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/118325 That just reports on any services that should be running and aren't. It would be trivial to make it attempt to restart anything that needed it. > People may also be interested in this, that I use for personal cron jobs > that I need to schedule minutely hourly daily and such. > http://bit.ly/9ODE56 > > Perfectly fine that tools like portmaster or portupgrade offer these > things but lets not forget that its also really easy to figure out what > services are going to be stopped before you start a upgrade and then > restart them after using service(8) for example. > > Maybe it would not be such a bad idea to start a framework for a set of > periodic checks that the user can configure simple by > > # 5 Minute Service checks > minutely_check_enable="YES" # Allow disabling all 5 minute checks. > minutely_check_rcscript_enable="YES" # Enable check for this rcscript. > > # Hourly checks # > hourly_check_enable="YES" # See above > hourly_check_rcscript2_enable="YES" # > ... > > The rc.subr system should be able to handle this or service(8) by > calling status and taking appropriate action for each script within an > hourly_check_*_enable variable. Hmmm... checking every 5 minutes and automatically restarting anything not running sounds like a sorcerer's apprentice scenario... You shouldn't need to check service status that frequently -- a report once a day will do, unless you've just been fiddling with the system, when you could just run the daily check by hand and deal with anything that needs it. If you've got a service where downtime cannot be tolerated, that's why things like nagios and daemontools exist -- but that's overkill much of the time. Cheers Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/12/2010 15:10, Matthew Seaman wrote: > On 12/09/2010 15:46:18, jhell wrote: >> On 09/12/2010 09:02, Matthew Seaman wrote: >>> On 12/09/2010 07:46:02, Ion-Mihai Tetcu wrote: And you can't really know if it's a new install or an upgrade. >> >>> An app like portmaster or portupgrade would be able to know that. It's >>> an oddity of the ports/pkg system that because 'upgrade' is implemented >>> as 'delete' followed by 'install' that there is difficulty in making >>> that distinction. >> >>> In fact, portupgrade has a nifty feature you can enable which causes it >>> to run '/usr/local/etc/rc.d/foo start' for any rc scripts installed by a >>> port it is working on. Which is almost, but not quite, exactly what is >>> wanted; it should issue 'restart' for services already running, or >>> 'start' for services stopped during the upgrade process. >> >> >> >> If someone really wants to go for automation lets not leave it on the >> backs of every user that is involved with ports that offer network >> services but learn how to properly script out periodic(8) runs or a >> cron(8) job to check for the existence of that process. >> >> Line wrapage: >> */5 * * * * /usr/local/etc/rc.d/rcscript status \ >> ||/usr/local/etc/rc.d/rcscript start >> >> Or write your own periodic script that makes use of _enable etc... and >> put it in /usr/local/etc/periodic somewhere. > > Heh. BTDT. Well, almost: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/118325 > > That just reports on any services that should be running and aren't. It > would be trivial to make it attempt to restart anything that needed > it. > >> People may also be interested in this, that I use for personal cron jobs >> that I need to schedule minutely hourly daily and such. >> http://bit.ly/9ODE56 >> >> Perfectly fine that tools like portmaster or portupgrade offer these >> things but lets not forget that its also really easy to figure out what >> services are going to be stopped before you start a upgrade and then >> restart them after using service(8) for example. >> >> Maybe it would not be such a bad idea to start a framework for a set of >> periodic checks that the user can configure simple by >> >> # 5 Minute Service checks >> minutely_check_enable="YES" # Allow disabling all 5 minute checks. >> minutely_check_rcscript_enable="YES" # Enable check for this rcscript. >> >> # Hourly checks # >> hourly_check_enable="YES"# See above >> hourly_check_rcscript2_enable="YES" # >> ... >> >> The rc.subr system should be able to handle this or service(8) by >> calling status and taking appropriate action for each script within an >> hourly_check_*_enable variable. > > Hmmm... checking every 5 minutes and automatically restarting anything > not running sounds like a sorcerer's apprentice scenario... Right but I'm just thinking of the "X wants Z" scenario but A comes along and says Y is not even in the picture?... Provide this as a common ground since the rest would already be done. But I'm not saying it should even report anything at all unless something has to be restarted. and heck that could be a option too ;) > > You shouldn't need to check service status that frequently -- a report > once a day will do, unless you've just been fiddling with the system, > when you could just run the daily check by hand and deal with anything > that needs it. If you've got a service where downtime cannot be > tolerated, that's why things like nagios and daemontools exist -- but > that's overkill much of the time. > I agree with that but like you said overkill in most cases and even this would be overkill in its own way. Providing something like this gives the user a generic middle-ground where they can make the decision if they would like something a little more sophisticated or nothing at all. Not really set in stone but those checks could also obey a *_threshold much like what 800.zfs-scrub does but for a time-frame instead with unsaid defaults for the moment. Anyhoo... Regards, - -- jhell,v -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMjTF5AAoJEJBXh4mJ2FR+NNEH/iEChgxhNXukrLHnlHxDUV69 zT16HArIsUR9S/0Wvc98Ok9DUBHMf6DeKREP/vbfFqnhWJ7SINCKzw9dod9wo+8W JudfrX7ultqv22Rimh2i8+EYUMHToqXP/gxDMINDHlJTsaqkO2J7oYPZu4w9svxy Q/PtoeGIWYAcg7IIHYSOZIv85eVoRkSTcuValQ81XBsksi5zP9eUMnBDtgkc25lB hbtpXfY3aftJPfPloatuIJL7V1yJAKpiMghkuNmrbUVgn6nywkLigrf7tSzJVDow WRKdirwrkuljb5mRsNz62TYXsbf6N2Dxxyh1iH6SN4hAnOPnNqeB8juyLH6zQYE= =kxmd -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
