Re: Ports with daemons on uninstall...

2013-07-15 Thread Mark Felder
On Sun, Jul 14, 2013, at 14:49, Garrett Wollman wrote:

 Strongly agreed -- and it's what other operating systems do, either by
 policy or by convention.


As long as this behavior only happens during pkg installs and never with
ports, I'm OK. The worst is when a coworker forgets that the mysql port
stops the daemon and my coworker upgrades with portmaster... the daemon
is off the entire time mysql slowly compiles...
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Ports with daemons on uninstall...

2013-07-15 Thread RW
On Mon, 15 Jul 2013 08:34:05 -0500
Mark Felder wrote:

 On Sun, Jul 14, 2013, at 14:49, Garrett Wollman wrote:
 
  Strongly agreed -- and it's what other operating systems do, either
  by policy or by convention.
 
 
 As long as this behavior only happens during pkg installs and never
 with ports, I'm OK. The worst is when a coworker forgets that the
 mysql port stops the daemon and my coworker upgrades with
 portmaster... the daemon is off the entire time mysql slowly
 compiles...

Is that really correct? I would expect the deinstall to be done after
the build has completed successfully.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Ports with daemons on uninstall...

2013-07-15 Thread Walter Hurry
On Mon, 15 Jul 2013 08:34:05 -0500, Mark Felder wrote:

 As long as this behavior only happens during pkg installs and never with
 ports, I'm OK. The worst is when a coworker forgets that the mysql port
 stops the daemon and my coworker upgrades with portmaster... the daemon
 is off the entire time mysql slowly compiles...

I'm not familiar with portmaster, since I use portupgrade. That does the 
build first, then the deinstall old/install new. Seems a sensible 
approach anyway, in case the build fails. Doesn't portmaster work 
similarly?

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Ports with daemons on uninstall...

2013-07-15 Thread Lars Engels
On Mon, Jul 15, 2013 at 01:46:03PM +, Walter Hurry wrote:
 On Mon, 15 Jul 2013 08:34:05 -0500, Mark Felder wrote:
 
  As long as this behavior only happens during pkg installs and never with
  ports, I'm OK. The worst is when a coworker forgets that the mysql port
  stops the daemon and my coworker upgrades with portmaster... the daemon
  is off the entire time mysql slowly compiles...
 
 I'm not familiar with portmaster, since I use portupgrade. That does the 
 build first, then the deinstall old/install new. Seems a sensible 
 approach anyway, in case the build fails. Doesn't portmaster work 
 similarly?

Yes. PM builds, creates a backup package, deinstalls the old packages,
installs the new one.


pgp2inH11AJYo.pgp
Description: PGP signature


Re: Ports with daemons on uninstall...

2013-07-15 Thread Ian FREISLICH
Walter Hurry wrote:
 On Mon, 15 Jul 2013 08:34:05 -0500, Mark Felder wrote:
 
  As long as this behavior only happens during pkg installs and never with
  ports, I'm OK. The worst is when a coworker forgets that the mysql port
  stops the daemon and my coworker upgrades with portmaster... the daemon
  is off the entire time mysql slowly compiles...
 
 I'm not familiar with portmaster, since I use portupgrade. That does the 
 build first, then the deinstall old/install new. Seems a sensible 
 approach anyway, in case the build fails. Doesn't portmaster work 
 similarly?

Try doing a 'portupgrade -f isc-dhcp41-server' and watch it leave
dhcpd not running.

I eventually made the following change so that it wouldn't leave
my system in a broken state:

/usr/ports/net/isc-dhcp41-server # make clean
===  Cleaning for isc-dhcp41-server-4.1.e_7,2
[fw2.smmt] /usr/ports/net/isc-dhcp41-server # svn diff
Index: pkg-plist
===
--- pkg-plist   (revision 323024)
+++ pkg-plist   (working copy)
@@ -1,6 +1,4 @@
 @comment $FreeBSD$
-@unexec %D/etc/rc.d/isc-dhcpd forcestop 2/dev/null || true
-%%IPV6%%@unexec %D/etc/rc.d/isc-dhcpd6 forcestop 2/dev/null || true
 @unexec if cmp -s %D/etc/dhcpd.conf.sample %D/etc/dhcpd.conf; then rm -f 
%D/etc/dhcpd.conf; fi
 etc/dhcpd.conf.sample
 @exec if [ ! -f %D/etc/dhcpd.conf ] ; then cp -p %D/%F %B/dhcpd.conf; fi

I don't mind it stopping the daemon, but if it's going to automatically
stop it, it should automatically start it too.  It's also not
consistent - random sample of two: exim and quagga just leave the
daemon running.  I'm just asking if there's a stated project guideline
for what should happen because at the moment it's hard to know what
to expect.  Maybe its as simple as an install exec that does a
'service foo start'.  If it's a first install it will fail because
foo_enable=yes won't be set in /etc/rc.conf.

Personally, I'd rather that the package management system ports,pkg,etc
doesn't take liberties with my running daemons.  If I want to kill
them off, I'll kill them off, but there have been several times
where I've left uninstalled things running while the system was in
flux during an upgrade.  It was nice to be able to do that.

Ian

-- 
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Ports with daemons on uninstall...

