Re: Re-starting daemons across upgrades?
W dniu 2011-09-28 23:12, Matthias Andree pisze: So basically, we need a lever the operator can flip, and that typical ports running daemons, respect - that can state whether ports auto-restart deamons previously running (which would entail complaining the if needs manual intervention, like chasing configuration language changes, or other), or whether not to and just collect their names and list them so the operator can do it at a convenient time -- assuming the daemons are up to that task (continue running). That solution would satisfy most of the use cases. -- best regards, Lukasz Wasikowski ___ 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: Re-starting daemons across upgrades?
Am 18.09.2011 22:42, schrieb Łukasz Wąsikowski: We shouldn't go that way at all. Restarting service right after it's update is not a good thing. In many cases service will not start, because of needed configuration changes od other ports not recompiled or updated. The safe way is to not stop service at all. Let the system operator restart service manually when he finish all the needed update tasks. Well, the maintainer should know if the service can be restarted or needs manual intervention. For patch level upgrades - pathological cases like OpenLDAP or Cyrus-SASL interactions aside - you normally can restart the service without further ado. ___ 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: Re-starting daemons across upgrades?
W dniu 2011-09-28 20:53, Matthias Andree pisze: We shouldn't go that way at all. Restarting service right after it's update is not a good thing. In many cases service will not start, because of needed configuration changes od other ports not recompiled or updated. The safe way is to not stop service at all. Let the system operator restart service manually when he finish all the needed update tasks. Well, the maintainer should know if the service can be restarted or needs manual intervention. For patch level upgrades - pathological cases like OpenLDAP or Cyrus-SASL interactions aside - you normally can restart the service without further ado. That's true. Still, I often like to update software during the work hours and restart it in the middle of the night. It's not as annoying to customers as restarting critical service during peak hours. Restart time should be left for operator to decide. -- best regards Lukasz Wasikowski ___ 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: Re-starting daemons across upgrades?
Am 28.09.2011 22:40, schrieb Łukasz Wąsikowski: W dniu 2011-09-28 20:53, Matthias Andree pisze: We shouldn't go that way at all. Restarting service right after it's update is not a good thing. In many cases service will not start, because of needed configuration changes od other ports not recompiled or updated. The safe way is to not stop service at all. Let the system operator restart service manually when he finish all the needed update tasks. Well, the maintainer should know if the service can be restarted or needs manual intervention. For patch level upgrades - pathological cases like OpenLDAP or Cyrus-SASL interactions aside - you normally can restart the service without further ado. That's true. Still, I often like to update software during the work hours and restart it in the middle of the night. It's not as annoying to customers as restarting critical service during peak hours. Restart time should be left for operator to decide. So basically, we need a lever the operator can flip, and that typical ports running daemons, respect - that can state whether ports auto-restart deamons previously running (which would entail complaining the if needs manual intervention, like chasing configuration language changes, or other), or whether not to and just collect their names and list them so the operator can do it at a convenient time -- assuming the daemons are up to that task (continue running). On the other hand, one might wonder if in such cases it's not better to pre-build the required updated packages in Tinderbox, and install them as binary package at a convenient time later. My line of reasoning is that live updates (meaning replacing ANY parts of the system) probably aren't a good idea if there's a nontrivial number of ports to rebuild, unless you have a full set of old packages backed up (to roll back quickly if something goes amiss in the upgrade) and new ones pre-built but not yet installed (to roll forward quickly without the need to wait for - possibly failing - builds). ___ 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: Re-starting daemons across upgrades?
W dniu 2011-09-17 11:08, Matthias Andree pisze: - discuss whether we want/need to support this (a) in the framework that we currently use, (b) only in pkgng, (c) in portmaster and portupgrade where necessary. Or we could have a facility to check whether services are running. For example, I have some cron scripts, which are similar for all of the services that I'm watching. They run periodically and restart services if they are down. It does not matter if they are down because of an upgrade or a failure, so this solution is more general. Here's an example that I have for MySQL: Before we go that way, we should consider using runit by Gerrit Pape (smarden.org), Upstart, or port systemd. We shouldn't go that way at all. Restarting service right after it's update is not a good thing. In many cases service will not start, because of needed configuration changes od other ports not recompiled or updated. The safe way is to not stop service at all. Let the system operator restart service manually when he finish all the needed update tasks. -- best regards, Lukasz Wasikowski ___ 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: Re-starting daemons across upgrades?
Am 16.09.2011 22:00, schrieb Gabor Kovesdan: On 2011.09.16. 17:51, Matthias Andree wrote: Am 16.09.2011 11:51, schrieb Lev Serebryakov: Hello, Freebsd-ports. You wrote 16 сентября 2011 г., 0:28:07: Really? I thought it was supposed to be standard behaviour- the @stopdaemon line in pkg-plist facilitates that. While I totally understand why we do this, I have to say it's VERY VERY annoying behavior especially when one upgrading a remote system with multiple server daemon ports. One have to watch the whole process carefully and restart the daemon manually. Yep, and even more annoyingly is that it is completely inconsistent: some daemons are stopped, some not, etc. We do not currently have a standard procedure for that, nor do we record the necessary state -- perhaps we should just discuss, vote, and add a paragraph to the porter's handbook. We also need to bring the authors (or volunteers) for the de-facto standard upgrade tools into the loop. My thoughts: - give the user a choice to configure whether to restart services - optional: give the users a chance to configure this per-service - discuss whether we want/need to support this (a) in the framework that we currently use, (b) only in pkgng, (c) in portmaster and portupgrade where necessary. Or we could have a facility to check whether services are running. For example, I have some cron scripts, which are similar for all of the services that I'm watching. They run periodically and restart services if they are down. It does not matter if they are down because of an upgrade or a failure, so this solution is more general. Here's an example that I have for MySQL: Before we go that way, we should consider using runit by Gerrit Pape (smarden.org), Upstart, or port systemd. ___ 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: Re-starting daemons across upgrades?
On Sat, Sep 17, 2011 at 11:08:46AM +0200, Matthias Andree wrote: Am 16.09.2011 22:00, schrieb Gabor Kovesdan: On 2011.09.16. 17:51, Matthias Andree wrote: Am 16.09.2011 11:51, schrieb Lev Serebryakov: Hello, Freebsd-ports. You wrote 16 сентября 2011 г., 0:28:07: Really? I thought it was supposed to be standard behaviour- the @stopdaemon line in pkg-plist facilitates that. While I totally understand why we do this, I have to say it's VERY VERY annoying behavior especially when one upgrading a remote system with multiple server daemon ports. One have to watch the whole process carefully and restart the daemon manually. Yep, and even more annoyingly is that it is completely inconsistent: some daemons are stopped, some not, etc. We do not currently have a standard procedure for that, nor do we record the necessary state -- perhaps we should just discuss, vote, and add a paragraph to the porter's handbook. We also need to bring the authors (or volunteers) for the de-facto standard upgrade tools into the loop. My thoughts: - give the user a choice to configure whether to restart services - optional: give the users a chance to configure this per-service - discuss whether we want/need to support this (a) in the framework that we currently use, (b) only in pkgng, (c) in portmaster and portupgrade where necessary. Or we could have a facility to check whether services are running. For example, I have some cron scripts, which are similar for all of the services that I'm watching. They run periodically and restart services if they are down. It does not matter if they are down because of an upgrade or a failure, so this solution is more general. Here's an example that I have for MySQL: Before we go that way, we should consider using runit by Gerrit Pape (smarden.org), Upstart, or port systemd. Or (bet you didn't expect that from a hardcore daemontools user like me ;) our own FreeBSD Services Control - http://people.FreeBSD.org/~trhodes/fsc/ (once it's ready to enter the tree) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 because I didn't think of a good beginning of it. signature.asc Description: Digital signature
Re: Re-starting daemons across upgrades?
Doesn't fsc use pidfiles, unlike daemontools? Jos ___ 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-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
Am 16.09.2011 11:51, schrieb Lev Serebryakov: Hello, Freebsd-ports. You wrote 16 сентября 2011 г., 0:28:07: Really? I thought it was supposed to be standard behaviour- the @stopdaemon line in pkg-plist facilitates that. While I totally understand why we do this, I have to say it's VERY VERY annoying behavior especially when one upgrading a remote system with multiple server daemon ports. One have to watch the whole process carefully and restart the daemon manually. Yep, and even more annoyingly is that it is completely inconsistent: some daemons are stopped, some not, etc. We do not currently have a standard procedure for that, nor do we record the necessary state -- perhaps we should just discuss, vote, and add a paragraph to the porter's handbook. We also need to bring the authors (or volunteers) for the de-facto standard upgrade tools into the loop. My thoughts: - give the user a choice to configure whether to restart services - optional: give the users a chance to configure this per-service - discuss whether we want/need to support this (a) in the framework that we currently use, (b) only in pkgng, (c) in portmaster and portupgrade where necessary. ___ 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: Re-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
We do not currently have a standard procedure for that, nor do we record the necessary state -- perhaps we should just discuss, vote, and add a paragraph to the porter's handbook. We also need to bring the authors (or volunteers) for the de-facto standard upgrade tools into the loop. My thoughts: - give the user a choice to configure whether to restart services - optional: give the users a chance to configure this per-service - discuss whether we want/need to support this (a) in the framework that we currently use, (b) only in pkgng, (c) in portmaster and portupgrade where necessary. Just for ref regarding (c) on the portupgrade wiki page[1] it mentions using AFTERINSTALL in pkgtools.conf for doing automatic stop/start/restart. [1] http://wiki.freebsd.org/portupgrade ___ 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: Re-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
W dniu 2011-09-16 18:17, Eric pisze: Just for ref regarding (c) on the portupgrade wiki page[1] it mentions using AFTERINSTALL in pkgtools.conf for doing automatic stop/start/restart. I'm using it for a long time on my personal box and it's not that great. After some updates there is need to prepare the daemon - adjust configuration for example. Automatic restart will do much harm in that case. Another example: update when there's apache and php in new versions, system has also eaccelerator and some pecl's installed. If php was updated before apache, then apache restart via AFTERINSTALL will leave you with not working www server (because eaccelerator and pecl's were not recompiled). Updating ports should never turn off or restart service - thats my $0.02. -- best regards, Lukasz Wasikowski ___ 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: Re-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
2011/9/16 Łukasz Wąsikowski luk...@wasikowski.net: W dniu 2011-09-16 18:17, Eric pisze: Just for ref regarding (c) on the portupgrade wiki page[1] it mentions using AFTERINSTALL in pkgtools.conf for doing automatic stop/start/restart. I'm using it for a long time on my personal box and it's not that great. After some updates there is need to prepare the daemon - adjust configuration for example. Automatic restart will do much harm in that case. Another example: update when there's apache and php in new versions, system has also eaccelerator and some pecl's installed. If php was updated before apache, then apache restart via AFTERINSTALL will leave you with not working www server (because eaccelerator and pecl's were not recompiled). Updating ports should never turn off or restart service - thats my $0.02. I had a thought about implementing this in bsd.port.mk, but to tell the truth it would be better handled by your port manager of choice-- I can't find an option for portmaster, but I bet someone willing to send a working patch to dougb can earn themselves some brownie points. I would do it myself, but meh it doesn't upset me that much. However, having services not restarted after an upgrade can leave you with a) a vulnerable older service and b) a nasty shock when you decide to reboot six months later and it breaks :) Chris ___ 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: Re-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
Hello, Łukasz. You wrote 16 сентября 2011 г., 22:17:58: were not recompiled). Updating ports should never turn off or restart service - thats my $0.02. I agree with that. It is not difficult to REstart service by hands. But stopping service is another story. Many ports/packages stop service on dinstall/pkg_delete, and as result, if port with service are upgraded in the middle of large upgrade session (and it is not always possible to upgrade services SEPARATELY, due to dependences), here is large window when old service is stopped, but new cannot be started yet. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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: Re-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
W dniu 2011-09-16 20:25, Chris Rees pisze: However, having services not restarted after an upgrade can leave you with a) a vulnerable older service and b) a nasty shock when you decide to reboot six months later and it breaks :) I know that I should restart service after update and I will do it, I promise :) But I like to do it when I'm prepared for it, not when monitoring system starts screaming about a down service ;) -- best regards, Lukasz Wasikowski ___ 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: Re-starting daemons across upgrades? (was: Thank you (for making the ports less boring).)
Lev Serebryakov wrote: Hello, Łukasz. You wrote 16 сентября 2011 г., 22:17:58: were not recompiled). Updating ports should never turn off or restart service - thats my $0.02. I agree with that. It is not difficult to REstart service by hands. But stopping service is another story. Many ports/packages stop service on dinstall/pkg_delete, and as result, if port with service are upgraded in the middle of large upgrade session (and it is not always possible to upgrade services SEPARATELY, due to dependences), here is large window when old service is stopped, but new cannot be started yet. From my point of view, it is better to not stop the service by deinstall phase, if it is not started by install. If I do portmaster -a, deinstall of MySQL stops the mysql daemon and all dependent services are unavailable for a very long time - until all other packages are upgraded and administrator starts MySQL by hand. It can be hours. But I like the idea based on portupgrade AFTERINSTALL / (AFTERUPGRADE) - some kind of custom hooks, where user can define actions for specific packages / services. It can be restart in some cases, or write something to log, or send an e-mail, or print some user defined warning text about dependencies needed to be upgraded / restarted... and so on. Miroslav Lachman ___ 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: Re-starting daemons across upgrades?
On 2011.09.16. 17:51, Matthias Andree wrote: Am 16.09.2011 11:51, schrieb Lev Serebryakov: Hello, Freebsd-ports. You wrote 16 сентября 2011 г., 0:28:07: Really? I thought it was supposed to be standard behaviour- the @stopdaemon line in pkg-plist facilitates that. While I totally understand why we do this, I have to say it's VERY VERY annoying behavior especially when one upgrading a remote system with multiple server daemon ports. One have to watch the whole process carefully and restart the daemon manually. Yep, and even more annoyingly is that it is completely inconsistent: some daemons are stopped, some not, etc. We do not currently have a standard procedure for that, nor do we record the necessary state -- perhaps we should just discuss, vote, and add a paragraph to the porter's handbook. We also need to bring the authors (or volunteers) for the de-facto standard upgrade tools into the loop. My thoughts: - give the user a choice to configure whether to restart services - optional: give the users a chance to configure this per-service - discuss whether we want/need to support this (a) in the framework that we currently use, (b) only in pkgng, (c) in portmaster and portupgrade where necessary. Or we could have a facility to check whether services are running. For example, I have some cron scripts, which are similar for all of the services that I'm watching. They run periodically and restart services if they are down. It does not matter if they are down because of an upgrade or a failure, so this solution is more general. Here's an example that I have for MySQL: #!/bin/sh PID_FILE=/var/db/mysql/server.mypc.hu.pid PID=`cat $PID_FILE` EXECUTABLE=/usr/local/etc/rc.d/mysql-server start if test -r $PID_FILE ; then # pidfile exist, is it correct? if kill -CHLD $PID /dev/null 21; then # ok, exit silently exit 0 fi rm -f $PID_FILE fi echo echo Couldn't find the MySQL server running, retsarting.. echo $EXECUTABLE Gabor ___ 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: Re-starting daemons across upgrades?
On 09/16/11 20:00, Gabor Kovesdan wrote: #!/bin/sh PID_FILE=/var/db/mysql/server.mypc.hu.pid PID=`cat $PID_FILE` EXECUTABLE=/usr/local/etc/rc.d/mysql-server start if test -r $PID_FILE ; then # pidfile exist, is it correct? if kill -CHLD $PID /dev/null 21; then # ok, exit silently exit 0 fi rm -f $PID_FILE fi echo echo Couldn't find the MySQL server running, retsarting.. echo $EXECUTABLE #!/bin/sh PIDS=$(/usr/bin/pgrep rsyslogd) if [ $? -eq 1 ]; then /usr/bin/killall rsyslogd 2/dev/null /usr/local/etc/rc.d/rsyslogd start /dev/null else exit 1 fi exit 0 -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Infrastructure,Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ 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: Re-starting daemons across upgrades?
On 16 Sep 2011 21:16, Gabor Kovesdan ga...@freebsd.org wrote: On 2011.09.16. 17:51, Matthias Andree wrote: Am 16.09.2011 11:51, schrieb Lev Serebryakov: Hello, Freebsd-ports. You wrote 16 сентября 2011 г., 0:28:07: Really? I thought it was supposed to be standard behaviour- the @stopdaemon line in pkg-plist facilitates that. While I totally understand why we do this, I have to say it's VERY VERY annoying behavior especially when one upgrading a remote system with multiple server daemon ports. One have to watch the whole process carefully and restart the daemon manually. Yep, and even more annoyingly is that it is completely inconsistent: some daemons are stopped, some not, etc. We do not currently have a standard procedure for that, nor do we record the necessary state -- perhaps we should just discuss, vote, and add a paragraph to the porter's handbook. We also need to bring the authors (or volunteers) for the de-facto standard upgrade tools into the loop. My thoughts: - give the user a choice to configure whether to restart services - optional: give the users a chance to configure this per-service - discuss whether we want/need to support this (a) in the framework that we currently use, (b) only in pkgng, (c) in portmaster and portupgrade where necessary. Or we could have a facility to check whether services are running. For example, I have some cron scripts, which are similar for all of the services that I'm watching. They run periodically and restart services if they are down. It does not matter if they are down because of an upgrade or a failure, so this solution is more general. Here's an example that I have for MySQL: #!/bin/sh PID_FILE=/var/db/mysql/server.mypc.hu.pid PID=`cat $PID_FILE` EXECUTABLE=/usr/local/etc/rc.d/mysql-server start if test -r $PID_FILE ; then # pidfile exist, is it correct? if kill -CHLD $PID /dev/null 21; then # ok, exit silently exit 0 fi rm -f $PID_FILE fi echo echo Couldn't find the MySQL server running, retsarting.. echo $EXECUTABLE I would prefer to parse the output of rc status, but I presume this script is more specialised. Chris ___ 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
