[systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
Daniel J Walsh
dwalsh at redhat.com
Tue Nov 20 06:50:39 PST 2012
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/20/2012 09:36 AM, Daniel P. Berrange wrote:
> On Tue, Nov 20, 2012 at 08:52:51AM -0500, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> On 11/19/2012 07:41 PM, Lennart Poettering wrote:
>>> On Fri, 16.11.12 15:06, Daniel J Walsh (dwalsh at redhat.com) wrote:
>>>
>>>> Isn't there a way to shut off systemV init scripts altogether, it
>>>> just so happens that we hit one on my machine. But in the field a
>>>> customer could have an init script and then setup containers and
>>>> systemd will attempt to start it. I want a way to say don't run SysV
>>>> Init scripts altogether.
>>>
>>> Hmm, there is currently no option for that.
>>>
>>> A semi-dirty trick might be to over-bind-mount /etc/rc.d with something
>>> empty?
>>>
>>> Lennart
>>>
>> What run levels would get executed? I would prefer to mount over the
>> empty run levels and allow an admin to be able to turn on a SysV init
>> script.
>
> I'm not convinced we need to support that explicitly. If an admin wants to
> support execution of some ad-hoc script they can easily make a system unit
> that uses the various ExecXXX directives to invoke their arbitrary shell
> scripts.
>
> Daniel
>
I was thinking more that if they wanted to execute
chkconfig within the container, the right thing would happen, which I get by
mounting empty dirs over /etc/rc.d/rc.[0-6]d
Similar to us allowing the admin to execute
systemctl enable foobar.service
within the container.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlCrmL8ACgkQrlYvE4MpobMCUQCgwsbUmhD+EWbjyKb82rXtlz4J
75AAnArmyLK7Juc8Z1HuZ49SImMz+WJa
=LyFa
-----END PGP SIGNATURE-----
More information about the systemd-devel
mailing list