2013-07-15 Thread Mark Felder
On Mon, Jul 15, 2013, at 8:44, RW wrote:
 
 Is that really correct? I would expect the deinstall to be done after
 the build has completed successfully.


That might not be accurate with a current portmaster, but we used to
have that happen all too frequently. I just checked the plist and it has
@stopdaemon mysql-server, so I'm guessing portmaster would run that too
prematurely.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Ports with daemons on uninstall...

2013-07-15 Thread Kevin Oberman
On Mon, Jul 15, 2013 at 7:57 AM, Mark Felder f...@freebsd.org wrote:

 On Mon, Jul 15, 2013, at 8:44, RW wrote:
 
  Is that really correct? I would expect the deinstall to be done after
  the build has completed successfully.
 

 That might not be accurate with a current portmaster, but we used to
 have that happen all too frequently. I just checked the plist and it has
 @stopdaemon mysql-server, so I'm guessing portmaster would run that too
 prematurely.


The reality is that some ports take a LONG time to just install, especially
when libtool is involved. I want the old daemon running until the old one
is installed. Then either the make or I can restart the daemon which
results in a downtime of about  two or three seconds. Stopping before the
new version is installed guarantees a much longer outage.

Yes, I also see some possible nasty races in a few cases, not most would be
fine.

-- 
R. Kevin Oberman, Network Engineer
E-mail: rkober...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Ports with daemons on uninstall...

2013-07-14 Thread Scot Hetzel
On Sun, Jul 14, 2013 at 10:52 AM, Ian FREISLICH i...@clue.co.za wrote:
 Hi

 I have to ask if there's a standard for the way ports should handle
 their daemons when the port is uninstalled.

 I've encountered 3 varients of ports behaviour on uninstall:

 1. Do nothing
 2. Stop the daemon
 3. Ask if the daemon should be stopped

 #1 closely followed by #3 are the least irritating when it comes
 to portupgrade because you can at least have the service running
 while upgrading.  At least with #3 the upgrade gets paused until
 the propmpt is answered and you're then aware that some service
 will go away immediately so you can be prepared to restart it.

 #2 is extremely irritating because upgrading with portupgrade etc
 kills the service.  For instance isc-dhcpd* does this which means
 that for some time, dhcp may be unavailable.  It could be less
 irritating if it would automatically start the service, but that
 can have its own problems.

 Does the project have a preferred method for handling running
 daenmons on uninstall?  I know that Linux will even start daemons
 on install.


Personally, I prefer that when uninstalling a port, that the daemon
gets stopped.  But if you are upgrading a port, then you will want the
daemon to be re-started.

This should be possible with the new pkg tools, but I don't know if it
is implemented:

pkg install isc-dhcpd42-server
- pkg installs the port doesn't start service
- admin starts service with /usr/local/etc/rc.d/isc-dhcpd start

pkg upgrade isc-dhcp42-server
- pkg checks the repository and finds a new version and asks if you
want it installed
- pkg checks if the service(s) is running, saves the status for later
- pkg uninstalls the old port
- pkg installs the new port
- pkg checks the saved status to see if it needs to restart the service(s)

pkg uninstall isc-dhcpd42-server
- pkg uninstalls the port and stops the service if running


-- 
DISCLAIMER:

No electrons were maimed while sending this message. Only slightly bruised.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Ports with daemons on uninstall...

2013-07-14 Thread Jilles Tjoelker
On Sun, Jul 14, 2013 at 05:52:37PM +0200, Ian FREISLICH wrote:
 I have to ask if there's a standard for the way ports should handle
 their daemons when the port is uninstalled.

 I've encountered 3 varients of ports behaviour on uninstall:

 1. Do nothing
 2. Stop the daemon
 3. Ask if the daemon should be stopped

 #1 closely followed by #3 are the least irritating when it comes
 to portupgrade because you can at least have the service running
 while upgrading.  At least with #3 the upgrade gets paused until
 the propmpt is answered and you're then aware that some service
 will go away immediately so you can be prepared to restart it.

 #2 is extremely irritating because upgrading with portupgrade etc
 kills the service.  For instance isc-dhcpd* does this which means
 that for some time, dhcp may be unavailable.  It could be less
 irritating if it would automatically start the service, but that
 can have its own problems.

 Does the project have a preferred method for handling running
 daenmons on uninstall?  I know that Linux will even start daemons
 on install.

I think that almost all of this per-port code should be removed with
pkgng. The HANDLE_RC_SCRIPTS pkg.conf option will stop/start the rc.d
script during deinstallation/installation. By default, services are left
running.

Stopping the service on deinstall but not starting it again on install
seems like a particularly bad idea.

Apart from the annoyance of the restarts, automatic stopping and
starting is probably the best policy for having things just work. Some
daemons will crash or otherwise stop being useful when their files have
been deleted or replaced, and the new rc.d script might be unable to
stop the old daemon.

-- 
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Ports with daemons on uninstall...

2013-07-14 Thread Garrett Wollman
In article 20130714191725.ga30...@stack.nl, jil...@stack.nl writes:

Apart from the annoyance of the restarts, automatic stopping and
starting is probably the best policy for having things just work. Some
daemons will crash or otherwise stop being useful when their files have
been deleted or replaced, and the new rc.d script might be unable to
stop the old daemon.

Strongly agreed -- and it's what other operating systems do, either by
policy or by convention.

-GAWollman

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org