Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
On 11/20/2012 12:41 AM, Lennart Poettering wrote: On Fri, 16.11.12 15:06, Daniel J Walsh (dwa...@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? Or he can just simply apply and test the diff for iscsi in [1] and walk around the office and ask all those RH maintainers that maintain iscsi what the freaking hold up is. JBG 1. https://bugzilla.redhat.com/show_bug.cgi?id=714688 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
On Tue, Nov 20, 2012 at 09:50:39AM -0500, Daniel J Walsh wrote: -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 (dwa...@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. IMHO supporting legacy commands like chkconfig is a non-goal for libvirt-sandbox. It is brand new functionality designed around closely integrating with systemd, and I don't think we should pollute it with code for legacy / dieing init systems. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
On Tue, 20.11.12 08:52, Daniel J Walsh (dwa...@redhat.com) wrote: 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. Well, if you boot into multi-user then all sysv scripts enabled in runlevel 2+3+4 are pulled in. If you boot into graphical, then all services from 5 will be pulled in too. Let me get this right: you want to disable all sysv scripts in the container, but then allow the admin to reenable a few of his own choice? If so, it might be possible to replace /etc/rc.d by something empty (but persistent, if changed), and then mount /etc/rc.d/init.d into it from the host system. That way the host's scripts are avaulable but the enable/disable status is separate from the host? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
On Fri, 16.11.12 15:06, Daniel J Walsh (dwa...@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 -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The only problem I see is that now sysV init scripts are firing off within the container. (iSCSI daemon). What can I do to stop this within the container? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCmTG4ACgkQrlYvE4MpobNS8ACgqJU1ADDnId43Roa2H1x0c81c p1gAnjn1glOuV4vfHsmWl7IyN6yNyCOB =dgtw -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
On Fri, 2012-11-16 at 09:23 -0500, Daniel J Walsh wrote: The only problem I see is that now sysV init scripts are firing off within the container. (iSCSI daemon). What can I do to stop this within the container? ConditionVirtualization=!lxc-libvirt ? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
On Fri, 16.11.12 09:23, Daniel J Walsh (dwa...@redhat.com) wrote: The only problem I see is that now sysV init scripts are firing off within the container. (iSCSI daemon). What can I do to stop this within the container? Services such as the iscsi daemon which one can sort in the driver category should never run in containers I believe. To automaticalky execution of these services in containers you can use ConditionVirtualization (as Colin already suggested). ConditionVirtualization=!container should do the job. (See systemd.unit(5) for details). That said, iscsid on Fedora currently is still a sysv script, which is a bit disappointing, and there's hence no place to add ConditionVirtualization=. My recommendation would be to get the iscsi folks to convert it into a systemd unit file, they should do that anyway soon. But as a temporary work-around you could just mask the unit in your container. Just add a symlink to /dev/null for /etc/systemd/system/iscsi.service and it will mask the sysv service and make it entirely unavailable. See this for details: http://0pointer.de/blog/projects/three-levels-of-off.html That said, manually masking things in the container in your script really is hacky, and I am pretty sure the better way is to get iscsid fixed to become a native systemd unit file that usese ConditionVirtualization to disable itself in a container. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I have switched libvirt-sandbox containers to use multi-user.target
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/16/2012 02:56 PM, Lennart Poettering wrote: On Fri, 16.11.12 09:23, Daniel J Walsh (dwa...@redhat.com) wrote: The only problem I see is that now sysV init scripts are firing off within the container. (iSCSI daemon). What can I do to stop this within the container? Services such as the iscsi daemon which one can sort in the driver category should never run in containers I believe. To automaticalky execution of these services in containers you can use ConditionVirtualization (as Colin already suggested). ConditionVirtualization=!container should do the job. (See systemd.unit(5) for details). That said, iscsid on Fedora currently is still a sysv script, which is a bit disappointing, and there's hence no place to add ConditionVirtualization=. My recommendation would be to get the iscsi folks to convert it into a systemd unit file, they should do that anyway soon. But as a temporary work-around you could just mask the unit in your container. Just add a symlink to /dev/null for /etc/systemd/system/iscsi.service and it will mask the sysv service and make it entirely unavailable. See this for details: http://0pointer.de/blog/projects/three-levels-of-off.html That said, manually masking things in the container in your script really is hacky, and I am pretty sure the better way is to get iscsid fixed to become a native systemd unit file that usese ConditionVirtualization to disable itself in a container. Lennart 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCmnNgACgkQrlYvE4MpobNKyQCcCIVQS/FuvOg3wWYi6AvgFMAw mI4AnA14UHY47GUd1uQROjDXmlv1TmDT =Ew3x -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
