The current version doesn't allow to flexible configure the start and stop setting of the container also it doesn't allow to know when the container was stopped Reproducible: Always
Created attachment 390410 [details] /etc/conf.d/lxc
Created attachment 390412 [details] /etc/init.d/lxc
My solution should solve these problems
Created attachment 390414 [details] /etc/init.d/lxc
Created attachment 390416 [details] /etc/init.d/lxc
Created attachment 390418 [details] /etc/init.d/lxc corrected typos
Please attach diffs to make review easier. Please also describe what problem are you are trying to solve in details. Give me an example scenario to understand it.
*** Bug 525956 has been marked as a duplicate of this bug. ***
Created attachment 392298 [details] /etc/init.d/lxc some trivial fixes
(In reply to Markos Chandras from comment #7) > Please attach diffs to make review easier. ====================== # diff -su /usr/portage/app-emulation/lxc/files/lxc.initd.3 /etc/init.d/lxc |grep -cE '^ [^#]' 9 # wc -l /usr/portage/app-emulation/lxc/files/lxc.initd.3 /etc/init.d/lxc 137 /usr/portage/app-emulation/lxc/files/lxc.initd.3 177 /etc/init.d/lxc ---------------------- differences TOO MUCH. In fact, the script is being rewritten from scratch. I don't think that diff help to make review > Please also describe what problem are you are trying to solve in details. > Give me an example scenario to understand it. ok. I'll try. Let's look at lxc.initd.3: ====================== checkconfig() { ... utsname=$(lxc_get_var lxc.utsname) if [ ${CONTAINER} != ${utsname} ]; then eerror "You should use the same name for the service and the" eerror "container. Right now the container is called ${utsname}" return 1 fi ... ---------------------- for what this is? that terrible will happen if they will be different? maybe utsname is used here /sys/fs/cgroup/cpuset/lxc/NAME ? not. there is used value from parameter --name=NAME you can check it out. it is an unnecessary restriction. ====================== ... start() { checkconfig || return 1 rm /var/log/lxc/${CONTAINER}.log rootpath=$(lxc_get_var lxc.rootfs) # Check the format of our init and the chroot's init, to see # if we have to use linux32 or linux64; always use setarch # when required, as that makes it easier to deal with # x32-based containers. case $(scanelf -BF '%a#f' ${rootpath}/sbin/init) in EM_X86_64) setarch=linux64;; EM_386) setarch=linux32;; esac ebegin "Starting ${CONTAINER}" env -i ${setarch} $(type -p lxc-start) -l WARN -n ${CONTAINER} -f ${CONFIGFILE} -d -o /var/log/lxc/${CONTAINER}.log sleep 0.5 # lxc-start -d will _always_ report a correct startup, even if it # failed, so rather than trust that, check that the cgroup exists. [ -d /sys/fs/cgroup/cpuset/lxc/${CONTAINER} ] eend $? } ... ====================== this script hopelessly outdated. * > rootpath=$(lxc_get_var lxc.rootfs) what if I don't use lxc.rootfs in config? what if I include this parameter from other config by lxc.include? rootpath will get a blank value? and below we will get archtecture of host system? What if, for any reson, I want to use own shell instead of /sbin/init? This test makes no sense. As far as I know, lxc-start perfectly launches himself x86 code on x86_64 platform * What if previeusly container stopped with some errors on start and directory /sys/fs/cgroup/cpuset/lxc/${CONTAINER} is not retired? in this case, will be created directories /sys/fs/cgroup/{cpuset,<and other>}/lxc/${CONTAINER}-1 and so forth sequentially in which case you should never check these directories, or check them just before the lxc-start yet * what if I need to configure LOGLEVEL, or set --console-log lxc-start has a lot of parameters, but the script does not allow them to easily change individually for each container. I can't even use somthink like this alias lxc-start='lxc-start <my own parameters>' becouse of $(type -p lxc-start) * what if container wlii stop? how OpenRC will know about it? lxc-start HAS PARAMETER --pidfile, but it is not used!! What about this bugs: https://bugs.gentoo.org/show_bug.cgi?id=525956 https://bugs.gentoo.org/show_bug.cgi?id=416643 My script solves all these problems. Maybe, my English too bad to correctly write documentation. I know, comments on my lxc.confd ,ust be more complete Maybe some functions, such as freeze/unfreeze/attach/info unnecessary in init script(I thought that they may be useful in some situations) Maybe some code design can be made better, but this script is definitely better than what is used now just read it
Created attachment 393250 [details, diff] the difference beween original script from portage and the proposed version > Please attach diffs to make review easier. I added diff. I hope this helps to make review easier.
The bug status is UNCONFIRMED, but i confirm the bug on my Gentoo. lxc.lxcpath not read.
Well i can review the patches but I can't test them since I am using systemd everywhere so I am more than happy to commit them as-is if that works for you
> I am more than happy to commit them as-is if that works for you yes, this work for me since I published it here now I'm don't use all variables like a rc_lxc__lxcpath or rc_lxc_..timeout, but before writing here, I tried test all of them. what I'm not sure - is the quality of comments in English in files lxc.confd and lxc.initd Unfortunately, my English is poor I hope that there are interested people who will verify literacy of comments
I tried to apply the patches by they no longer apply on top of lxc.initd.3. Can you please have a look and create new patches based on the latest files in the tree? Thanks
Created attachment 405162 [details] /etc/init.d/lxc * fixed bug with lxcpath * added possibility to use lxc-execute instead lxc-start to run any command instead /sbin/init * I hope that reading this script is now a little easier
Created attachment 405164 [details] /etc/conf.d/lxc added example of variable rc_lxc_foo_bar__linuxrc this variable may be used to run with lxc-execute
Created attachment 405166 [details, diff] the difference beween original script from portage and the proposed version
Created attachment 405168 [details, diff] the difference beween original script from portage and the proposed version previous diff was bad
Thanks for the diff. However, it's more complex than I thought so it will take a bit of time for me to process it.
Can you please write a simple post_pkginst() message to explain to users how to migrate their containers the new init.d file (assuming there are migration steps).
Furthermore, does it make sense for you to try and upstream these files? The LXC project already has various init files (not for Gentoo unfortunately) but it would be nice to have these files in the upstream repository. https://github.com/lxc/lxc/tree/master/config/init Anyway, that's not critical, just a NiceToHave thing.
