[opensuse-factory] systemd (feature #310327)
Hi, There have been various talks about systemd at the openSUSE conference and we would like to go forward. So next step would be a wider testing: so please install systemd and boot with init=/bin/systemd and report issues (here). AJ documented some more details on: http://lizards.opensuse.org/2010/10/08/systemd-and-osc2010/ If you want coloured pictures, compare http://ktown.kde.org/~coolo/bootchart-sysvinit.png and http://ktown.kde.org/~coolo/bootchart-systemd.png Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday 27 October 2010 13:46:31 Stephan Kulow wrote:
Hi,
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
So next step would be a wider testing: so please install systemd and boot with init=/bin/systemd and report issues (here).
Hi Stephan, I have noticed that there are two systemd packages. One is called just systemd and the other one is systemd-sysvinit. Should they both be installed ? If I try to install the systemd-sysvinit, then it tries to de-install sysvinit, so I guess this is not the correct one. Thanks Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday 27 October 2010 22:17:03 Raymond Wooninck wrote:
On Wednesday 27 October 2010 13:46:31 Stephan Kulow wrote:
Hi,
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
So next step would be a wider testing: so please install systemd and boot with init=/bin/systemd and report issues (here).
Hi Stephan,
I have noticed that there are two systemd packages. One is called just systemd and the other one is systemd-sysvinit. Should they both be installed ? If I try to install the systemd-sysvinit, then it tries to de-install sysvinit, so I guess this is not the correct one.
Just install systemd so that you can switch. For details see: http://en.opensuse.org/SDB:Systemd Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Stephan Kulow <coolo <at> novell.com> writes:
Hi,
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
So next step would be a wider testing: so please install systemd and boot with init=/bin/systemd and report issues (here).
AJ documented some more details on: http://lizards.opensuse.org/2010/10/08/systemd-and-osc2010/
If you want coloured pictures, compare http://ktown.kde.org/~coolo/bootchart-sysvinit.png and http://ktown.kde.org/~coolo/bootchart-systemd.png
Greetings, Stephan
Hi First a disclaimer. I'm new to testing bits of linux/openSUSE and not too confident that all of the following is correct so I hope you can bear with me. :) I was testing systemd successfully using the default kernel from the standard repos (non-factory) until a recent change in systemd caused a problem. I've been getting an error at boot time saying that the "/sys/fs/cgroup" can't be mounted. At that point I switched to the 2.6.36 rc from Kernel Head and that worked OK. The problem with that kernel is there's no kernel sources available (unless I'm missing something obvious) for that release, as I use VMware products on my workstation most of the time I can't use that kernel or systemd. I'd like to get it working again on the current kernel, if possible. In doing some research I found the following on lkml.org: http://lkml.org/lkml/2010/7/22/384 and current versions of systemd now mount cgroupfs on /sys/fs/cgroup - I suppose my questions are: can that patch be backported to the current 2.6.34 kernel; if it can be backported how do I get it actioned? Regards Bill -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 28 October 2010 14:23:08 Bill Pye wrote:
Stephan Kulow <coolo <at> novell.com> writes:
Hi,
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
So next step would be a wider testing: so please install systemd and boot with init=/bin/systemd and report issues (here).
AJ documented some more details on: http://lizards.opensuse.org/2010/10/08/systemd-and-osc2010/
If you want coloured pictures, compare http://ktown.kde.org/~coolo/bootchart-sysvinit.png and http://ktown.kde.org/~coolo/bootchart-systemd.png
Greetings, Stephan
Hi
First a disclaimer. I'm new to testing bits of linux/openSUSE and not too confident that all of the following is correct so I hope you can bear with me. :)
I was testing systemd successfully using the default kernel from the standard repos (non-factory) until a recent change in systemd caused a problem. I've been getting an error at boot time saying that the "/sys/fs/cgroup" can't be mounted. At that point I switched to the 2.6.36
You can ignore that message, it should still work.
rc from Kernel Head and that worked OK. The problem with that kernel is there's no kernel sources available (unless I'm missing something obvious) for that release, as I use VMware products on my workstation most of the time I can't use that kernel or systemd. I'd like to get it working again on the current kernel, if possible.
You can use the openSUSE head kernel from the Kernel:HEAD project or from openSUSE:Factory.
In doing some research I found the following on lkml.org: http://lkml.org/lkml/2010/7/22/384 and current versions of systemd now mount cgroupfs on /sys/fs/cgroup - I suppose my questions are: can that patch be backported to the current 2.6.34 kernel; if it can be backported how do I get it actioned?
We disabled it and forgot to enable it again, really use the 2.6.36 kernel. Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 2010-10-27 at 13:46 +0200, Stephan Kulow wrote:
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
This is a bootchart of systemd-git of today on openSUSE Factory of today: http://people.freedesktop.org/~kay/bootchart.png The box is a 1.5 Ghz laptop with a medium-speed SSD. Many (default) services are not installed on this box. A default installation is around ~10 sec instead of the ~6.5 sec here. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 29/10/10 11:20, Kay Sievers escribió:
On Wed, 2010-10-27 at 13:46 +0200, Stephan Kulow wrote:
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
This is a bootchart of systemd-git of today on openSUSE Factory of today: http://people.freedesktop.org/~kay/bootchart.png
The box is a 1.5 Ghz laptop with a medium-speed SSD.
Many (default) services are not installed on this box. A default installation is around ~10 sec instead of the ~6.5 sec here.
While I agree it is very cool to see the system booting faster, is anyone looking into the speed of IMHO waay more important suspend/resume feature ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Cristian Rodríguez wrote:
El 29/10/10 11:20, Kay Sievers escribió:
On Wed, 2010-10-27 at 13:46 +0200, Stephan Kulow wrote:
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
This is a bootchart of systemd-git of today on openSUSE Factory of today: http://people.freedesktop.org/~kay/bootchart.png
The box is a 1.5 Ghz laptop with a medium-speed SSD.
Many (default) services are not installed on this box. A default installation is around ~10 sec instead of the ~6.5 sec here.
While I agree it is very cool to see the system booting faster, is
I agree it's a cool feature, but I question how useful/important it really is. For a desktop user, the 8-10 seconds saved isn't even time for a cup of coffee, for a server boot-up time is largely irrelevant. -- Per Jessen, Zürich (13.4°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi; On Fri, Oct 29, 2010 at 6:09 PM, Per Jessen <per@opensuse.org> wrote:
Cristian Rodríguez wrote:
El 29/10/10 11:20, Kay Sievers escribió:
On Wed, 2010-10-27 at 13:46 +0200, Stephan Kulow wrote:
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
This is a bootchart of systemd-git of today on openSUSE Factory of today: http://people.freedesktop.org/~kay/bootchart.png
The box is a 1.5 Ghz laptop with a medium-speed SSD.
Many (default) services are not installed on this box. A default installation is around ~10 sec instead of the ~6.5 sec here.
While I agree it is very cool to see the system booting faster, is
I agree it's a cool feature, but I question how useful/important it really is. For a desktop user, the 8-10 seconds saved isn't even time for a cup of coffee, for a server boot-up time is largely irrelevant.
IMHO 8-10 seconds is long enough to make a difference for desktop. Regards, ismail -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 10/29/2010 11:10 AM, İsmail Dönmez wrote:
Hi;
On Fri, Oct 29, 2010 at 6:09 PM, Per Jessen <per@opensuse.org> wrote:
Cristian Rodríguez wrote:
El 29/10/10 11:20, Kay Sievers escribió:
On Wed, 2010-10-27 at 13:46 +0200, Stephan Kulow wrote:
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
This is a bootchart of systemd-git of today on openSUSE Factory of today: http://people.freedesktop.org/~kay/bootchart.png
The box is a 1.5 Ghz laptop with a medium-speed SSD.
Many (default) services are not installed on this box. A default installation is around ~10 sec instead of the ~6.5 sec here.
While I agree it is very cool to see the system booting faster, is
I agree it's a cool feature, but I question how useful/important it really is. For a desktop user, the 8-10 seconds saved isn't even time for a cup of coffee, for a server boot-up time is largely irrelevant.
IMHO 8-10 seconds is long enough to make a difference for desktop.
Regards, ismail
If its not stable, the boot up time is irrelevant. I could care less how fast my desktop boots, as long as it functions properly I'm good. Same with my servers... I'd rather have stability over a faster boot up time. -Matt -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi; On Fri, Oct 29, 2010 at 6:19 PM, Matt Hayes <dominian@slackadelic.com> wrote:
IMHO 8-10 seconds is long enough to make a difference for desktop.
If its not stable, the boot up time is irrelevant.
I could care less how fast my desktop boots, as long as it functions properly I'm good. Same with my servers... I'd rather have stability over a faster boot up time.
That is true. I didn't mean to say speed should be preferred over stability. Changing the init system comes with lots of headaches by itself even excluding the new bugs it introduces. Optimizing boot time is not (only) about changing init systems anyway, working on intelligent file caching with ureadahead etc. greatly helps too. Regards, ismail -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 10/29/2010 11:23 AM, İsmail Dönmez wrote:
Hi;
On Fri, Oct 29, 2010 at 6:19 PM, Matt Hayes <dominian@slackadelic.com> wrote:
IMHO 8-10 seconds is long enough to make a difference for desktop.
If its not stable, the boot up time is irrelevant.
I could care less how fast my desktop boots, as long as it functions properly I'm good. Same with my servers... I'd rather have stability over a faster boot up time.
That is true. I didn't mean to say speed should be preferred over stability. Changing the init system comes with lots of headaches by itself even excluding the new bugs it introduces.
Optimizing boot time is not (only) about changing init systems anyway, working on intelligent file caching with ureadahead etc. greatly helps too.
Regards, ismail
Oh I was just giving me input on it :) But yes, I do see your point! -Matt -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 29 Oct 2010 18:23:29 +0300 İsmail Dönmez <ismail@namtrac.org> wrote:
That is true. I didn't mean to say speed should be preferred over stability. Changing the init system comes with lots of headaches by itself even excluding the new bugs it introduces.
systemd is IMHO not about "boot faster" - that's only a side effect of it. The most important feature of systemd IMHO is the native support of cgroups. Actually even the server people I work with are looking forward to using systemd because of that. (They'll probably run it in SysV compat mode, though ;) -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Stefan Seyfried wrote:
On Fri, 29 Oct 2010 18:23:29 +0300 İsmail Dönmez <ismail@namtrac.org> wrote:
That is true. I didn't mean to say speed should be preferred over stability. Changing the init system comes with lots of headaches by itself even excluding the new bugs it introduces.
systemd is IMHO not about "boot faster" - that's only a side effect of it.
The most important feature of systemd IMHO is the native support of cgroups. Actually even the server people I work with are looking forward to using systemd because of that. (They'll probably run it in SysV compat mode, though ;)
Are there any actual dependencies between systemd and the use of cgroups? Sounds a bit far fetched. -- Per Jessen, Zürich (11.6°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 31/10/10 08:31, Per Jessen escribió:
Are there any actual dependencies between systemd and the use of cgroups? Sounds a bit far fetched.
Yes, you need a kernel with cgroups enabled. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Cristian Rodríguez wrote:
El 31/10/10 08:31, Per Jessen escribió:
Are there any actual dependencies between systemd and the use of cgroups? Sounds a bit far fetched.
Yes, you need a kernel with cgroups enabled.
But that's not a dependency between systemd and the use of cgroups. As in - I can use cgroups without using systemd. -- Per Jessen, Zürich (11.5°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, 31 Oct 2010 16:18:05 +0100 Per Jessen <per@opensuse.org> wrote:
Cristian Rodríguez wrote:
El 31/10/10 08:31, Per Jessen escribió:
Are there any actual dependencies between systemd and the use of cgroups? Sounds a bit far fetched.
Yes, you need a kernel with cgroups enabled.
But that's not a dependency between systemd and the use of cgroups. As in - I can use cgroups without using systemd.
Of course you can. And should. But it is all much more natural if all services are put into their respective group from the start (that's what systemd does) than if you have to "reclassify" after they are started (that's what you can do now). -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 2010-10-29 at 11:19 -0400, Matt Hayes wrote:
On 10/29/2010 11:10 AM, İsmail Dönmez wrote:
On Fri, Oct 29, 2010 at 6:09 PM, Per Jessen <per@opensuse.org> wrote:
Cristian Rodríguez wrote:
El 29/10/10 11:20, Kay Sievers escribió:
On Wed, 2010-10-27 at 13:46 +0200, Stephan Kulow wrote:
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
This is a bootchart of systemd-git of today on openSUSE Factory of today: http://people.freedesktop.org/~kay/bootchart.png
The box is a 1.5 Ghz laptop with a medium-speed SSD.
Many (default) services are not installed on this box. A default installation is around ~10 sec instead of the ~6.5 sec here.
If its not stable, the boot up time is irrelevant.
I could care less how fast my desktop boots, as long as it functions properly I'm good. Same with my servers... I'd rather have stability over a faster boot up time.
I'll post the stabilitychart.png next. Stay tuned. :) Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le vendredi 29 octobre 2010, à 11:19 -0400, Matt Hayes a écrit :
If its not stable, the boot up time is irrelevant.
Which is why as many people as possible should play with it now, so that we can see how stable it is, and fix potential issues. Then we'll be able to take an informed decision. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Per Jessen wrote:
Cristian Rodríguez wrote:
El 29/10/10 11:20, Kay Sievers escribió:
On Wed, 2010-10-27 at 13:46 +0200, Stephan Kulow wrote:
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
This is a bootchart of systemd-git of today on openSUSE Factory of today: http://people.freedesktop.org/~kay/bootchart.png
The box is a 1.5 Ghz laptop with a medium-speed SSD.
Many (default) services are not installed on this box. A default installation is around ~10 sec instead of the ~6.5 sec here.
While I agree it is very cool to see the system booting faster, is
I agree it's a cool feature, but I question how useful/important it really is.
Nonetheless, I've just upgraded an 11.3 server to 2.6.36 and systemd - wow, that was FAST! So fast I can't help thinking not everything got started. -- Per Jessen, Zürich (9.3°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Per Jessen wrote:
Per Jessen wrote:
Nonetheless, I've just upgraded an 11.3 server to 2.6.36 and systemd - wow, that was FAST! So fast I can't help thinking not everything got started.
Yep, it didn't - a filesystem failed to mount, looks like a hardware issue. Normally this would have caused the system to stop booting and wait for root to log in ? -- Per Jessen, Zürich (9.1°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 29 October 2010 19:15:38 Per Jessen wrote:
Per Jessen wrote:
Per Jessen wrote:
Nonetheless, I've just upgraded an 11.3 server to 2.6.36 and systemd - wow, that was FAST! So fast I can't help thinking not everything got started.
Yep, it didn't - a filesystem failed to mount, looks like a hardware issue. Normally this would have caused the system to stop booting and wait for root to log in ?
Could you give some more details so that we can discuss what is the proper way to handle this? Which filesystem was it? Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Andreas Jaeger wrote:
On Friday 29 October 2010 19:15:38 Per Jessen wrote:
Per Jessen wrote:
Per Jessen wrote:
Nonetheless, I've just upgraded an 11.3 server to 2.6.36 and systemd - wow, that was FAST! So fast I can't help thinking not everything got started.
Yep, it didn't - a filesystem failed to mount, looks like a hardware issue. Normally this would have caused the system to stop booting and wait for root to log in ?
Could you give some more details so that we can discuss what is the proper way to handle this? Which filesystem was it?
Yes, sorry, I forgot. The system has an LVM setup, 2 logical volumes over a group with three physical volumes (each is RAID5). Filesystem is JFS. One of the RAID5s failed, which meant one of the logical volumes could not be mounted at startup. The normal way to react is for the startup sequence to enter some path which ends by asking the user for the root password. Single-user mode maybe? With systemd and this failed mount, this is not what happened. -- Per Jessen, Zürich (9.3°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 27 Oct 2010 13:46:31 +0200 Stephan Kulow <coolo@novell.com> wrote:
Hi,
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
So next step would be a wider testing: so please install systemd and boot with init=/bin/systemd and report issues (here).
Not impressed. Boot takes much longer than with traditional init, the system is sitting idle (no disk activity, no visible activity at all) for long periods of time during boot. /etc/fstab is not obeyed: susi:~ # cat /etc/crypttab cr_sda7 /dev/disk/by-id/ata-WDC_WD2500BEVS-08VAT2_WD-WX20AC9U2733-part7 none none susi:~ # cat /etc/fstab LABEL=root-FACTORY / ext4 acl,user_xattr 1 1 /dev/mapper/cr_sda7 /home ext3 noatime,acl,user_xattr,nofail 0 0 /dev/disk/by-id/ata-WDC_WD2500BEVS-08VAT2_WD-WX20AC9U2733-part5 swap swap defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 LABEL=local /local xfs noatime,logbufs=8,logbsize=262144 1 2 /local/libvirt /var/lib/libvirt none bind 1 2 LABEL=space /space xfs user,noauto,noatime,logbufs=8,logbsize=262144 0 0 susi:~ # mount /dev/sda6 on / type ext4 (rw,acl,user_xattr,commit=0) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devtmpfs on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) /dev/sda9 on /local type xfs (rw,noatime,logbufs=8,logbsize=262144) /dev/mapper/cr_sda7 on /home type ext3 (rw,_netdev,noatime,acl,user_xattr,commit=0) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) /proc on /var/lib/ntp/proc type none (ro,nosuid,nodev,bind) fusectl on /sys/fs/fuse/connections type fusectl (rw) gvfs-fuse-daemon on /home/seife/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=seife) susi:~ # df /var/lib/libvirt/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda6 10320184 7646096 2149852 79% / => the /var/lib/libvirt mount is ignored. => /var/run is mounted twice [ 77.203139] systemd[1]: crypto-early.service: control process exited, code=exited status=1 [ 77.206148] systemd[1]: Unit crypto-early.service entered failed state. [ 77.301585] systemd[1]: dev-disk-by\x2did-ata\x2dWDC_WD2500BEVS\x2d08VAT2_WD\x2dWX20AC9U2733\x2dpart5.swap swap process exited, code=exited status=255 [ 77.301611] systemd[1]: Unit dev-disk-by\x2did-ata\x2dWDC_WD2500BEVS\x2d08VAT2_WD\x2dWX20AC9U2733\x2dpart5.swap entered failed state. [ 115.600168] systemd[1]: Startup finished in 4s 90ms 164us (kernel) + 1min 51s 509ms 898us (userspace) = 1min 55s 600ms 62us. "reboot" does nothing. The only way to reboot the machine is either to pull the plug or to type "quick_reboot". Oct 30 12:02:31 susi systemd-initctl[3289]: Received environment initctl request. This is not implemented in systemd. Oct 30 12:02:31 susi systemd-initctl[3289]: Failed to start unit: Transaction order is cyclic. See system logs for details. Oct 30 12:02:31 susi kernel: [ 191.703093] systemd[1]: Found ordering cycle on basic.target/stop Oct 30 12:02:31 susi kernel: [ 191.703103] systemd[1]: Walked on cycle path to sysinit.target/stop Oct 30 12:02:31 susi kernel: [ 191.703111] systemd[1]: Walked on cycle path to open-iscsi.service/stop Oct 30 12:02:31 susi kernel: [ 191.703119] systemd[1]: Walked on cycle path to basic.target/stop Oct 30 12:02:31 susi kernel: [ 191.703126] systemd[1]: Unable to break cycle Oct 30 12:02:31 susi kernel: [ 191.703134] systemd[1]: Requested transaction contains an unfixable cyclic ordering dependency: Transaction order is cyclic. See system logs for details. ctrl-alt-del: Oct 30 12:04:31 susi kernel: [ 310.893968] systemd[1]: Activating special unit ctrl-alt-del.target Oct 30 12:04:31 susi kernel: [ 310.894255] systemd[1]: Found ordering cycle on basic.target/stop Oct 30 12:04:31 susi kernel: [ 310.894264] systemd[1]: Walked on cycle path to sysinit.target/stop Oct 30 12:04:31 susi kernel: [ 310.894272] systemd[1]: Walked on cycle path to open-iscsi.service/stop Oct 30 12:04:31 susi kernel: [ 310.894280] systemd[1]: Walked on cycle path to basic.target/stop Oct 30 12:04:31 susi kernel: [ 310.894287] systemd[1]: Unable to break cycle Oct 30 12:04:31 susi kernel: [ 310.894295] systemd[1]: Requested transaction contains an unfixable cyclic ordering dependency: Transaction order is cyclic. See system logs for details. Oct 30 12:04:31 susi kernel: [ 310.894305] systemd[1]: Failed to enqueue ctrl-alt-del.target job: Transaction order is cyclic. See system logs for details. Not (yet) a way to have a lot of fun... -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Saturday 30 October 2010 12:24:52 Stefan Seyfried wrote:
On Wed, 27 Oct 2010 13:46:31 +0200
Stephan Kulow <coolo@novell.com> wrote:
Hi,
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
So next step would be a wider testing: so please install systemd and boot with init=/bin/systemd and report issues (here).
Not impressed. Boot takes much longer than with traditional init, the system is sitting idle (no disk activity, no visible activity at all) for long periods of time during boot.
/etc/fstab is not obeyed: susi:~ # cat /etc/crypttab cr_sda7 /dev/disk/by-id/ata-WDC_WD2500BEVS-08VAT2_WD-WX20AC9U2733-part7 none none susi:~ # cat /etc/fstab LABEL=root-FACTORY / ext4 acl,user_xattr 1 1 /dev/mapper/cr_sda7 /home ext3 noatime,acl,user_xattr,nofail 0 0 /dev/disk/by-id/ata-WDC_WD2500BEVS-08VAT2_WD-WX20AC9U2733-part5 swap swap defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 LABEL=local /local xfs noatime,logbufs=8,logbsize=262144 1 2 /local/libvirt /var/lib/libvirt none bind 1 2 LABEL=space /space xfs user,noauto,noatime,logbufs=8,logbsize=262144 0 0 susi:~ # mount /dev/sda6 on / type ext4 (rw,acl,user_xattr,commit=0) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devtmpfs on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) /dev/sda9 on /local type xfs (rw,noatime,logbufs=8,logbsize=262144) /dev/mapper/cr_sda7 on /home type ext3 (rw,_netdev,noatime,acl,user_xattr,commit=0) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) /proc on /var/lib/ntp/proc type none (ro,nosuid,nodev,bind) fusectl on /sys/fs/fuse/connections type fusectl (rw) gvfs-fuse-daemon on /home/seife/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=seife) susi:~ # df /var/lib/libvirt/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda6 10320184 7646096 2149852 79% /
=> the /var/lib/libvirt mount is ignored. => /var/run is mounted twice
Could you file bugreports for these, please?
[ 77.203139] systemd[1]: crypto-early.service: control process exited, code=exited status=1 [ 77.206148] systemd[1]: Unit crypto-early.service entered failed state. [ 77.301585] systemd[1]: dev-disk-by\x2did-ata\x2dWDC_WD2500BEVS\x2d08VAT2_WD\x2dWX20AC9U2733\x2 dpart5.swap swap process exited, code=exited status=255 [ 77.301611] systemd[1]: Unit dev-disk-by\x2did-ata\x2dWDC_WD2500BEVS\x2d08VAT2_WD\x2dWX20AC9U2733\x2 dpart5.swap entered failed state. [ 115.600168] systemd[1]: Startup finished in 4s 90ms 164us (kernel) + 1min 51s 509ms 898us (userspace) = 1min 55s 600ms 62us.
"reboot" does nothing. The only way to reboot the machine is either to pull the plug or to type "quick_reboot".
Oct 30 12:02:31 susi systemd-initctl[3289]: Received environment initctl request. This is not implemented in systemd. Oct 30 12:02:31 susi systemd-initctl[3289]: Failed to start unit: Transaction order is cyclic. See system logs for details. Oct 30 12:02:31 susi kernel: [ 191.703093] systemd[1]: Found ordering cycle on basic.target/stop Oct 30 12:02:31 susi kernel: [ 191.703103] systemd[1]: Walked on cycle path to sysinit.target/stop Oct 30 12:02:31 susi kernel: [ 191.703111] systemd[1]: Walked on cycle path to open-iscsi.service/stop Oct 30 12:02:31 susi kernel: [ 191.703119] systemd[1]: Walked on cycle path to basic.target/stop Oct 30 12:02:31 susi kernel: [ 191.703126] systemd[1]: Unable to break cycle Oct 30 12:02:31 susi kernel: [ 191.703134] systemd[1]: Requested transaction contains an unfixable cyclic ordering dependency: Transaction order is cyclic. See system logs for details.
Kay, why does it fail to reboot if cycles exist? This behaviour is IMO a bug. The cycle itself is a bug as well. Kay, could you enhancd the SDB:Systemd page with some info on debugging and reporting bugs?
ctrl-alt-del: Oct 30 12:04:31 susi kernel: [ 310.893968] systemd[1]: Activating special unit ctrl-alt-del.target Oct 30 12:04:31 susi kernel: [ 310.894255] systemd[1]: Found ordering cycle on basic.target/stop Oct 30 12:04:31 susi kernel: [ 310.894264] systemd[1]: Walked on cycle path to sysinit.target/stop Oct 30 12:04:31 susi kernel: [ 310.894272] systemd[1]: Walked on cycle path to open-iscsi.service/stop Oct 30 12:04:31 susi kernel: [ 310.894280] systemd[1]: Walked on cycle path to basic.target/stop Oct 30 12:04:31 susi kernel: [ 310.894287] systemd[1]: Unable to break cycle Oct 30 12:04:31 susi kernel: [ 310.894295] systemd[1]: Requested transaction contains an unfixable cyclic ordering dependency: Transaction order is cyclic. See system logs for details. Oct 30 12:04:31 susi kernel: [ 310.894305] systemd[1]: Failed to enqueue ctrl-alt-del.target job: Transaction order is cyclic. See system logs for details.
Not (yet) a way to have a lot of fun...
Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, 2010-11-01 at 16:29 +0100, Andreas Jaeger wrote:
On Saturday 30 October 2010 12:24:52 Stefan Seyfried wrote:
cyclic ordering dependency: Transaction order is cyclic. See system logs for details.
Kay, why does it fail to reboot if cycles exist? This behaviour is IMO a bug.
It's fixed. Also the rescue shell on failure, and the unusual initramfs behavior to mount / rw is fixed, and fsck does not fail here anymore. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 02/11/10 10:33, Kay Sievers escribió:
It's fixed.
Cool, I have a problem when running systemd this mount table does not look correct ➜ system mount /dev/sda2 on / type ext4 (rw,noatime,data=writeback,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devtmpfs on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) Looks like it is mounting ad infinitum :D -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 2010-11-03 at 19:07 -0300, Cristian Rodríguez wrote:
El 02/11/10 10:33, Kay Sievers escribió:
It's fixed.
Cool, I have a problem when running systemd
this mount table does not look correct
➜ system mount /dev/sda2 on / type ext4 (rw,noatime,data=writeback,acl,user_xattr) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devtmpfs on /dev type devtmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,mode=0620,gid=5) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) securityfs on /sys/kernel/security type securityfs (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) tmpfs on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=755) tmpfs on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=775,gid=54) mqueue on /dev/mqueue type mqueue (rw) hugetlbfs on /dev/hugepages type hugetlbfs (rw) securityfs on /sys/kernel/security type securityfs (rw)
Looks like it is mounting ad infinitum :D
(was on the road for a week, sorry) Systemd does not support /etc/mtab anymore. Mirroring volatile kernel state in the filesystem is a concept which you can not win with today's setups. It must be a symlink to /proc/mounts. Systemd will log an error now, when /etc/mtab is not a symlink. We will need to find out which package need to do this on upgrade, likely util-linux. Thanks, Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, On Wed, Nov 10, 2010 at 12:56:00AM +0100, Kay Sievers wrote:
Systemd does not support /etc/mtab anymore. Mirroring volatile kernel state in the filesystem is a concept which you can not win with today's setups. It must be a symlink to /proc/mounts.
Systemd will log an error now, when /etc/mtab is not a symlink.
I agree writable /etc/mtab is something we should get rid of (and AFAIK util-linux upstream is working on it). OTOH, there is still some information missing in /proc/mounts compared to what's written in mtab - e.g. the 'user' option will if mtab is a symlink to /proc/mounts. How do you plan to deal with this?
We will need to find out which package need to do this on upgrade, likely util-linux.
Yes, util-linux sounds logical.
Thanks, Kay
Regards, Petr -- Petr Uzel IRC: ptr_uzl @ freenode
Am Mittwoch 10 November 2010 schrieb Petr Uzel:
Hi,
On Wed, Nov 10, 2010 at 12:56:00AM +0100, Kay Sievers wrote:
Systemd does not support /etc/mtab anymore. Mirroring volatile kernel state in the filesystem is a concept which you can not win with today's setups. It must be a symlink to /proc/mounts.
Systemd will log an error now, when /etc/mtab is not a symlink.
I agree writable /etc/mtab is something we should get rid of (and AFAIK util-linux upstream is working on it). OTOH, there is still some information missing in /proc/mounts compared to what's written in mtab - e.g. the 'user' option will if mtab is a symlink to /proc/mounts.
How do you plan to deal with this?
mount writes a file to e.g. /var/adm that contains such options and that mount will then display. Other tools parsing mtab may miss such informations, but adding support for it in glibc should be possible too once util-linux. This is at least what I gathered from an IRC discussion between systemd and util-linux-ng maintainers (both redhat employees, so possible fedora has already patches for it, I couldn't find anything in util-linux-ng git yet). Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 2010-11-10 at 08:07 +0100, Petr Uzel wrote:
On Wed, Nov 10, 2010 at 12:56:00AM +0100, Kay Sievers wrote:
Systemd does not support /etc/mtab anymore. Mirroring volatile kernel state in the filesystem is a concept which you can not win with today's setups. It must be a symlink to /proc/mounts.
Systemd will log an error now, when /etc/mtab is not a symlink.
I agree writable /etc/mtab is something we should get rid of (and AFAIK util-linux upstream is working on it). OTOH, there is still some information missing in /proc/mounts compared to what's written in mtab - e.g. the 'user' option will if mtab is a symlink to /proc/mounts.
How do you plan to deal with this?
It will likely be stored in private file(s) in /dev/.mount/*. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, 1 Nov 2010 16:29:14 +0100 Andreas Jaeger <aj@novell.com> wrote:
On Saturday 30 October 2010 12:24:52 Stefan Seyfried wrote:
=> the /var/lib/libvirt mount is ignored.
https://bugzilla.novell.com/show_bug.cgi?id=652762
=> /var/run is mounted twice
This seems to be a side effect of the fstab problem, at least today it was only mounted once, and symlinking /proc/mounts to /etc/fstab has fixed the display problem ;) Two other reports: * cryptohome needs extra [enter] to mount https://bugzilla.novell.com/show_bug.cgi?id=652767 * 60 second wait during boot https://bugzilla.novell.com/show_bug.cgi?id=652706
Could you file bugreports for these, please?
Kay, why does it fail to reboot if cycles exist? This behaviour is IMO a bug.
rebooting does work now. -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Testing today's version, I noticed that the following directories were not created: d /var/run/screens 0755 root root - d /var/run/uscreens 1777 root root - d /var/run/vi.recover 1777 root root - d /var/run/PolicyKit 0770 polkituser polkituser - Kay, does systemd-tmpfiles-setup.service replace boot.cleanup? If yes, I'm curious where this is configured... Otherwise, I wonder why it did not get executed... I guess the right solution would be to create /etc/tmpfiles.d/{screen,vi,PolicyKit} for these? Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le mercredi 03 novembre 2010, à 10:20 +0100, Andreas Jaeger a écrit :
Testing today's version, I noticed that the following directories were not created:
d /var/run/screens 0755 root root - d /var/run/uscreens 1777 root root - d /var/run/vi.recover 1777 root root - d /var/run/PolicyKit 0770 polkituser polkituser -
Kay, does systemd-tmpfiles-setup.service replace boot.cleanup? If yes, I'm curious where this is configured... Otherwise, I wonder why it did not get executed...
I guess the right solution would be to create /etc/tmpfiles.d/{screen,vi,PolicyKit} for these?
Yes. I said I'd take care of the screen one, but haven't done this yet... Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
I don't have any virtual terminals while using systemd Now I boot without init=/bin/systemd in the command line opensuse11.4 ms3 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Andreas Jaeger wrote:
Testing today's version, I noticed that the following directories were not created:
d /var/run/screens 0755 root root - d /var/run/uscreens 1777 root root - d /var/run/vi.recover 1777 root root - d /var/run/PolicyKit 0770 polkituser polkituser -
Kay, does systemd-tmpfiles-setup.service replace boot.cleanup? If yes, I'm curious where this is configured... Otherwise, I wonder why it did not get executed...
I guess the right solution would be to create /etc/tmpfiles.d/{screen,vi,PolicyKit} for these?
What about getting rid of the ugly /etc/tmpdirs.d/ then? boot.cleanup could read /etc/tmpfiles.d just as well. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday 03 November 2010 14:35:27 Ludwig Nussel wrote:
Andreas Jaeger wrote:
Testing today's version, I noticed that the following directories were not created:
d /var/run/screens 0755 root root - d /var/run/uscreens 1777 root root - d /var/run/vi.recover 1777 root root - d /var/run/PolicyKit 0770 polkituser polkituser -
Kay, does systemd-tmpfiles-setup.service replace boot.cleanup? If yes, I'm curious where this is configured... Otherwise, I wonder why it did not get executed...
I guess the right solution would be to create /etc/tmpfiles.d/{screen,vi,PolicyKit} for these?
What about getting rid of the ugly /etc/tmpdirs.d/ then? boot.cleanup could read /etc/tmpfiles.d just as well.
Good idea IMO to merge to one solution... Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Well this machine has no /etc/tmpfiles.d directory and is missing one of your mentioned statements. Everything else is there. Question is "d /var/run/vi.recover 1777 root root -" is missing. Do I need it in /etc/tmpdirs? What does the contents of /etc/tmpdirs.d/ do for this machine. Who/What creates these statements and is it configured somewhere? On 11/03/2010 08:35 AM, Ludwig Nussel wrote:
Andreas Jaeger wrote:
Testing today's version, I noticed that the following directories were not created:
d /var/run/screens 0755 root root - d /var/run/uscreens 1777 root root - d /var/run/vi.recover 1777 root root - d /var/run/PolicyKit 0770 polkituser polkituser -
Kay, does systemd-tmpfiles-setup.service replace boot.cleanup? If yes, I'm curious where this is configured... Otherwise, I wonder why it did not get executed...
I guess the right solution would be to create /etc/tmpfiles.d/{screen,vi,PolicyKit} for these? What about getting rid of the ugly /etc/tmpdirs.d/ then? boot.cleanup could read /etc/tmpfiles.d just as well.
cu Ludwig
-- 73 de Donn Washburn 307 Savoy Street Email:" n5xwb@comcast.net " Sugar Land, TX 77478 LL# 1.281.242.3256 Ham Callsign N5XWB HAMs : " n5xwb@arrl.net " VoIP via Gizmo: bmw_87kbike / via Skype: n5xwbg BMW MOA #: 4146 - Ambassador " http://counter.li.org " #279316 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 2010-11-03 at 14:35 +0100, Ludwig Nussel wrote:
Andreas Jaeger wrote:
Testing today's version, I noticed that the following directories were not created:
d /var/run/screens 0755 root root - d /var/run/uscreens 1777 root root - d /var/run/vi.recover 1777 root root - d /var/run/PolicyKit 0770 polkituser polkituser -
Kay, does systemd-tmpfiles-setup.service replace boot.cleanup? If yes, I'm curious where this is configured... Otherwise, I wonder why it did not get executed...
I guess the right solution would be to create /etc/tmpfiles.d/{screen,vi,PolicyKit} for these?
What about getting rid of the ugly /etc/tmpdirs.d/ then? boot.cleanup could read /etc/tmpfiles.d just as well.
Sounds good, yeah. The Debian guys want to do the same. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 18:58 Wed 03 Nov 2010, Kay Sievers wrote:
On Wed, 2010-11-03 at 14:35 +0100, Ludwig Nussel wrote:
Andreas Jaeger wrote:
Testing today's version, I noticed that the following directories were not created:
d /var/run/screens 0755 root root - d /var/run/uscreens 1777 root root - d /var/run/vi.recover 1777 root root - d /var/run/PolicyKit 0770 polkituser polkituser -
Kay, does systemd-tmpfiles-setup.service replace boot.cleanup? If yes, I'm curious where this is configured... Otherwise, I wonder why it did not get executed...
I guess the right solution would be to create /etc/tmpfiles.d/{screen,vi,PolicyKit} for these?
What about getting rid of the ugly /etc/tmpdirs.d/ then? boot.cleanup could read /etc/tmpfiles.d just as well.
Sounds good, yeah. The Debian guys want to do the same.
Here is a quick implementation of a shell script to do the /etc/tmpfiles.d/ work that we can merge into aaa_base. It implements the verbs that we care about right now: create and remove. I can send a patch to fix aaa_base to call this script and remove the screen specific stuff too as the Factory version of screen now ships a /etc/tmpfiles.d file. Eventually it would be great to move all of the magic for tmp files in aaa_base and have packages ship /etc/tmpfiles.d. This is a place to start. Thoughts? Cheers, Brandon #!/bin/sh # Limited implementation of /lib/systemd/systemd-tmpfiles in shell # Copyright 2010 (C) Brandon Philips <bphilips@suse.de> # # Licensed under GPLv2 # This reads all files listed in /etc/tmpfiles.d/?*.conf and creates # them in the file system. This is intended to be used to create # properly owned directories beneath /tmp, /var/tmp, /var/run and # /var/lock which are volatile and hence need to be recreated on # bootup. if [ $# -lt 1 ]; then echo "aaa-tmpfiles (--create|--clean|--remove)+" exit 1 fi for arg in $*; do case "$arg" in --create) arg_create=true ;; --remove) arg_remove=true ;; --clean) arg_clean=true ;; *) echo "Unknown option '$arg'" exit 1 ;; esac done function create_item() { case "$type" in # IGNORE_PATH | REMOVE_PATH | RECURSIVE_REMOVE_PATH x|r|R) return ;; #CREATE_FILE f) touch $file ;; #TRUNCATE_FILE F) cat /dev/null > $file ;; # CREATE_DIRECTORY | TRUNCATE_DIRECTORY D|d) mkdir $file ;; esac [ $mode ] && [ $mode != '-' ] && chmod $mode $file [ $user ] && [ $user != '-' ] && chown $user $file [ $group ] && [ $group != '-' ] && chown :$group $file } function clean_item { case "$type" in # CREATE_DIRECTORY | TRUNCATE_DIRECTORY | IGNORE_PATH d|D|x) # Stub not implemented ;; esac } function remove_item { case "$type" in # CREATE_FILE | TRUNCATE_FILE | CREATE_DIRECTORY | IGNORE_PATH f|F|d|x) ;; # RECURSIVE_REMOVE_PATH | TRUNCATE_DIRECTORY D|R) rm -Rf $file ;; # REMOVE_PATH r) rm $file ;; esac } # # parse all of the tmpfiles configs # example line: # d /var/lock/subsys 0755 root root - # cat /etc/tmpfiles.d/* | sed -e '/^#.*$/d' -e '/^\s*$/d' | while read line; do eval $(echo $line |\ sed -n "s/\(.\)\s\(.*\)\s\(.*\)\s\(.*\)\s\(.*\)\s\(.*\)/type=\1\nfile=\2\nmode=\3\nuser=\4\ngroup=\5\nage=\6/p") if [ ! $type ] || [ ! $file ]; then echo "Error: no type or file" echo $line exit 1 fi [ $arg_create ] && create_item [ $arg_remove ] && remove_item [ $arg_clean ] && clean_item done -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday 03 November 2010 23:03:41 Brandon Philips wrote:
On 18:58 Wed 03 Nov 2010, Kay Sievers wrote:
On Wed, 2010-11-03 at 14:35 +0100, Ludwig Nussel wrote:
Andreas Jaeger wrote:
Testing today's version, I noticed that the following directories were not created:
d /var/run/screens 0755 root root - d /var/run/uscreens 1777 root root - d /var/run/vi.recover 1777 root root - d /var/run/PolicyKit 0770 polkituser polkituser -
Kay, does systemd-tmpfiles-setup.service replace boot.cleanup? If yes, I'm curious where this is configured... Otherwise, I wonder why it did not get executed...
I guess the right solution would be to create /etc/tmpfiles.d/{screen,vi,PolicyKit} for these?
What about getting rid of the ugly /etc/tmpdirs.d/ then? boot.cleanup could read /etc/tmpfiles.d just as well.
Sounds good, yeah. The Debian guys want to do the same.
Here is a quick implementation of a shell script to do the /etc/tmpfiles.d/ work that we can merge into aaa_base. It implements the verbs that we care about right now: create and remove.
I can send a patch to fix aaa_base to call this script and remove the screen specific stuff too as the Factory version of screen now ships a /etc/tmpfiles.d file.
And also the vim bits. Sounds like a good way to move forward.
Eventually it would be great to move all of the magic for tmp files in aaa_base and have packages ship /etc/tmpfiles.d. This is a place to start.
Right now some files are part of systemd: /etc/tmpfiles.d/systemd.conf /etc/tmpfiles.d/x11.conf I just fixed PolicyKit and vim to have conf files as well, so the packages part is done but we should double check this later. So, IMO, we should move the two files from systemd to another package that gets installed on its own and can be used without going to systemd - or we require systemd installation just because of these files,... Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Donnerstag, 4. November 2010, 10:47:34 schrieb Andreas Jaeger:
On Wednesday 03 November 2010 23:03:41 Brandon Philips wrote:
On 18:58 Wed 03 Nov 2010, Kay Sievers wrote:
On Wed, 2010-11-03 at 14:35 +0100, Ludwig Nussel wrote:
Andreas Jaeger wrote:
Testing today's version, I noticed that the following directories were not created:
d /var/run/screens 0755 root root - d /var/run/uscreens 1777 root root - d /var/run/vi.recover 1777 root root - d /var/run/PolicyKit 0770 polkituser polkituser -
Kay, does systemd-tmpfiles-setup.service replace boot.cleanup? If yes, I'm curious where this is configured... Otherwise, I wonder why it did not get executed...
I guess the right solution would be to create /etc/tmpfiles.d/{screen,vi,PolicyKit} for these?
What about getting rid of the ugly /etc/tmpdirs.d/ then? boot.cleanup could read /etc/tmpfiles.d just as well.
Sounds good, yeah. The Debian guys want to do the same.
Here is a quick implementation of a shell script to do the /etc/tmpfiles.d/ work that we can merge into aaa_base. It implements the verbs that we care about right now: create and remove.
I can send a patch to fix aaa_base to call this script and remove the screen specific stuff too as the Factory version of screen now ships a /etc/tmpfiles.d file.
And also the vim bits. Sounds like a good way to move forward.
Eventually it would be great to move all of the magic for tmp files in aaa_base and have packages ship /etc/tmpfiles.d. This is a place to start.
Right now some files are part of systemd: /etc/tmpfiles.d/systemd.conf /etc/tmpfiles.d/x11.conf
I just fixed PolicyKit and vim to have conf files as well, so the packages part is done but we should double check this later.
So, IMO, we should move the two files from systemd to another package that gets installed on its own and can be used without going to systemd - or we require systemd installation just because of these files,...
moving the files to the packages where they belong sounds like a good idea, I'd think we want to prevent another package getting the "trashcan-syndrome" that aaa_base sometimes has. Can I find the info on the format of these files somewhere (since I possibly have to implement reading the files in boot.cleanup as well) ... ? -- with kind regards (mit freundlichem Grinsen), Ruediger Oertel (ro@novell.com,ro@suse.de,bugfinder@t-online.de) ---------------------------------------------------------------------- Linux fatou 2.6.36-3-default #1 SMP 2010-10-26 21:31:22 +0200 x86_64 Key fingerprint = 17DC 6553 86A7 384B 53C5 CA5C 3CE4 F2E7 23F2 B417 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 15:25 Thu 04 Nov 2010, Ruediger Oertel wrote:
Can I find the info on the format of these files somewhere (since I possibly have to implement reading the files in boot.cleanup as well) ... ?
Andreas just sent a patch that explains the format to the systemd mailing list: http://lists.freedesktop.org/archives/systemd-devel/2010-November/000712.htm... Cheers, Brandon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 10:47 Thu 04 Nov 2010, Andreas Jaeger wrote:
So, IMO, we should move the two files from systemd to another package that gets installed on its own and can be used without going to systemd
I would wait and see how upstream and systemd works out where the X tmpfiles.d conf ends up.
or we require systemd installation just because of these files,...
I know you are half joking but installing systemd by default makes good sense as we seem to plan on using it eventually as default. For Factory it would really lower the barrier for users testing systemd (init=/bin/systemd) if we don't end up using it as init for 11.4. Also, and more importantly to this discussion, if we install systemd by default in Factory we could skip my silly and possibly broken tmpfiles script and just use /lib/systemd/systemd-tmpfiles instead in aaa_base. Cheers, Brandon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Brandon Philips wrote:
Here is a quick implementation of a shell script to do the /etc/tmpfiles.d/ work that we can merge into aaa_base. It implements the verbs that we care about right now: create and remove.
Alternatively the small systemd-tmpfiles binary could probably be split off systemd and be used directly. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday 03 November 2010 23:03:41 Brandon Philips wrote:
Thoughts? [...] # # parse all of the tmpfiles configs # example line: # d /var/lock/subsys 0755 root root - # cat /etc/tmpfiles.d/* | sed -e '/^#.*$/d' -e '/^\s*$/d' | while read line; do eval $(echo $line |\ sed -n "s/\(.\)\s\(.*\)\s\(.*\)\s\(.*\)\s\(.*\)\s\(.*\)/type=\1\nfile=\2\nmode=\3 \nuser=\4\ngroup=\5\nage=\6/p")
if [ ! $type ] || [ ! $file ]; then echo "Error: no type or file" echo $line exit 1 fi
[ $arg_create ] && create_item [ $arg_remove ] && remove_item [ $arg_clean ] && clean_item done
I don't really like constructs like echo $foo | sed. Bash can usually do a much better job on its own, as long as you don't need really complex things. Please consider a construct like this instead for i in /etc/tmpfiles.d/*; do while read type file mode user group age; do if [ ! $type ] || [ ! $file ]; then echo "Error: no type or file" echo $line exit 1 fi # do the work..... done < $i done I'm also not sure why you allow multiple parameters when they look to be mutually exclusive Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Anders Johansson <ajohansson@novell.com> [2010-11-04 11:22]:
On Wednesday 03 November 2010 23:03:41 Brandon Philips wrote:
Thoughts? [...] # # parse all of the tmpfiles configs # example line: # d /var/lock/subsys 0755 root root - # cat /etc/tmpfiles.d/* | sed -e '/^#.*$/d' -e '/^\s*$/d' | while read line; do eval $(echo $line |\ sed -n "s/\(.\)\s\(.*\)\s\(.*\)\s\(.*\)\s\(.*\)\s\(.*\)/type=\1\nfile=\2\nmode=\3 \nuser=\4\ngroup=\5\nage=\6/p")
if [ ! $type ] || [ ! $file ]; then echo "Error: no type or file" echo $line exit 1 fi
[ $arg_create ] && create_item [ $arg_remove ] && remove_item [ $arg_clean ] && clean_item done
I don't really like constructs like echo $foo | sed. Bash can usually do a much better job on its own, as long as you don't need really complex things. Please consider a construct like this instead
for i in /etc/tmpfiles.d/*; do while read type file mode user group age; do if [ ! $type ] || [ ! $file ]; then echo "Error: no type or file" echo $line exit 1 fi # do the work..... done < $i done
This breaks for empty lines and comments, furthermore the "!" operator is not a safe way to check for an empty string use "-n" or "-z", more generally read should always be used with "-r" to prevent interpretation of escape sequences, and variables should be put in quotes to protect field splitting and globbing. Using built in field splitting allows easily to check for empty lines and the number of arguments per line, also this does not need bash, any POSIX shell is sufficient: for tmpdir_file in /etc/tmpfiles.d/*; do while read -r line; do set -- ${line} [ "$1" = "#" ] && continue [ $# -eq 0 ] && continue if [ $# -lt 3 ]; then printf "Error: no type or file\n" >&2 printf "%s\n" "${line}" >&2 exit 1 fi type="$1"; file="$2"; mode="$3"; user="$4"; group="$5"; age="$6" [ -n "${arg_create}" ] && create_item [ -n "${arg_remove}" ] && remove_item [ -n "${arg_clean}" ] && clean_item done < "${tmpdir_file}" done -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 2010-11-03 at 10:20 +0100, Andreas Jaeger wrote:
Testing today's version, I noticed that the following directories were not created:
d /var/run/screens 0755 root root - d /var/run/uscreens 1777 root root - d /var/run/vi.recover 1777 root root - d /var/run/PolicyKit 0770 polkituser polkituser -
Kay, does systemd-tmpfiles-setup.service replace boot.cleanup? If yes, I'm curious where this is configured... Otherwise, I wonder why it did not get executed...
Its an alias to boot.cleanup, yes.
I guess the right solution would be to create /etc/tmpfiles.d/{screen,vi,PolicyKit} for these?
Yes, we need to add these files to the packages. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Stephan Kulow <coolo@novell.com> [2010-10-27 13:46]:
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
So this means we will loose interactive boot and the ability to start services in a chroot? I hope this will not be the default in an openSUSE release before Fedora 15 is out. I still remeber the fallout when Ubuntu switched (as the first distro) to native upstart jobs. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Mittwoch 03 November 2010 schrieb Guido Berhoerster:
* Stephan Kulow <coolo@novell.com> [2010-10-27 13:46]:
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
So this means we will loose interactive boot and the ability to start services in a chroot? I think you're the first to mention interactive boot as feature.
I hope this will not be the default in an openSUSE release before Fedora 15 is out. I still remeber the fallout when Ubuntu switched (as the first distro) to native upstart jobs.
What fallout? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Stephan Kulow <coolo@novell.com> [2010-11-03 15:16]:
Am Mittwoch 03 November 2010 schrieb Guido Berhoerster:
* Stephan Kulow <coolo@novell.com> [2010-10-27 13:46]:
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
So this means we will loose interactive boot and the ability to start services in a chroot? I think you're the first to mention interactive boot as feature.
I have used it in the past to debug init scripts and to selectively disable certain scripts and force scripts to be executed serially. Same goes for being able to start daemons without having to write init scripts (also a problem with upstart), is there anything planned to allow that with systemd services?
I hope this will not be the default in an openSUSE release before Fedora 15 is out. I still remeber the fallout when Ubuntu switched (as the first distro) to native upstart jobs.
What fallout?
The inevitable fallout of bugs when exposing a complex piece of software for the first time to a large number of users and thus use cases. While I admit that part of the bad experience with Ubuntu might have been due to their (lack of) QA and the horrible approach of mixing native jobs with sysv-initscripts and the lack of equivalent interfaces in upstart (e.g. reload/restart actions expected by .deb pre/post-install scripts) there still were a lot of plain bugs despite all testing and earlier usage of upstart for legacy sysvinit-scripts. Examples of bugs I have encountered were GDM sometimes not coming up clearly due to some race, hanging boot process when mounting NFS shares from a NAS server on bootup, unreliable tracing of daemons, and pressing SAK in order to get out of an unresponsive X session killing upstart/init. Point is that despite all the testing these kinds of issues will come up when rolling out systemd to thousands of users and forcing the openSUSE userbase to become beta testers for Redhat would IMHO be a disservice to the whole project. Let them give it some exposure in Fedora 15 first, I suppose people using Fedora are used to certain levels of pain. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 2010-11-03 at 11:26 +0100, Guido Berhoerster wrote:
* Stephan Kulow <coolo@novell.com> [2010-10-27 13:46]:
There have been various talks about systemd at the openSUSE conference and we would like to go forward.
So this means we will loose interactive boot and the ability to start services in a chroot?
systemd natively supports interactive boot, in addition to a few other facilities to simplify debugging of the boot-up. systemd has native support for chrooting services. Just use the RootDirectory= switch in systemd unit files. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
I've created now a status page about the status of systemd integration targetting package maintainers: http://en.opensuse.org/openSUSE:Systemd_status Please help completing the page - and add also what you think is missing, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (19)
-
Anders Johansson -
Andreas Jaeger -
Bill Pye -
Brandon Philips -
Cristian Rodríguez -
Dale Ritchey -
Donn Washburn -
Guido Berhoerster -
İsmail Dönmez -
Kay Sievers -
Ludwig Nussel -
Matt Hayes -
Per Jessen -
Petr Uzel -
Raymond Wooninck -
Ruediger Oertel -
Stefan Seyfried -
Stephan Kulow -
Vincent Untz