[opensuse-factory] Moving forward with systemd
Hi: Above, there is a list of tasks, which are "up for the grabs" after we completely remove the old sysvinit system from the distribution. * We have to remove ConsoleKit, ASAP. its functionality has been replaced by systemd logind, apparently is enough to build polkit with systemd support to achieve this goal. * build the kernel with CONFIG_AUDIT_LOGINUID_IMMUTABLE=yes (From these point on sysvinit waves his old arse goodbye) * See if acpid can be replaced by logind features HandlePowerKey,HandleSleepKey,HandleLidSwitch etc.. * we must ensure that packages have proper tmpfiles.d(5) configuration files and remove/obsolete all the CLEAR_TMP_DIRS_AT_* sysconfig kludges in /etc/sysconfig/cron and boot.cleanup script. Related to this : daemons must run with PrivateTemp set to true and see a way to provide exclusive temporary directories to users in a sensible manner such as pam_mktemp (?) or similar. * Yast or $whatever is doing the job, must learn how to setup remote filesystems mount points according to what systemd.automount(5) and systemd.mount(5) describe. * migrate away from pm-utils scripts to /usr/lib/systemd/system-sleep/ ..systemctl suspend.. systemctl hibernate..etc.. Im very likely missing something else, but this is enough to start :-) Cheers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10.09.2012 03:39, Cristian Rodríguez wrote:
Hi:
Above, there is a list of tasks, which are "up for the grabs" after we completely remove the old sysvinit system from the distribution.
Hi, This kind of asks for a meta bug to track the TODOs :)
* We have to remove ConsoleKit, ASAP. its functionality has been replaced by systemd logind, apparently is enough to build polkit with systemd support to achieve this goal.
* build the kernel with CONFIG_AUDIT_LOGINUID_IMMUTABLE=yes
(From these point on sysvinit waves his old arse goodbye)
Can you please elaborate on this one?
* See if acpid can be replaced by logind features HandlePowerKey,HandleSleepKey,HandleLidSwitch etc..
* we must ensure that packages have proper tmpfiles.d(5) configuration files and remove/obsolete all the CLEAR_TMP_DIRS_AT_* sysconfig kludges in /etc/sysconfig/cron and boot.cleanup script.
Related to this : daemons must run with PrivateTemp set to true and see a way to provide exclusive temporary directories to users in a sensible manner such as pam_mktemp (?) or similar.
* Yast or $whatever is doing the job, must learn how to setup remote filesystems mount points according to what systemd.automount(5) and systemd.mount(5) describe.
* migrate away from pm-utils scripts to /usr/lib/systemd/system-sleep/ ..systemctl suspend.. systemctl hibernate..etc..
Im very likely missing something else, but this is enough to start :-)
Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Sep 10, 2012 at 11:26:30AM +0200, Stephan Kulow wrote:
On 10.09.2012 03:39, Cristian Rodríguez wrote:
Hi:
Above, there is a list of tasks, which are "up for the grabs" after we completely remove the old sysvinit system from the distribution.
Hi,
This kind of asks for a meta bug to track the TODOs :)
* We have to remove ConsoleKit, ASAP. its functionality has been replaced by systemd logind, apparently is enough to build polkit with systemd support to achieve this goal.
* build the kernel with CONFIG_AUDIT_LOGINUID_IMMUTABLE=yes
(From these point on sysvinit waves his old arse goodbye)
Can you please elaborate on this one?
Once the loginuid is set, not even root can change it anymore. relevant kernel code: #ifdef CONFIG_AUDIT_LOGINUID_IMMUTABLE if (task->loginuid != -1) return -EPERM; #else /* CONFIG_AUDIT_LOGINUID_IMMUTABLE */ if (!capable(CAP_AUDIT_CONTROL)) return -EPERM; #endif /* CONFIG_AUDIT_LOGINUID_IMMUTABLE */ I am not sure what the relation to systemd is though. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10 September 2012 10:38, Marcus Meissner <meissner@suse.de> wrote:
I am not sure what the relation to systemd is though.
Google gives this -> http://www.redhat.com/archives/linux-audit/2011-November/msg00040.html So it's not something that is going to make systemd work better. It's something to make the system safer... but that can only be enabled if systemd is used. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Marcus Meissner wrote:
On Mon, Sep 10, 2012 at 11:26:30AM +0200, Stephan Kulow wrote:
On 10.09.2012 03:39, Cristian Rodríguez wrote:
Above, there is a list of tasks, which are "up for the grabs" after we completely remove the old sysvinit system from the distribution.
This kind of asks for a meta bug to track the TODOs :)
* We have to remove ConsoleKit, ASAP. its functionality has been replaced by systemd logind, apparently is enough to build polkit with systemd support to achieve this goal.
* build the kernel with CONFIG_AUDIT_LOGINUID_IMMUTABLE=yes
(From these point on sysvinit waves his old arse goodbye)
Can you please elaborate on this one?
Once the loginuid is set, not even root can change it anymore.
relevant kernel code: #ifdef CONFIG_AUDIT_LOGINUID_IMMUTABLE if (task->loginuid != -1) return -EPERM; #else /* CONFIG_AUDIT_LOGINUID_IMMUTABLE */ if (!capable(CAP_AUDIT_CONTROL)) return -EPERM; #endif /* CONFIG_AUDIT_LOGINUID_IMMUTABLE */
I am not sure what the relation to systemd is though.
With systemd if you enter e.g. "sudo rcsshd start" a wrappper asks systemd to call the sshd init script as child of systemd. Therefore the newly forked daemon has no loginuid and can set it if needed. If you do that in sysv "sudo rcsshd start" would run in your session directly, inheriting your loginuid. Therefore sshd could not set the loginuid properly anymore for users trying to log in. To fix that sysv would need to run init scripts through a wrapper too. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 10/09/12 09:12, Ludwig Nussel escribió: vant kernel code:
#ifdef CONFIG_AUDIT_LOGINUID_IMMUTABLE if (task->loginuid != -1) return -EPERM; #else /* CONFIG_AUDIT_LOGINUID_IMMUTABLE */ if (!capable(CAP_AUDIT_CONTROL)) return -EPERM; #endif /* CONFIG_AUDIT_LOGINUID_IMMUTABLE */
I am not sure what the relation to systemd is though.
With systemd if you enter e.g. "sudo rcsshd start" a wrappper asks systemd to call the sshd init script as child of systemd. Therefore the newly forked daemon has no loginuid and can set it if needed. If you do that in sysv "sudo rcsshd start" would run in your session directly, inheriting your loginuid. Therefore sshd could not set the loginuid properly anymore for users trying to log in. To fix that sysv would need to run init scripts through a wrapper too.
cu Ludwig
DO you think it is reasonable to ask kernel developers to turn this into a sysctl so we simple turn the flag on at some point at startup ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Sep 10, 2012 at 12:35:31PM -0300, Cristian Rodríguez wrote:
El 10/09/12 09:12, Ludwig Nussel escribió: vant kernel code:
#ifdef CONFIG_AUDIT_LOGINUID_IMMUTABLE if (task->loginuid != -1) return -EPERM; #else /* CONFIG_AUDIT_LOGINUID_IMMUTABLE */ if (!capable(CAP_AUDIT_CONTROL)) return -EPERM; #endif /* CONFIG_AUDIT_LOGINUID_IMMUTABLE */
I am not sure what the relation to systemd is though.
With systemd if you enter e.g. "sudo rcsshd start" a wrappper asks systemd to call the sshd init script as child of systemd. Therefore the newly forked daemon has no loginuid and can set it if needed. If you do that in sysv "sudo rcsshd start" would run in your session directly, inheriting your loginuid. Therefore sshd could not set the loginuid properly anymore for users trying to log in. To fix that sysv would need to run init scripts through a wrapper too.
cu Ludwig
DO you think it is reasonable to ask kernel developers to turn this into a sysctl so we simple turn the flag on at some point at startup ?
The idea is to not be able to turn it off as root... :) Having a sysctl would defy the purpose. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.09.2012 21:32, schrieb Marcus Meissner:
On Mon, Sep 10, 2012 at 12:35:31PM -0300, Cristian Rodríguez wrote:
DO you think it is reasonable to ask kernel developers to turn this into a sysctl so we simple turn the flag on at some point at startup ?
I think that's the only way to go forward if we want to enable that. Maybe a boot option could also do that enables it (default disabled)
The idea is to not be able to turn it off as root... :) Having a sysctl would defy the purpose.
Well, it could be one-way only: turn on => allowed, turn off => -EINVAL -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Sep 09, 2012 at 10:39:50PM -0300, Cristian Rodríguez wrote:
Hi:
Above, there is a list of tasks, which are "up for the grabs" after we completely remove the old sysvinit system from the distribution.
I would say we need to track this in bugzilla and add it to meta bug bnc#696902. And there is the very first task * update systemd to the latest upstream version as with venerable 44 we have in Factory, it does not makes a lot of sense to adapt system as we can be beaten by things already fixed in a meanwhile in upstream. I tryed to take a loot, but with 128 patches we have in systemd+udev that's not an easy task. So the merge should be done by the maintainers. Regards Michal Vyskocil
El 10/09/12 08:37, Michal Vyskocil escribió:
On Sun, Sep 09, 2012 at 10:39:50PM -0300, Cristian Rodríguez wrote:
Hi:
Above, there is a list of tasks, which are "up for the grabs" after we completely remove the old sysvinit system from the distribution.
I would say we need to track this in bugzilla and add it to meta bug bnc#696902. And there is the very first task
* update systemd to the latest upstream version
Yes, upgrading systemd is a pre-requisite for most of the stuff I listed here.
I tryed to take a loot, but with 128 patches we have in systemd+udev that's not an easy task. So the merge should be done by the maintainers.
Apparently fcrozat is on vacation, let's bug him on return. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 10 septembre 2012 à 13:37 +0200, Michal Vyskocil a écrit :
On Sun, Sep 09, 2012 at 10:39:50PM -0300, Cristian Rodríguez wrote:
Hi:
Above, there is a list of tasks, which are "up for the grabs" after we completely remove the old sysvinit system from the distribution.
I would say we need to track this in bugzilla and add it to meta bug bnc#696902. And there is the very first task
* update systemd to the latest upstream version
as with venerable 44 we have in Factory, it does not makes a lot of sense to adapt system as we can be beaten by things already fixed in a meanwhile in upstream.
I tryed to take a loot, but with 128 patches we have in systemd+udev that's not an easy task. So the merge should be done by the maintainers.
And I plan to start working on this as soon as I finish reading the flame^Wthread regarding systemd on -factory mailing list ;) -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Cristian Rodríguez <crrodriguez@opensuse.org> [2012-09-10 03:41]:
* We have to remove ConsoleKit, ASAP. its functionality has been replaced by systemd logind, apparently is enough to build polkit with systemd support to achieve this goal.
No we dont't, particularly not as long as packages depend on it. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 10/09/12 13:21, Guido Berhoerster escribió:
* Cristian Rodríguez <crrodriguez@opensuse.org> [2012-09-10 03:41]:
* We have to remove ConsoleKit, ASAP. its functionality has been replaced by systemd logind, apparently is enough to build polkit with systemd support to achieve this goal.
No we dont't, particularly not as long as packages depend on it.
Well, removing this component implies that we have to fix dependant packages. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le dimanche 09 septembre 2012 à 22:39 -0300, Cristian Rodríguez a écrit :
Hi:
Above, there is a list of tasks, which are "up for the grabs" after we completely remove the old sysvinit system from the distribution.
* We have to remove ConsoleKit, ASAP. its functionality has been replaced by systemd logind, apparently is enough to build polkit with systemd support to achieve this goal.
build kernel with autofs4 built-in (systemd will modprobe it anyway, but we could save some boot time by not having to do so).
(From these point on sysvinit waves his old arse goodbye)
* See if acpid can be replaced by logind features HandlePowerKey,HandleSleepKey,HandleLidSwitch etc..
* we must ensure that packages have proper tmpfiles.d(5) configuration files and remove/obsolete all the CLEAR_TMP_DIRS_AT_* sysconfig kludges in /etc/sysconfig/cron and boot.cleanup script.
Related to this : daemons must run with PrivateTemp set to true and see a way to provide exclusive temporary directories to users in a sensible manner such as pam_mktemp (?) or similar.
Must is a bit hard for PrivateTmp, I'd suggest "should".
* Yast or $whatever is doing the job, must learn how to setup remote filesystems mount points according to what systemd.automount(5) and systemd.mount(5) describe.
Hmm, the "canonical" way for mount points should still be /etc/fstab. I don't see the need to change YaST in that regard. Could you be a little more specific. We need YaST "runlevel" editor to be ported to systemd. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 20/09/12 10:02, Frederic Crozat escribió:
build kernel with autofs4 built-in (systemd will modprobe it anyway, but we could save some boot time by not having to do so).
Ok, we need to bug kernel developers with this.. ;)
Related to this : daemons must run with PrivateTemp set to true and see a way to provide exclusive temporary directories to users in a sensible manner such as pam_mktemp (?) or similar.
Must is a bit hard for PrivateTmp, I'd suggest "should".
Yeah, we probably need an script that checks the binary AND the linked libraries for usage of mkstemp(3) mkdtemp(3), mktemp(3), tempnam(3), tmpfile(3), tmpnam(3) functions and tell us if we really need that. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 20 of September 2012 15:02EN, Frederic Crozat wrote:
build kernel with autofs4 built-in (systemd will modprobe it anyway, but we could save some boot time by not having to do so).
What I always liked on (Open)SuSE kernel is the modularity. If you don't use a device or a filesystem, you don't waste memory and time with its driver as it is built as a module. Building something like autofs hard into the image would go exactly against this philosophy. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Sep 21, 2012 at 5:34 AM, Michal Kubeček <mkubecek@suse.cz> wrote:
On Thursday 20 of September 2012 15:02EN, Frederic Crozat wrote:
build kernel with autofs4 built-in (systemd will modprobe it anyway, but we could save some boot time by not having to do so).
What I always liked on (Open)SuSE kernel is the modularity. If you don't use a device or a filesystem, you don't waste memory and time with its driver as it is built as a module. Building something like autofs hard into the image would go exactly against this philosophy.
Not really, if systemd will modprobe it at early boot, not having statically linked is just a waste of time. I'm wondering, though, how big that time saving can be, and how big should it be to justify such a move. Not even a second would compel me to change the kernel (and a second for a modprobe would be excessive already). IMO, a waste of kernel team time. For now. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Sep 21, 2012 at 12:01:17PM -0300, Claudio Freire wrote:
On Fri, Sep 21, 2012 at 5:34 AM, Michal Kubeček <mkubecek@suse.cz> wrote:
On Thursday 20 of September 2012 15:02EN, Frederic Crozat wrote:
build kernel with autofs4 built-in (systemd will modprobe it anyway, but we could save some boot time by not having to do so).
What I always liked on (Open)SuSE kernel is the modularity. If you don't use a device or a filesystem, you don't waste memory and time with its driver as it is built as a module. Building something like autofs hard into the image would go exactly against this philosophy.
Not really, if systemd will modprobe it at early boot, not having statically linked is just a waste of time.
Do you have numbers? Have you compared them forcing the load at boot time via /etc/sysconfig/kernel MODULES_LOADED_ON_BOOT ?
I'm wondering, though, how big that time saving can be, and how big should it be to justify such a move. Not even a second would compel me to change the kernel (and a second for a modprobe would be excessive already).
Measure it. Compare the dynamic approch, vs MODULES_LOADED_ON_BOOT, vs static build. Then we know for sure. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Fri, Sep 21, 2012 at 12:21 PM, Lars Müller <lmuelle@suse.com> wrote:
I'm wondering, though, how big that time saving can be, and how big should it be to justify such a move. Not even a second would compel me to change the kernel (and a second for a modprobe would be excessive already).
Measure it. Compare the dynamic approch, vs MODULES_LOADED_ON_BOOT, vs static build. Then we know for sure.
static build takes negligible time, as most of the linking is done at build time. The only impact at runtime is the bigger linux image, but that module is mere 44k, so it ought to be rather quick. So, lets say static build = 1ms ? I just timed modprobe autofs4 (by doing "time modprobe autofs4"), and with a really cold disk cache it took 0.3s. That even takes into acount whatever dependency autofs4 has and wasn't loaded. So... best case net time saving: 0.3s -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le vendredi 21 septembre 2012 à 17:21 +0200, Lars Müller a écrit :
On Fri, Sep 21, 2012 at 12:01:17PM -0300, Claudio Freire wrote:
On Fri, Sep 21, 2012 at 5:34 AM, Michal Kubeček <mkubecek@suse.cz> wrote:
On Thursday 20 of September 2012 15:02EN, Frederic Crozat wrote:
build kernel with autofs4 built-in (systemd will modprobe it anyway, but we could save some boot time by not having to do so).
What I always liked on (Open)SuSE kernel is the modularity. If you don't use a device or a filesystem, you don't waste memory and time with its driver as it is built as a module. Building something like autofs hard into the image would go exactly against this philosophy.
Not really, if systemd will modprobe it at early boot, not having statically linked is just a waste of time.
Do you have numbers?
Have you compared them forcing the load at boot time via /etc/sysconfig/kernel MODULES_LOADED_ON_BOOT ?
I'm wondering, though, how big that time saving can be, and how big should it be to justify such a move. Not even a second would compel me to change the kernel (and a second for a modprobe would be excessive already).
Measure it. Compare the dynamic approch, vs MODULES_LOADED_ON_BOOT, vs static build. Then we know for sure.
well, MODULES_LOADED_ON_BOOT also implies starting /lib/systemd/systemd-modules-load which will then use kmod to do the modprobe. So, you should get similar numbers in both case, since kmod is involded.. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2012-09-21 17:01, Claudio Freire wrote:
On Fri, Sep 21, 2012 at 5:34 AM, Michal Kubeček <mkubecek@suse.cz> wrote:
On Thursday 20 of September 2012 15:02EN, Frederic Crozat wrote:
build kernel with autofs4 built-in (systemd will modprobe it anyway, but we could save some boot time by not having to do so).
What I always liked on (Open)SuSE kernel is the modularity. If you don't use a device or a filesystem, you don't waste memory and time with its driver as it is built as a module. Building something like autofs hard into the image would go exactly against this philosophy.
Not really, if systemd will modprobe it at early boot, not having statically linked is just a waste of time.
Speaking of waste of time: Can systemd be taught not to spend time on binfmt_misc? Because that's the _only_ autofs user on my 12.2. 15:05 nakamura:~ # lsmod | grep autof autofs4 32754 2 15:05 nakamura:~ # grep autof /proc/self/mounts systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 With that eventually gone, I certainly don't want autofs builtin. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le dimanche 23 septembre 2012 à 15:08 +0200, Jan Engelhardt a écrit :
On Friday 2012-09-21 17:01, Claudio Freire wrote:
On Fri, Sep 21, 2012 at 5:34 AM, Michal Kubeček <mkubecek@suse.cz> wrote:
On Thursday 20 of September 2012 15:02EN, Frederic Crozat wrote:
build kernel with autofs4 built-in (systemd will modprobe it anyway, but we could save some boot time by not having to do so).
What I always liked on (Open)SuSE kernel is the modularity. If you don't use a device or a filesystem, you don't waste memory and time with its driver as it is built as a module. Building something like autofs hard into the image would go exactly against this philosophy.
Not really, if systemd will modprobe it at early boot, not having statically linked is just a waste of time.
By default, systemd-binfmt.service isn't started unless you have a config file in either /usr/lib/binfmt.d or /usr/local/lib/binfmt.d or /etc/binfmt.d or /run/binfmt.d. My guess is you have wine installed. If you want to disable this feature, systemctl mask systemd-binfmt.service -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
2012/9/24 Frederic Crozat <fcrozat@suse.com>:
By default, systemd-binfmt.service isn't started unless you have a config file in either /usr/lib/binfmt.d or /usr/local/lib/binfmt.d or /etc/binfmt.d or /run/binfmt.d. My guess is you have wine installed.
Just as information, I just checked since I have wine installed and autofs4 is loaded. The interesting fact is that /usr/lib/binfmt.d and /etc/binfmt.d are empty while /usr/local/lib/binfmt.d and /run/binfmt.d do not exist. If I run "systemctl status systemd-binfmt.service", I obtain systemd-binfmt.service - Set Up Additional Binary Formats Loaded: loaded (/lib/systemd/system/systemd-binfmt.service; static) Active: inactive (dead) start condition failed at Mon, 24 Sep 2012 07:10:59 +0200; 3h 42min ago CGroup: name=systemd:/system/systemd-binfmt.service and /lib/systemd/system/systemd-binfmt.service comes from systemd-44-10.1.1.x86_64, according to "rpm -qf" output. Just a side question: the service is loaded but dead since the start condition failed. Where can I find a more complete info about the failure? If I grep /var/log/messages or systemd-journal for binfmt, I do not find any occurrence of binfmt... Best, Andrea -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 24 septembre 2012 à 11:07 +0200, Andrea Turrini a écrit :
2012/9/24 Frederic Crozat <fcrozat@suse.com>:
By default, systemd-binfmt.service isn't started unless you have a config file in either /usr/lib/binfmt.d or /usr/local/lib/binfmt.d or /etc/binfmt.d or /run/binfmt.d. My guess is you have wine installed.
Just as information, I just checked since I have wine installed and autofs4 is loaded. The interesting fact is that /usr/lib/binfmt.d and /etc/binfmt.d are empty while /usr/local/lib/binfmt.d and /run/binfmt.d do not exist. If I run "systemctl status systemd-binfmt.service", I obtain
systemd-binfmt.service - Set Up Additional Binary Formats Loaded: loaded (/lib/systemd/system/systemd-binfmt.service; static) Active: inactive (dead) start condition failed at Mon, 24 Sep 2012 07:10:59 +0200; 3h 42min ago CGroup: name=systemd:/system/systemd-binfmt.service
and /lib/systemd/system/systemd-binfmt.service comes from systemd-44-10.1.1.x86_64, according to "rpm -qf" output.
Just a side question: the service is loaded but dead since the start condition failed. Where can I find a more complete info about the failure? If I grep /var/log/messages or systemd-journal for binfmt, I do not find any occurrence of binfmt...
How about looking at the service file itself ? :) I don't know if the exact failing conditions will be logged in future version of systemd. Regarding binfmt, I've checked deeper and there is also an automount setup as proc-sys-fs-binfmt_misc.automount -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 21 of September 2012 12:01EN, Claudio Freire wrote:
Not really, if systemd will modprobe it at early boot, not having statically linked is just a waste of time.
If it does - even for users who don't need it (which is actually most of the users) - it's wrong. Forcing autofs into kernel image is not a solution, it's just an attempt to mask consequences of this mistake. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (14)
-
Andrea Turrini -
Claudio Freire -
Cristian Morales Vega -
Cristian Rodríguez -
Frederic Crozat -
Guido Berhoerster -
Jan Engelhardt -
Lars Müller -
Ludwig Nussel -
Marcus Meissner -
Michal Kubeček -
Michal Vyskocil -
Stefan Seyfried -
Stephan Kulow