So, I think we're miscommunicating a bit here... On Mon, Feb 4, 2019 at 4:10 PM Grant Taylor <gtay...@gentoo.tnetconsulting.net> wrote: > > On 02/04/2019 11:55 AM, Rich Freeman wrote: > > IMO I would separate your container logic from your service manager logic. > > I'm not exactly sure what you mean by "container logic" vs "service > manager logic" and how they differ. I'm assuming that the former > creates / destroys the container and that the latter manages > (re)starting/stopping services where ever they are at.
I'm saying that an init.d script shouldn't try to do anything other than initialize a service, which should be implemented outside the init.d script. So, if you have a shell script that launches a container, then you should call it from the init.d script. You shouldn't merge them into a single init.d script that has 30 lines of container setup logic or whatever. > > I'd like to see a way that I can have standard service init scripts and > use them where ever I want them, either inside a container or outside on > the host. Of course. That shell script that launches a container could very well just launch sysvinit which runs openrc which runs another set of init.d scripts INSIDE the container to initialize it. > I'm wanting to avoid having an init script that creates the container > and starts services therein. I'd rather start the container and then > start the services therein using the same type of init scripts, just > called within different contexts. Yup - though I would think the scripts inside the container would be fairly different, as they are doing different things. The scripts inside the container aren't starting containers, for a start... > > As a result, I'd suggest considering using sysvinit inside your > > containers to do the work. > > That is a possibility. But I feel like that's tantamount to saying > "Gentoo doesn't have an answer for what you're wanting to do, so just > use Sys V init scripts." I don't like it. > > I like the idea of re-using standard OpenRC / NetifRC scripts inside the > containers too. Especially if the services don't conflict anywhere. To > me, this re-uses the existing Gentoo methodology in different contexts. OpenRC/Netifrc are run by sysvinit in Gentoo, as I mention later on. These two are not mutually exclusive. > The more that I think about it, largely in response to emails in this > thread, I believe that I want the same overall thing to create the > network between the default / main / unnamed NetNS and the container, as > well as likely re-using the OpenRC / NetifRC scripts to configure things > inside the container. Not sure how much of it would be re-use. The scripts inside/outside the container would likely have different roles. > I think, and would be curious to have someone confirm or refute, that I > could add configuration information to /etc/conf.d/net for the xyz123 > interface inside the container and use an /etc/init.d/net.xyz123 init > script sym-linked to /etc/init.d/net.lo script. > > My host would not have net.xyz123 in any runlevel. Certainly not boot > or default. Honestly, I wouldn't go sticking container init.d scripts inside the host init.d. I mean, I guess you could, but again, separation of concerns and all that. You're going to have to use a separate /etc/runlevels, so why not just a whole separate /etc? -- Rich
