Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
On Wed, Sep 15, 2010 at 11:31:51AM -0700, Doug Barton wrote: > On 9/15/2010 1:18 AM, Greg Byshenk wrote: > >On Tue, Sep 14, 2010 at 06:22:24PM -0700, Doug Barton wrote: > >>I can think of at least one more scenario off the top of my head. You > >>want to run the new version of the service the next time the box is > >>restarted for whatever reason, but the update is not so critical that it > >>justifies restarting the system immediately. > > > >Do 'you' (generic) -really- want to do this? > > Once again, it's an area where the intelligence of the admin is expected > to be applied. :) If you're thinking in terms of one machine, you're > right, this probably isn't a good idea. However if you're thinking of a > server farm with 1,000's of identical systems, a good QA process (so > it's a known-good change), and monitoring in place to detect a failed > reboot and take that box out of the pool; not only is what I described > reasonable, it's commonplace. I don't want to belabor this too much, and -- of course -- the intelligence of the sysadmin is expected to be applied, but part of the point here is reasonable expectations of default behaviour. It may be that my view of this is incomplete, but it really does seem to me that the reasonable expectation is that an admin (of however many machines) is updating service because s/he wants to be -running- the new version of service . And that the most reasonable time to change the running service from version a to version a+1 is during the maintenance period in which the new service is installed. And this is not dependent upon the distinction between working with a single server or a pool of hundreds or thousands. After all, if the server is in its maintenance window, then stopping/restarting the service won't make any difference at that time, while it may at some other time. That said, I can imagine cases in which one might wish to roll out a new version but wait until some later time to activate it -- but it seems to me (at least) that these are the non-standard, 'special' caes, and also the cases in which the admins can be expected to know how to disable automatic updates/restarts. Note: because of that last paragraph, I do think that any automated restart of services should have the option to disable that restart. -- 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"
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
Hi.
On Wed, 15 Sep 2010 11:31:51 -0700
Doug Barton wrote:
> >> I can think of at least one more scenario off the top of my head. You
> >> want to run the new version of the service the next time the box is
> >> restarted for whatever reason, but the update is not so critical that it
> >> justifies restarting the system immediately.
> > Do 'you' (generic) -really- want to do this?
> Once again, it's an area where the intelligence of the admin is expected
> to be applied. :) If you're thinking in terms of one machine, you're
> right, this probably isn't a good idea. However if you're thinking of a
> server farm with 1,000's of identical systems, a good QA process (so
> it's a known-good change), and monitoring in place to detect a failed
> reboot and take that box out of the pool; not only is what I described
> reasonable, it's commonplace.
I agree.
And to disable '@unexec %D/etc/rc.d/isc-dhcpd forcestop', I wrote
/etc/rc.conf.d/dhcpd in my machines like following:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
stop_precmd="nothing_to_do"
nothing_to_do () {
[ x"${rc_force}" = x"yes" ] && exit 1
}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
If needed, we (administrators) can disable a mechanism such as thus.
--
Norikatsu Shigemura
___
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 9/15/2010 1:18 AM, Greg Byshenk wrote: On Tue, Sep 14, 2010 at 06:22:24PM -0700, Doug Barton wrote: [...] I can think of at least one more scenario off the top of my head. You want to run the new version of the service the next time the box is restarted for whatever reason, but the update is not so critical that it justifies restarting the system immediately. Do 'you' (generic) -really- want to do this? Once again, it's an area where the intelligence of the admin is expected to be applied. :) If you're thinking in terms of one machine, you're right, this probably isn't a good idea. However if you're thinking of a server farm with 1,000's of identical systems, a good QA process (so it's a known-good change), and monitoring in place to detect a failed reboot and take that box out of the pool; not only is what I described reasonable, it's commonplace. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ 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
Quoth Jerry on Wednesday, 15 September 2010: > On Wed, 15 Sep 2010 08:15:56 -0700 > Chip Camden articulated: > > > Please don't automatically stop/start anything that might be critical. > > I've had enough of Windows' automatic reboots after automatic > > upgrades, and I never want to go back. > > You do realize that, that is extremely easy to deactivate? > > -- > Jerry ??? > freebsd-ports.u...@seibercom.net > > Disclaimer: off-list followups get on-list replies or get ignored. > Please do not ignore the Reply-To header. > __ > Sacred cows make great hamburgers. Of course -- but clients and other users tend to enable it by default. Then your software gets blamed for being "down" because something prevented the reboot from coming back cleanly. -- Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com| http://chipsquips.com pgpg8BFNbFw9v.pgp Description: PGP signature
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
On Wed, 15 Sep 2010 08:15:56 -0700 Chip Camden articulated: > Please don't automatically stop/start anything that might be critical. > I've had enough of Windows' automatic reboots after automatic > upgrades, and I never want to go back. You do realize that, that is extremely easy to deactivate? -- Jerry ✌ freebsd-ports.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Sacred cows make great hamburgers. signature.asc Description: PGP signature
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
Quoth Greg Byshenk on Wednesday, 15 September 2010: > On Tue, Sep 14, 2010 at 06:22:24PM -0700, Doug Barton wrote: > > [...] > > > I can think of at least one more scenario off the top of my head. You > > want to run the new version of the service the next time the box is > > restarted for whatever reason, but the update is not so critical that it > > justifies restarting the system immediately. > > Do 'you' (generic) -really- want to do this? 'This', in this case > being making a change without testing what will happen when the > machine or service is next restarted? One of the things I've > learned is that things aren't always perfect, and, if I change > service in some way, then I want to test that .../rc.d/ > actually does what I want/expect next time it runs. > > As I noted before, if by chance something is wrong, I want to > know -now-, while the server/service is being maintained, not at > some random later date. > > > I am not coming down on either side of the 'automation' issue, as > I think that I can see points on both sides; I'm just suggesting > that this argument is not a good one. > > > -- > 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" Please don't automatically stop/start anything that might be critical. I've had enough of Windows' automatic reboots after automatic upgrades, and I never want to go back. -- Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com| http://chipsquips.com pgpJKoVXnirWR.pgp Description: PGP signature
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
On Tue, Sep 14, 2010 at 06:22:24PM -0700, Doug Barton wrote: [...] > I can think of at least one more scenario off the top of my head. You > want to run the new version of the service the next time the box is > restarted for whatever reason, but the update is not so critical that it > justifies restarting the system immediately. Do 'you' (generic) -really- want to do this? 'This', in this case being making a change without testing what will happen when the machine or service is next restarted? One of the things I've learned is that things aren't always perfect, and, if I change service in some way, then I want to test that .../rc.d/ actually does what I want/expect next time it runs. As I noted before, if by chance something is wrong, I want to know -now-, while the server/service is being maintained, not at some random later date. I am not coming down on either side of the 'automation' issue, as I think that I can see points on both sides; I'm just suggesting that this argument is not a good one. -- 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"
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
On Wed, Sep 15, 2010 at 12:19:43AM -0700, per...@pluto.rain.com wrote: > Doug Barton wrote: > > > >>>... Is it really absolutely necessary > > >>>to stop a service before it's files go away? > > > > IMO the only time the ports infrastructure itself should do this > > is if it isn't possible to pkg_delete the port cleanly if it's > > running. For example, if there is a file being held open that > > cannot be deleted unless the service is stopped ... > > Which should be an exceedingly rare circumstance, since the fact > of some process(es) having a file open will not ordinarily prevent > the removal of any or all directory entries pointing to it. The > inode and disk space won't actually be released until the last > such process closes the file, but another file could be created > having the same pathname as the one whose prior directory entry > was removed. ...which also makes the assumption the daemon doesn't do stat(2) or similar to verify a file exists, or does a multitude of other things that might act on a filesystem but not an open descriptor. We can sit here discussing what a daemon might do or not do until we're blue in the face, which is why I tend to side with Doug's argument that these sorts of tasks (stopping daemons, starting daemons, etc.) should be left to the administrator. I sympathise with the OP, but as I stated previously: what kind of administrator upgrades software, especially a daemon, then doesn't test/check to make sure everything's running correctly after the upgrade? I would rather we not try to solve a borderline social problem with software. But, also like Doug, I see the validity in the need for an automated upgrade infrastructure/framework that can provide daemon auto-stop and auto-start (I strongly oppose the latter) if desired. I just don't know how feasible that is, or if it's worth the time. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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
Doug Barton wrote: > >>>... Is it really absolutely necessary > >>>to stop a service before it's files go away? > > IMO the only time the ports infrastructure itself should do this > is if it isn't possible to pkg_delete the port cleanly if it's > running. For example, if there is a file being held open that > cannot be deleted unless the service is stopped ... Which should be an exceedingly rare circumstance, since the fact of some process(es) having a file open will not ordinarily prevent the removal of any or all directory entries pointing to it. The inode and disk space won't actually be released until the last such process closes the file, but another file could be created having the same pathname as the one whose prior directory entry was removed. ___ 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 9/13/2010 11:51 PM, Scot Hetzel wrote:
On Sat, Sep 11, 2010 at 9:33 AM, Ion-Mihai Tetcu wrote:
On Sat, 11 Sep 2010 22:29:02 +0900
Norikatsu Shigemura wrote:
Hi wxs and jpaetzel.
I noticed that dhcpd server stoped after portupgrade,
sometimes. It's a painful accident on my network. Because I didn't
notice some troubles:-(.
Why do you stop the daemons? Is it really absolutely necessary
to stop a service before it's files go away?
IMO the only time the ports infrastructure itself should do this is if
it isn't possible to pkg_delete the port cleanly if it's running. For
example, if there is a file being held open that cannot be deleted
unless the service is stopped. But that's just my opinion, and how I
maintain my ports. Reasonable minds could differ on this topic.
The problem is that your using tools such as portupgrade, or
portmaster, etc.. These tools don't check if the service was running
when it started the upgrade process. Instead they just pkg_delete
the old port and then build or pkg_install the newest version of the
port.
My understanding is that portupgrade has optional features to deal with
this. To date I have not developed anything similar for portmaster.
Partly because of a design choice (see below for more information about
that), partly because of minimal interest expressed by portmaster users,
and mostly for lack of time.
Consider thess senarios:
1. A system admin installs package foo-1.3, adds the appropriate
foo_enable to /etc/rc.conf, and then executes ${PREFIX}/etc/rc.d/foo
start. He tests the foo package and decides that it doesn't meet his
requirements and wants to use bar-1.7 instead. So he goes to
uninstall foo-1.3 without stopping the service (pkg_delete foo-1.3)
and installs bar-1.7. Now, if the pkg-plist didn't have the @unexec
%D/etc/rc.d/foo forcestop, the foo daemon would still be running until
the system was rebooted. So when he goes to starts the bar service,
he gets a suprise because he is connecting to the foo daemon, and the
bar daemon failed to start.
2. A system admin installs package foo-1.3, after running the service
for a while a security hole is found in foo-1.3. So he uses his
favorite ports management tool (pkg_delete/pkg_install, portupgrade,
or portmaster, ...) to upgrade to foo-1.4. If the pkg-plist didn't
have the @unexec %D/etc/rc.d/foo forcestop, the security vulnerable
foo-1.3 daemon would still be running, even though the latest version
has been installed. This would cause the system to still be
vulnerable to the security risk.
I can think of at least one more scenario off the top of my head. You
want to run the new version of the service the next time the box is
restarted for whatever reason, but the update is not so critical that it
justifies restarting the system immediately.
The main problem with upgrading ports that install daemon startup
scripts is that the ports management tools are not checking if the
service is running before they start the upgrade process. These tools
should print a warning at the end of the upgrade process that states
which daemons were stopped due to the upgrade process.
The ports management tools should not automatically restart the
daemons that it had stopped. The reason is that there could be a
configuration change in the new ports sample config files that should
be migrated to the old modified config files before restarting the
service.
To be honest (and I'm sorry if this is off-putting), my knee-jerk
reaction is that neither the ports infrastructure itself, nor the ports
management tools should be doing the thinking _for_ the admin; and that
they should be smart enough to know what services need to be stopped,
and restarted all on their own.
HOWEVER, as I'm looking more and more closely at other systems to see
how they do things I think we're really missing out in terms of not
having a more comprehensive "system management" tool as opposed to the
existing tools that do a bang-up job at ports management. Unfortunately
the deeper I dig into this topic the more I see that "we" simply don't
have the resources we need to do the bigger job properly. And by
resources I mean the whole thing, infrastructure, personnel, funding,
etc. We can continue to talk about bolting stuff on to the existing
infrastructure, and I think there is some low-hanging fruit there; but
ultimately I don't think we're going to get where we need to be in terms
of either completeness or ease of use by building on the foundation we
already have.
Doug
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "fre
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
On Sat, Sep 11, 2010 at 9:33 AM, Ion-Mihai Tetcu wrote:
> On Sat, 11 Sep 2010 22:29:02 +0900
> Norikatsu Shigemura wrote:
>
>> Hi wxs and jpaetzel.
>>
>> I noticed that dhcpd server stoped after portupgrade,
>> sometimes. It's a painful accident on my network. Because I didn't
>> notice some troubles:-(.
>>
>> Why do you stop the daemons? Is it really absolutely necessary
>> to stop a service before it's files go away?
>>
>> SEE ALSO:
>>
>> http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html#AEN5402
>>
>> $ grep forcestop isc-dhcp*/pkg-plist
>> isc-dhcp31-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh
>> forcestop 2>/dev/null || true isc-dhcp31-relay/pkg-plist:@unexec
>> %D/etc/rc.d/isc-dhcrelay forcestop 2>/dev/null || true
>> isc-dhcp31-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd.sh
>> forcestop 2>/dev/null || true isc-dhcp31-server/pkg-plist:@unexec
>> %D/etc/rc.d/isc-dhcpd forcestop 2>/dev/null || true
>> isc-dhcp41-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh
>> forcestop 2>/dev/null || true isc-dhcp41-relay/pkg-plist:@unexec
>> %D/etc/rc.d/isc-dhcrelay forcestop 2>/dev/null || true
>> isc-dhcp41-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd forcestop
>> 2>/dev/null || true
>>
>> I want to remove these lines in pkg-plist.
These lines are needed to ensure that the daemon has been stopped upon
uninstalling the port
> This 'stop the service before we install' seems to be a new fashion,
> usually unneeded/disruptive.
The service is not stopped before the install, it is stopped before
uninstalling the service during a pkg_delete.
This ensures that the service has stopped running when the package is
pkg_deleted.
> IMO this should only happen when it's really needed, and with some big
> warning printed.
>
The problem is that your using tools such as portupgrade, or
portmaster, etc.. These tools don't check if the service was running
when it started the upgrade process. Instead they just pkg_delete
the old port and then build or pkg_install the newest version of the
port.
Consider thess senarios:
1. A system admin installs package foo-1.3, adds the appropriate
foo_enable to /etc/rc.conf, and then executes ${PREFIX}/etc/rc.d/foo
start. He tests the foo package and decides that it doesn't meet his
requirements and wants to use bar-1.7 instead. So he goes to
uninstall foo-1.3 without stopping the service (pkg_delete foo-1.3)
and installs bar-1.7. Now, if the pkg-plist didn't have the @unexec
%D/etc/rc.d/foo forcestop, the foo daemon would still be running until
the system was rebooted. So when he goes to starts the bar service,
he gets a suprise because he is connecting to the foo daemon, and the
bar daemon failed to start.
2. A system admin installs package foo-1.3, after running the service
for a while a security hole is found in foo-1.3. So he uses his
favorite ports management tool (pkg_delete/pkg_install, portupgrade,
or portmaster, ...) to upgrade to foo-1.4. If the pkg-plist didn't
have the @unexec %D/etc/rc.d/foo forcestop, the security vulnerable
foo-1.3 daemon would still be running, even though the latest version
has been installed. This would cause the system to still be
vulnerable to the security risk.
The main problem with upgrading ports that install daemon startup
scripts is that the ports management tools are not checking if the
service is running before they start the upgrade process. These tools
should print a warning at the end of the upgrade process that states
which daemons were stopped due to the upgrade process.
The ports management tools should not automatically restart the
daemons that it had stopped. The reason is that there could be a
configuration change in the new ports sample config files that should
be migrated to the old modified config files before restarting the
service.
Scot
___
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 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"
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 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 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: [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"
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
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: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
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 signature.asc Description: PGP signature
Re: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
Hi everyone! Thank you for my reply. This problem is 'Yet another minor release engineering' for all the world other environments. If you can give assurance upgrading ports, you can stop the daemon (at least, I want to restart it:-). But it's t difficult, and I(we?) don't/can't want your assurance. If the daemon doesn't stop (keep the daemon running), I(we) am given a little grace to update environment like configuration files. If the daemon stop, I(we) should correspond updating at once. In theoretically, we update ports like following operation: 1. Check updating lists like portversion -L =. 2. Check updating documents before portupgrade XXX. 3. portupgrade every once, and update environments (including restart OS). 4. repeat 3. But it's hard, so in practice: 1. portupgrade -aR. 2. Check updating documents, and update environments. 3. repeat 3. 4. restart OS if needed. So please regard such as system managers! -- Norikatsu Shigemura ___ 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 Sat, Sep 11, 2010 at 08:09:28PM -0400, Wesley Shields wrote: > On Sat, Sep 11, 2010 at 05:33:59PM +0300, Ion-Mihai Tetcu wrote: > > On Sat, 11 Sep 2010 22:29:02 +0900 > > Norikatsu Shigemura wrote: > > > > > Hi wxs and jpaetzel. > > > > > > I noticed that dhcpd server stoped after portupgrade, > > > sometimes. It's a painful accident on my network. Because I didn't > > > notice some troubles:-(. > > > > > > Why do you stop the daemons? Is it really absolutely necessary > > > to stop a service before it's files go away? > > > > > > SEE ALSO: > > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html#AEN5402 > > > > > > $ grep forcestop isc-dhcp*/pkg-plist > > > isc-dhcp31-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh > > > forcestop 2>/dev/null || true isc-dhcp31-relay/pkg-plist:@unexec > > > %D/etc/rc.d/isc-dhcrelay forcestop 2>/dev/null || true > > > isc-dhcp31-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd.sh > > > forcestop 2>/dev/null || true isc-dhcp31-server/pkg-plist:@unexec > > > %D/etc/rc.d/isc-dhcpd forcestop 2>/dev/null || true > > > isc-dhcp41-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh > > > forcestop 2>/dev/null || true isc-dhcp41-relay/pkg-plist:@unexec > > > %D/etc/rc.d/isc-dhcrelay forcestop 2>/dev/null || true > > > isc-dhcp41-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd forcestop > > > 2>/dev/null || true > > > > > > I want to remove these lines in pkg-plist. > > > > 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. > > This is there because that is how the old ISC ports were done. I'm not a > fan of this at all. If it doesn't break upgrades I'm going to remove it. > > Ports/packages should keep their grubby little hands off my services. ;) This "problem" affects more than just ISC-related ports. It's scattered all over many, and probably for a good reason. Has anyone taken the time to actually study how the daemon behaves in all possible circumstances if you pull certain files out from underneath it? Meaning, pkg_delete might delete/clean up something that the daemon relies upon. For example, with regards to isc-dhcp, has anyone checked the implications of removing the files it does with the daemon still running? Have they tested such with all configuration (e.g. LDAP in use)? For example, I know that with postfix if you let the daemon remain running when pkg_delete'ing the software, it starts freaking out whenever any mail I/O happens. And what about ports like mysqlXX-server? You get my point. I'm actually in favour of having ports ***not*** touch services at all, but I want to be absolutely sure people aren't jumping the gun claiming "oh it's totally safe" when there's a good chance it might not be. But to play devil's advocate once again: this discussion started because the OP uninstalled or upgraded a port which made use of a daemon, which was (possibly rightfully so) shut down during pkg_delete, and he forgot to restart the daemon. No offence intended, but what administrator upgrades software (a service nonetheless) and then walks away from his computer? Please think about that for a while too, and ask yourself if catering to this mentality through software (ports framework) is a good idea. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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 Sat, Sep 11, 2010 at 05:33:59PM +0300, Ion-Mihai Tetcu wrote: > On Sat, 11 Sep 2010 22:29:02 +0900 > Norikatsu Shigemura wrote: > > > Hi wxs and jpaetzel. > > > > I noticed that dhcpd server stoped after portupgrade, > > sometimes. It's a painful accident on my network. Because I didn't > > notice some troubles:-(. > > > > Why do you stop the daemons? Is it really absolutely necessary > > to stop a service before it's files go away? > > > > SEE ALSO: > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html#AEN5402 > > > > $ grep forcestop isc-dhcp*/pkg-plist > > isc-dhcp31-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh > > forcestop 2>/dev/null || true isc-dhcp31-relay/pkg-plist:@unexec > > %D/etc/rc.d/isc-dhcrelay forcestop 2>/dev/null || true > > isc-dhcp31-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd.sh > > forcestop 2>/dev/null || true isc-dhcp31-server/pkg-plist:@unexec > > %D/etc/rc.d/isc-dhcpd forcestop 2>/dev/null || true > > isc-dhcp41-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh > > forcestop 2>/dev/null || true isc-dhcp41-relay/pkg-plist:@unexec > > %D/etc/rc.d/isc-dhcrelay forcestop 2>/dev/null || true > > isc-dhcp41-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd forcestop > > 2>/dev/null || true > > > > I want to remove these lines in pkg-plist. > > 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. This is there because that is how the old ISC ports were done. I'm not a fan of this at all. If it doesn't break upgrades I'm going to remove it. Ports/packages should keep their grubby little hands off my services. ;) -- WXS ___ 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 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? -- Denny Lin ___ 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
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. -- Regards, Torfinn Ingolfsen ___ 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 Sat, 11 Sep 2010 22:29:02 +0900 Norikatsu Shigemura wrote: > Hi wxs and jpaetzel. > > I noticed that dhcpd server stoped after portupgrade, > sometimes. It's a painful accident on my network. Because I didn't > notice some troubles:-(. > > Why do you stop the daemons? Is it really absolutely necessary > to stop a service before it's files go away? > > SEE ALSO: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html#AEN5402 > > $ grep forcestop isc-dhcp*/pkg-plist > isc-dhcp31-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh > forcestop 2>/dev/null || true isc-dhcp31-relay/pkg-plist:@unexec > %D/etc/rc.d/isc-dhcrelay forcestop 2>/dev/null || true > isc-dhcp31-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd.sh > forcestop 2>/dev/null || true isc-dhcp31-server/pkg-plist:@unexec > %D/etc/rc.d/isc-dhcpd forcestop 2>/dev/null || true > isc-dhcp41-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh > forcestop 2>/dev/null || true isc-dhcp41-relay/pkg-plist:@unexec > %D/etc/rc.d/isc-dhcrelay forcestop 2>/dev/null || true > isc-dhcp41-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd forcestop > 2>/dev/null || true > > I want to remove these lines in pkg-plist. 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. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
[ports/net/isc-dhcp*] Don't stop DHCP related daemons
Hi wxs and jpaetzel. I noticed that dhcpd server stoped after portupgrade, sometimes. It's a painful accident on my network. Because I didn't notice some troubles:-(. Why do you stop the daemons? Is it really absolutely necessary to stop a service before it's files go away? SEE ALSO: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html#AEN5402 $ grep forcestop isc-dhcp*/pkg-plist isc-dhcp31-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh forcestop 2>/dev/null || true isc-dhcp31-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay forcestop 2>/dev/null || true isc-dhcp31-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd.sh forcestop 2>/dev/null || true isc-dhcp31-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd forcestop 2>/dev/null || true isc-dhcp41-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh forcestop 2>/dev/null || true isc-dhcp41-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay forcestop 2>/dev/null || true isc-dhcp41-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd forcestop 2>/dev/null || true I want to remove these lines in pkg-plist. Thank you! -- Norikatsu Shigemura ___ 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"
