Currently xcs is run by xend in xen-unstable by simply making it a child process. If you launch xend from an ssh session, the session won''t exit because the xcs still is connected to it''s controlling terminal. xcs should daemonize itself to prevent this from happening. This patch does that along with making the domain id => port mapping dynamically allocated. Regards, -- Anthony Liguori Linux Technology Center (LTC) - IBM Austin E-mail: aliguori@us.ibm.com Phone: (512) 838-1208 Signed-off-by: Anthony Liguori
> xcs should daemonize itself to prevent this from happening.Actually, I''d really like an option to keep xend and xensv in the foreground (and log to stdout), as I want to run them under runit (like daemontools) for XenCD. I haven''t gotten there yet, but if anyone touches this code, it''d be nice to leave this possibility open in the design. -- Jared Rhine <jared@wordzoo.com> ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Jared Rhine wrote:>Actually, I''d really like an option to keep xend and xensv in the >foreground (and log to stdout), as I want to run them under runit (like >daemontools) for XenCD. I haven''t gotten there yet, but if anyone >touches this code, it''d be nice to leave this possibility open in the >design. > >I should have mentioned in the note that I also added a -i switch to xcs that keeps it in the foreground. If I''m playing around in Xend and find where it daemonizes I''ll submit a patch to do the same. It seems to be a pretty standard option in most daemons. Regards, -- Anthony Liguori anthony@codemonkey.ws ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Fri, 28 Jan 2005 16:28:13 -0800, Jared Rhine <jared@wordzoo.com> wrote:>> xcs should daemonize itself to prevent this from happening. > > Actually, I''d really like an option to keep xend and xensv in the > foreground (and log to stdout), as I want to run them under runit (like > daemontools) for XenCD. I haven''t gotten there yet, but if anyone > touches this code, it''d be nice to leave this possibility open in the > design.Yes, definitely. Twisted has code for doing daemonization/pidfile management that is much more flexible than xend''s current approach. I looked into refactoring it to use that as well as adding support for Twisted''s remote-object protocol, but I kept finding things about xend''s architecture I wanted to change, so I gave up temporarily :) I will probably revisit this after finishing my current project, which just talks to xend via its HTTP protocol. Basically what needs to be done is to remove entirely the code in SrvDaemon that starts things up, and use ''twistd'' to start it instead. Allen ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel