On Sun, 2013-06-02 at 11:18 +0530, Shridhar Daithankar wrote:
> Hi All,
> I looked around and didn't find a script that generates systemd unit
> files for containers.
> Here is the script. I hope people find it useful and it is included by
> default in lxc upstream.
That's an interesting suggestion that might be worth consideration over
on the lxc-devel list where we are currently considering autostart
proposals. Not sure if you're doing this under Arch Linux or Fedora (or
maybe CentOS) but we will need some suggestions for incorporating the
proposed boot management into the systemd based hosts.
Current proposal on the table is discussing having an autostart flag,
boot delay, and group name contained in the container's configuration
file. If a container is then transported from one host to another, the
boot attributes are transported along with it. It's also highly
desirable to have a uniform autoboot convention such that you're not
dependent on whether you're running systemd (CentOS, SL, Fedora, Arch)
or upstart (Ubuntu and others) or the older sysvinit scripts. One
highly desirable characteristic is to have the processed more or less
consistent regardless of the host platform, keeping it as platform
agnostic as possible. The current Ubuntu convention of having links
in /etc/lxc/boot/{container} to the container config
in /var/lib/lxc/{container}/config may or may not end up being part of
that proposal.
Under the proposed paradigm, we would not be using systemd unit files
for autostarting the containers and, rather, have a service that runs
our startup process that would then handling this. Doing this purely as
systemd unit devices would not be portable from, say, a Fedora host to
an Ubuntu host. Even moving this from a Fedora host to another Fedora
host (or Arch), we would have to also remove and rebuild unit files on
each host, as that wouldn't have been automatically transported. This
also would be challenging to work with prioritizing or ordering the boot
order independent of the container name.
Nice suggestion, however. I may play with it on some of my hosts (I run
Fedora and I've been working on the Fedora lxc-create template). I
don't think I would incorporate it into the container creation
templates, however, because of the current discussions underway. This
is one of the things we need to hash out before cutting 1.0.
> Thanks
Thank you.
> -----------------
> #!/bin/bash
>
> function usage()
> {
> echo "Usage:$0 enable|disable <container name>"
> }
>
> if [ $# -lt 2 ] ;
> then
> usage
> exit -1;
> fi
>
> export
> UNITFILE=/etc/systemd/system/multi-user.target.wants/$2_container.service
>
>
> case $1 in
> enable)
> cat <<EOF > $UNITFILE
> [Unit]
> Description=Container $2 service
>
> [Service]
> Type=forking
> ExecStart=/usr/bin/lxc-start -d -n $2
> ExecStop=/usr/bin/lxc-stop -n $2
> RemainAfterExit=yes
>
> [Install]
> WantedBy=multi-user.target
> EOF
>
> ;;
> disable)
> rm $UNITFILE
> ;;
> *)
> usage
> ;;
> esac
>
> -----------------
> --
> Regards
> Shridhar
Regards,
Mike
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
