Hi, I worked on the xendomains init script. It now allows the user to configure what he wants to be done on xendomains stop: sysrq, migrate, save, or shutdown. For this to be safe, a timeout has been introduced (optional). On start, saved domains may be restored, and not yet started domains from the auto start dir will be started in addition. status reports missing domains, restart and reload work as well. The init script is somewhat SUSE-ish, but it should work on LSB compliant and on RH based distros as well. I would appreciate this to be put into tools/examples/init.d/ Signed-off-by: Kurt Garloff <garloff@suse.de> Best, -- Kurt Garloff, Director SUSE Labs, Novell Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Oct 19, 2005 at 11:44:39AM +0200, Kurt Garloff wrote:> Hi, > > I worked on the xendomains init script. > > It now allows the user to configure what he wants to be done on > xendomains stop: sysrq, migrate, save, or shutdown. > For this to be safe, a timeout has been introduced (optional). > On start, saved domains may be restored, and not yet started > domains from the auto start dir will be started in addition. > status reports missing domains, restart and reload work as well. > > The init script is somewhat SUSE-ish, but it should work on LSB > compliant and on RH based distros as well. > > I would appreciate this to be put into tools/examples/init.d/ > > Signed-off-by: Kurt Garloff <garloff@suse.de>I''ve committed this now, thanks Kurt. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Ewan, On Wed, Oct 26, 2005 at 06:11:08PM +0100, Ewan Mellor wrote:> On Wed, Oct 19, 2005 at 11:44:39AM +0200, Kurt Garloff wrote: > > I would appreciate this to be put into tools/examples/init.d/ > > > > Signed-off-by: Kurt Garloff <garloff@suse.de> > > I''ve committed this now, thanks Kurt.Cool, thanks! I think about adding one more feature to the script: XENDOMAINS_MEMSET0=xxx would make the script issue xm mem-set 0 xxx on xendomains start and restore the old mem allocation of dom0 on xendomains stop. Unless someone tells me it''s not worth doing ... Best, -- Kurt Garloff, Director SUSE Labs, Novell Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> I think about adding one more feature to the script: > XENDOMAINS_MEMSET0=xxx > would make the script issue xm mem-set 0 xxx on xendomains > start and restore the old mem allocation of dom0 on xendomains stop. > > Unless someone tells me it''s not worth doing ...You know about dom0-min-mem in xend-config.sxp, right? It''s a related feature, but I don''t object to adding the one you''re requesting. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 26/10/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> > I think about adding one more feature to the script:Here''s another feature... I''m not sure if anyone else will need this, but we had a requirement to log all console output, and to have console windows available at all time and potentially multiplexed between users. I solved it by having each xen domain start up in a persistent window inside a screen session. My (gentoo) xendomains start() and stop() currently look like: start() { einfo "Starting ${AUTODIR} Xen domains" if [[ ${SCREEN} == "yes" ]]; then screen -d -m -S xen -t xen-cbc0 screen -r xen -X zombie dr logrotate -f /usr/share/xen/xen-consoles-logrotate screen -r xen -X logfile /var/log/xen-consoles/%t screen -r xen -X logfile flush 1 screen -r xen -X deflog on fi # Create all domains with config files in AUTODIR. for dom in $(ls ${AUTODIR}/* 2>/dev/null); do name=$(get_domname ${dom}) if ! is_running ${name} ; then ebegin " Starting domain ${name}" if [[ ${SCREEN} == "yes" ]]; then screen -r xen -X screen -t ${name} xm create ${dom} -c else xm create --quiet ${dom} fi eend $? else einfo " Not Starting domain ${name} - allready running" fi done } stop() { einfo "Shutting down ${AUTODIR} Xen domains" # Stop all domains with config files in AUTODIR. for dom in $(ls ${AUTODIR}/* 2>/dev/null); do name=$(get_domname ${dom}) if is_running ${name} ; then ebegin " Stopping domain ${name}" xm shutdown --wait ${name} >/dev/null eend $? else einfo " Not Stopping domain ${name} - not running" fi done if [[ ${SCREEN} == "yes" ]]; then screen -r xen -X quit fi } It should be easy to adapt this to the generic script if others find it useful. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi Ian, On Wed, Oct 26, 2005 at 08:05:06PM +0100, Ian Pratt wrote:> > I think about adding one more feature to the script: > > XENDOMAINS_MEMSET0=xxx > > would make the script issue xm mem-set 0 xxx on xendomains > > start and restore the old mem allocation of dom0 on xendomains stop. > > > > Unless someone tells me it''s not worth doing ... > > You know about dom0-min-mem in xend-config.sxp, right? It''s a related > feature, but I don''t object to adding the one you''re requesting.Sure, I even use it :-) garloff@tpkurt:~ [0]$ grep -e ''^[^#]'' /etc/xen/xend-config.sxp | grep ''min-mem'' (dom0-min-mem 256) But: 1. Not everybody wants to use this 2. Shrinking dom0 on demand can fail Best, -- Kurt Garloff, Director SUSE Labs, Novell Inc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Here''s another feature... I''m not sure if anyone else will > need this, but we had a requirement to log all console > output, and to have console windows available at all time and > potentially multiplexed between users. I solved it by having > each xen domain start up in a persistent window inside a > screen session.We''ve been thinking about having an option to fork off a ''screen'' session when creating a vm. It would be good if you could write a few notes to describe what the runes you use to start screen are, and whether you think it makes sense to integrate this with ''xm''? Thanks, Ian> My (gentoo) xendomains start() and stop() currently look like: > > start() { > einfo "Starting ${AUTODIR} Xen domains" > if [[ ${SCREEN} == "yes" ]]; then > screen -d -m -S xen -t xen-cbc0 > screen -r xen -X zombie dr > logrotate -f /usr/share/xen/xen-consoles-logrotate > screen -r xen -X logfile /var/log/xen-consoles/%t > screen -r xen -X logfile flush 1 > screen -r xen -X deflog on > fi > # Create all domains with config files in AUTODIR. > for dom in $(ls ${AUTODIR}/* 2>/dev/null); do > name=$(get_domname ${dom}) > if ! is_running ${name} ; then > ebegin " Starting domain ${name}" > if [[ ${SCREEN} == "yes" ]]; then > screen -r xen -X screen -t > ${name} xm create ${dom} -c > else > xm create --quiet ${dom} > fi > eend $? > else > einfo " Not Starting domain ${name} > - allready running" > fi > done_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 27/10/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:> It would be good if you could write a few notes to describe what the > runes you use to start screen are, and whether you think it makes sense > to integrate this with ''xm''?Ok, this sequence will create a single screen session with a dom0 window, then opens a named window for each domU. The screen is initially detached (ie. you can''t see it), you can attach to it with screen -r or screen -x. You then see all of your domains as windows (ctrl-a " for a list).> > start() { > > einfo "Starting ${AUTODIR} Xen domains" > > if [[ ${SCREEN} == "yes" ]]; then > > screen -d -m -S xen -t dom0"-d -m" start screen session, but do not attach to it "-S xen" call the session "xen" "-t dom0" sets the title of the initial console - this will be a normal terminal on dom0.> > screen -r xen -X zombie dr"-r xen" name of session "-X" send a command "zombie dr" the command. By default, a window closes when it''s process dies. This changes that so windows remain persistent, so you can see xen domains reboot etc. The d and r keys are shortcuts to destroy/resurrect the window process, at the time it seemed like a good idea to be able to hit "r" in the console window and restart the domain.> > logrotate -f /usr/share/xen/xen-consoles-logrotateforce a run of a logrotate script which rotates the files in /var/log/xen-consoles/> > screen -r xen -X logfile /var/log/xen-consoles/%tsend a command to session "xen". logfile specifies a generic filename, %t is replaced with the name of the window for each domainU session.> > screen -r xen -X logfile flush 1flush the log every second> > screen -r xen -X deflog onturn on logging by default> > fi > > # Create all domains with config files in AUTODIR. > > for dom in $(ls ${AUTODIR}/* 2>/dev/null); do > > name=$(get_domname ${dom}) > > if ! is_running ${name} ; then > > ebegin " Starting domain ${name}" > > if [[ ${SCREEN} == "yes" ]]; then > > screen -r xen -X screen -t > > ${name} xm create ${dom} -c"screen -r xen" select screen called "xen" "-X screen -t name" run internal screen command "screen -t name" which creates a window with the given name, and runs "xm create /etc/xen/auto/dom -c" inside that window On stop(): screen -r xen -X quit This closes the screen session called "xen". Does it make sense to integrate this with xm? I think so, since then you can have a console screen session for any domain, not just ones you autostart. Also it multiplexes access to the console - I''m not sure what happens if two users run "xm console" at the same time? I don''t think it works. The console logs are useful for viewing domain crashes and other things that don''t make it to syslog. And it''s nice to be able to reboot in a window and see the full shutdown and startup. Regards, Chris _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, first: thanks for the nice script :) I had a (more cosmetic) problem with it:> The init script is somewhat SUSE-ish, but it should work on LSB > compliant and on RH based distros as well.Almost for the LSB-Part: LSB defines that the ini script functions like "log_success_msg" can be defined as shell aliases: http://www.linuxbase.org/spec/refspecs/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html The problem with that: shell aliases are usually not enabled in scripts (so I''ll have to blame LSB for allowing this in init script functions) and the real problem, they are never used (at least for bash) in if/then/else blocks or functions, which is exactly what your script does. So, IF a distribution decides to implement log_success_msg LSB conforming as alias, as current RedHat distributions (like RHEL4 and including FC5) do, this will fail and give "log_success_msg: command not found". I think this is a bad idea (see above), but can''t blame RedHat for following LSB by the word. And as you check for LSB first and then for redhat, newer redhat distributions will take the LSB case. I don''t think there''s a nice way to make this fully LSB compatible as these funtions are usually called within functions, but I''d highly suggest to use a "specific before generic" approach for the "distribution specific emulations". Means: test for the redhat specific part first and then use LSB. For the LSB part I''d add an if-test to check if log_success_msg is an alias and use the generic emulation in case it is (assuming log_error_msg would be an alias too when log_success_msg is). I attached a patch doing exactly this, resulting in a clean run on the redhat based distributions and fixing it for possible others using an alias in their LSB conformity scripts, leaving it unchanged for the rest. Hopefully :) @Kurt: as this is your init-script, would you like to review the patch and in case you think it''s OK submit it to the official source tree? Or whoever is responsible for this :) (:ul8er, r@y _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, first: thanks for the nice script :) (second: resent, hope my first mail using a wrong From: is ignored by the list daemon) I had a (more cosmetic) problem with it:> The init script is somewhat SUSE-ish, but it should work on LSB > compliant and on RH based distros as well.Almost for the LSB-Part: LSB defines that the ini script functions like "log_success_msg" can be defined as shell aliases: http://www.linuxbase.org/spec/refspecs/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html The problem with that: shell aliases are usually not enabled in scripts (so I''ll have to blame LSB for allowing this in init script functions) and the real problem, they are never used (at least for bash) in if/then/else blocks or functions, which is exactly what your script does. So, IF a distribution decides to implement log_success_msg LSB conforming as alias, as current RedHat distributions (like RHEL4 and including FC5) do, this will fail and give "log_success_msg: command not found". I think this is a bad idea (see above), but can''t blame RedHat for following LSB by the word. And as you check for LSB first and then for redhat, newer redhat distributions will take the LSB case. I don''t think there''s a nice way to make this fully LSB compatible as these funtions are usually called within functions, but I''d highly suggest to use a "specific before generic" approach for the "distribution specific emulations". Means: test for the redhat specific part first and then use LSB. For the LSB part I''d add an if-test to check if log_success_msg is an alias and use the generic emulation in case it is (assuming log_error_msg would be an alias too when log_success_msg is). I attached a patch doing exactly this, resulting in a clean run on the redhat based distributions and fixing it for possible others using an alias in their LSB conformity scripts, leaving it unchanged for the rest. Hopefully :) @Kurt: as this is your init-script, would you like to review the patch and in case you think it''s OK submit it to the official source tree? Or whoever is responsible for this :) (:ul8er, r@y _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Thu, Mar 30, 2006 at 06:09:33AM +0200, Florian Kirstein wrote:> Hi, > > first: thanks for the nice script :) (second: resent, hope my first mail > using a wrong From: is ignored by the list daemon) > > I had a (more cosmetic) problem with it: > > The init script is somewhat SUSE-ish, but it should work on LSB > > compliant and on RH based distros as well. > Almost for the LSB-Part: LSB defines that the ini script functions > like "log_success_msg" can be defined as shell aliases: > http://www.linuxbase.org/spec/refspecs/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html > > The problem with that: shell aliases are usually not enabled in scripts > (so I''ll have to blame LSB for allowing this in init script functions) > and the real problem, they are never used (at least for bash) in > if/then/else blocks or functions, which is exactly what your script > does. > > So, IF a distribution decides to implement log_success_msg LSB conforming > as alias, as current RedHat distributions (like RHEL4 and including > FC5) do, this will fail and give "log_success_msg: command not found". > I think this is a bad idea (see above), but can''t blame RedHat for > following LSB by the word. And as you check for LSB first and then > for redhat, newer redhat distributions will take the LSB case. > > I don''t think there''s a nice way to make this fully LSB compatible > as these funtions are usually called within functions, but I''d > highly suggest to use a "specific before generic" approach for the > "distribution specific emulations". Means: test for the redhat > specific part first and then use LSB. For the LSB part I''d add > an if-test to check if log_success_msg is an alias and use the > generic emulation in case it is (assuming log_error_msg would be an > alias too when log_success_msg is). > > I attached a patch doing exactly this, resulting in a clean run on the > redhat based distributions and fixing it for possible others using an > alias in their LSB conformity scripts, leaving it unchanged for the > rest. Hopefully :) > > @Kurt: as this is your init-script, would you like to review the patch > and in case you think it''s OK submit it to the official source tree? > Or whoever is responsible for this :) > > (:ul8er, r@y+1 Associated bug at Red Hat is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171056 yes this is a problem, but I didn''t tried the patch yet, I assume you tested it on FC5, Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi,> Associated bug at Red Hat is > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171056Oh, if I had known the old version (completely different from the more advanced current one) of the script already had the same problem, I had searched there :)> yes this is a problem, but I didn''t tried the patch yet, I assume you tested > it on FC5,The patch works for xen 3.0.1 (and newer, possibly some older) on all redhat-based distributions, as it simply moves the redhat check before the LSB check (like Jonathan did for the older script). Additionally it "fixes" the alias problem for possible other distributions which also use aliases to build the LSB compatibility. And yes: the patch applies cleanly when added for example as Patch13 (using -p1) to the FC5 xen SRPM, even though I intended it to be included in the main xen distribution as I don''t see any negative impacts - and it''s a bug in the script in the first place to assume no aliases are used for LSB. For RedHat I''d independently suggest to follow https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171052 and change the lsb-compatibility. Sure, LSB explicitly allows use of aliases as the link in my original mail shows, so it is not really a bug if you read the spec by the word, but IMHO it''s still a bad idea to do so :) Using functions like suggested in Bug 158183 and the one linked above simply will result in less trouble also in possible other cases. (:ul8er, r@y (oh my god, how much text for such a simple issue, sorry to all :) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, replying to my almost a year old message:> The patch works for xen 3.0.1 (and newer, possibly some older)... I''ve finally build this as patch for current xen-unstable.hg. RedHat followed the suggestion to reimplement LSB compatibility in RHEL5, but for all the others (including FC6) this patch still is needed. It''s also referenced as solution in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171056 and I''m using it since I first posted it on all my xen builds, don''t see problems there, should not harm non-redhat dists. (:ul8er, r@y # HG changeset patch # User ray@build.ray.net # Node ID a96bf6276e4fa1323a0ffe260f0029018b57dfda # Parent 1c5e6239a8d0381fdbf56d4926f986d7f0ec07c0 Fix init.d/xendomains startup script so log_error and log_success will also work on redhat-based distributions before RHEL 5. See discussion "xendomains init script" about a year ago on xen-devel. Signed-off-by: Florian Kirstein <ray@ray.net> diff -r 1c5e6239a8d0 -r a96bf6276e4f tools/examples/init.d/xendomains --- a/tools/examples/init.d/xendomains Sun Feb 25 23:58:33 2007 -0600 +++ b/tools/examples/init.d/xendomains Wed Feb 28 06:08:20 2007 +0100 @@ -58,18 +58,7 @@ else _SMSG=(done failed failed missed failed skipped unused failed failed) _RC_UNUSED=6 fi - if test -e /lib/lsb/init-functions; then - # LSB - . /lib/lsb/init-functions - echo_rc() - { - if test ${_RC_RV} = 0; then - log_success_msg " [${_SMSG[${_RC_RV}]}] " - else - log_failure_msg " [${_SMSG[${_RC_RV}]}] " - fi - } - elif test -e /etc/init.d/functions; then + if test -e /etc/init.d/functions; then # REDHAT . /etc/init.d/functions echo_rc() @@ -81,6 +70,24 @@ else failure " [${_SMSG[${_RC_RV}]}] " fi } + elif test -e /lib/lsb/init-functions; then + # LSB + . /lib/lsb/init-functions + if alias log_success_msg >/dev/null 2>/dev/null; then + echo_rc() + { + echo " [${_SMSG[${_RC_RV}]}] " + } + else + echo_rc() + { + if test ${_RC_RV} = 0; then + log_success_msg " [${_SMSG[${_RC_RV}]}] " + else + log_failure_msg " [${_SMSG[${_RC_RV}]}] " + fi + } + fi else # emulate it echo_rc() _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 28/2/07 05:20, "Florian Kirstein" <xenlist@custom.ray.net> wrote:> ... I''ve finally build this as patch for current xen-unstable.hg. > RedHat followed the suggestion to reimplement LSB compatibility in > RHEL5, but for all the others (including FC6) this patch still is > needed. It''s also referenced as solution in > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171056 > and I''m using it since I first posted it on all my xen builds, don''t > see problems there, should not harm non-redhat dists.Why is the LSB case moved to after the RedHat case? LSB looks like a more specific check (it looks for a file with ''lsb'' in the path for a start!) so wouldn''t it be better to leave it where it is? Or does that not work? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi,> Or does that not work?Exactly. The LSB way does not work on Redhat-based distributions prior to RHEL5. And that''s not /really/ a RH bug, as LSB explicitly allows their alias implementation, which unfortunately can''t be used the way the script tries to. Really a silly problem caused by the LSB spec allowing aliases.> Why is the LSB case moved to after the RedHat case? LSB looks like a more > specific check (it looks for a file with ''lsb'' in the path for a start!)No, LSB is the most generic check, as most distributions have LSB compliance scripts today. As the script''s first check is for SUSE''s /etc/rc.status, it''s only logical to check for RedHat''s /etc/init.d/functions second, and only then go for the generic case, LSB. Especially as that doesn''t work on all current RedHat''s and causes /etc/rc.d/init.d/xendomains: line 67: log_success_msg: command not found errors turning up in all (Fedora, Redhat) bugzillas :) I don''t see any non-redhat Distribution having an /etc/init.d/functions (which does not implement the RH success and failure function), so it should cause no problem to move this up, but it will make the problem disappear on all RH and Fedora Versions out there. And as RHs old LSB implementation isn''t a bug (according to the spec), we have to fix our init script and can''t hope for fixes in older Fedora/RedHat''s LSB. See my post last year... (:ul8er, r@y _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel