[opensuse-factory] Some second thoughts on systemd/sysvinit/udev

newer
[opensuse-factory] Build kernel...

Dr. Werner Fink

8 Jul 2011 8 Jul '11

16:43

Hi to every one, I'd like to do some notes on the topic how become systemd or should I better say udev better integrated in the current system scheme regardless of the used init. First of all as already mentioned the real problem why e.g. old-fashioned /usr isn't supported as an own partition by systemd (or better systemd warns about such a fact) is that the rules expanded by udev do not know about dependency orders on boot passed through by systemd as well as by the traditional sysvinit. This will lead e.g. to problems for the faciltiy `$remote_fs' defined by LSB specs. To solve this problem the udevd should be able to understand the dependencies of the services provided by the boot scripts of sysvinit as well as the dependencies of the systemd service configuration files. It would be perfect that achieving such dependencies could be understood as events within udev rules. The question is how to expand and resolve e.g. the LSB dependency rules of traditional boot scripts or e.g. the systemd configuration files for udev. IMHO this would require at least also a notification for udev which could be done by systemd and for sysvinit within the main boot scripts or the startpar utility used by main boot scripts. Currently udevadm seems to be able to do this on base of devices. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Show replies by date

Kay Sievers

8 Jul 8 Jul

17:18

New subject: [opensuse-factory] Re: Some second thoughts on systemd/sysvinit/udev

On Fri, Jul 8, 2011 at 18:43, Dr. Werner Fink wrote:

...

I'd like to do some notes on the topic how become systemd or should I better say udev better integrated in the current system scheme regardless of the used init.

First of all as already mentioned the real problem why e.g. old-fashioned /usr isn't supported as an own partition by systemd (or better systemd warns about such a fact) is that the rules expanded by udev do not know about dependency orders on boot passed through by systemd as well as by the traditional sysvinit. This will lead e.g. to problems for the faciltiy `$remote_fs' defined by LSB specs.

To solve this problem the udevd should be able to understand the dependencies of the services provided by the boot scripts of sysvinit as well as the dependencies of the systemd service configuration files. It would be perfect that achieving such dependencies could be understood as events within udev rules.

The question is how to expand and resolve e.g. the LSB dependency rules of traditional boot scripts or e.g. the systemd configuration files for udev. IMHO this would require at least also a notification for udev which could be done by systemd and for sysvinit within the main boot scripts or the startpar utility used by main boot scripts. Currently udevadm seems to be able to do this on base of devices.

/usr should just be mounted from initramfs. That solves all the problems. The artificial split of / and /usr makes not much sense in today's setups. What / was for UNIX, is the initramfs for Linux. Udev is just one of the users. We will never be able to fix all userspace to handle the broken idea of splitting off / and /usr. We can just can not reliably bring up a system today with only half of its tools installed. If we want to hack around the udev issues with /usr, we would just add another "udevadm trigger" after /usr is mounted, and do the entire coldplug again. But that is in no way a professional solution, or anything we should do. Most of the low-level tool maintainers have already given up on the idea of splitting / and /usr, are working on making initramfs solve the problem properly. I wouldn't expect much buy-in from upstream projects for fiddling with booting with a split-off /usr, it just does not make much sense anymore. People who need /usr separate, should focus on an initramfs which is able to do that, and not extend current tools to _try_ to handle it the way we used to do it today. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rob OpenSuSE

19:10

New subject: [opensuse-factory] Re: Some second thoughts on systemd/sysvinit/udev

On 8 July 2011 18:18, Kay Sievers wrote:

...

On Fri, Jul 8, 2011 at 18:43, Dr. Werner Fink wrote:

...
I'd like to do some notes on the topic how become systemd or should I better say udev better integrated in the current system scheme regardless of the used init.

/usr should just be mounted from initramfs. That solves all the problems. The artificial split of / and /usr makes not much sense in today's setups. What / was for UNIX, is the initramfs for Linux.

That's good insight! If there's difficulties mounting /usr from initramfs perhaps it's better to not support seperate / & /usr. The complications of dependency rules in udev etc etc, probably won't be ready with great reliability. Although it would be a wrench to lose "/usr", I think supporting the ro /, brings much more than supporting / & /usr with difficult manoevres; which tend to waste space seperating similar types of system data (bins, libraries & modules). I came across this "history" today "Ken & Dennis introduce UNIX" - http://www.poetv.com/video.php?vid=69235 .. amusing but it' rather shows how times have changed, and perhaps "accidental" tradition needs re-evaualating. If /usr does not have space for contents of /, less /tmp & /var, the installation has problems anyway. With bind mounts, large /srv directories and the like, could stay where they are, or be really /var/srv, with /lib, /bin,/sbin & /etc/ moving into same filesystem as /usr hierarchy. It might be better to use the "Major" version change to check openSUSE 11 installations, before upgrade and require things like seperate /usr to be gone before distribution upgrade. Also anything else, like acls & user_xattr's that might cause problems, to be sorted as well as requirements of software that could be forgotten and cause support issues. Providing a documented procedure (perhaps with simple helper scripts). Those who don't care to follow advice, can accept the broken bluetooth etc, it was easy enough to see what referenced /usr on a box. Regards Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Kay Sievers

9 Jul 9 Jul

18:23

New subject: [opensuse-factory] Re: Some second thoughts on systemd/sysvinit/udev

On Fri, Jul 8, 2011 at 21:10, Rob OpenSuSE wrote:

...

On 8 July 2011 18:18, Kay Sievers wrote:

...
On Fri, Jul 8, 2011 at 18:43, Dr. Werner Fink wrote:

...
I'd like to do some notes on the topic how become systemd or should I better say udev better integrated in the current system scheme regardless of the used init.

/usr should just be mounted from initramfs. That solves all the problems. The artificial split of / and /usr makes not much sense in today's setups. What / was for UNIX, is the initramfs for Linux.

That's good insight! If there's difficulties mounting /usr from initramfs perhaps it's better to not support seperate / & /usr.

Yeah, there is only really the option of the inside-initramfs mount to make everything work properly. We can not recommend running that on todays releases, not in the current, not in past releases. But things that worked in the past for people, should just continue to work as it is. It just might be that more errors are logged during boot because we made tools like udev and systemd to log an error when binaries mentioned in rules files are not available at boot time, we used to suppress these errors.

...

The complications of dependency rules in udev etc etc, probably won't be ready with great reliability.

I don't think there are any bigger changes to expect from people. There in no general support for the / vs. /usr split anymore. Only basic setups, like simple servers without any 'end user' software/hardware works reliably today.

...

Although it would be a wrench to lose "/usr", I think supporting the ro /, brings much more than supporting / & /usr with difficult manoevres; which tend to waste space seperating similar types of system data (bins, libraries & modules). I came across this "history" today "Ken & Dennis introduce UNIX" - http://www.poetv.com/video.php?vid=69235 .. amusing but it' rather shows how times have changed, and perhaps "accidental" tradition needs re-evaualating.

Oh, funny video. :)

...

If /usr does not have space for contents of /, less /tmp & /var, the installation has problems anyway. With bind mounts, large /srv directories and the like, could stay where they are, or be really /var/srv, with /lib, /bin,/sbin & /etc/ moving into same filesystem as /usr hierarchy.

The current idea is not read-only /, but to move _everything_ back to /usr, and have only the compat symlinks in /. /usr would basically be something like /System. /usr would contain allmost all RPM installed content. If people like to split off /usr to mount it read-only or to share it across hosts, they could do that just fine. The / would only contain the host-specific data including /etc, /root, /srv. The new-world-/usr would contain _all_ binaries and not miss half of them laying around on /. The / would be r/w, /usr would be r/o by default. Almost all content of an installed system would be r/o and could be safely shared that way, all host specific data is just r/w without all the silly hacks r/o / requires. Anyway, wherever we will end up with, the / vs. /usr split makes no sense for any reasonable setup. Mounting /usr separate makes a lot of sense in some setups, but the split doesn't make any in today's system architecture.

...

It might be better to use the "Major" version change to check openSUSE 11 installations, before upgrade and require things like seperate /usr to be gone before distribution upgrade. Also anything else, like acls & user_xattr's that might cause problems, to be sorted as well as requirements of software that could be forgotten and cause support issues. Providing a documented procedure (perhaps with simple helper scripts).

Those who don't care to follow advice, can accept the broken bluetooth etc, it was easy enough to see what referenced /usr on a box.

These problems exist for long, even in earlier releases. People who do that should be able to continue to do that. As said, it might just log errors if they install packages using udev and /usr. None of the tool like udev, systemd requires /usr itself, only packages using these services. If we want to fix it properly, we just make the initramfs /usr mount work. In the long run, all tools in / should just move back to /usr where they belong. It offers us more flexibility, better security, and more sane options to run all sorts of custom/specialized setups. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Linda Walsh

11 Jul 11 Jul

02:22

New subject: [opensuse-factory] Re: Some second thoughts on systemd/sysvinit/udev

Kay Sievers wrote:

...

On Fri, Jul 8, 2011 at 21:10, Rob OpenSuSE wrote:

...
On 8 July 2011 18:18, Kay Sievers wrote:

...
...
I'd like to do some notes on the topic how become systemd or should I better say udev better integrated in the current system scheme regardless of the used init. /usr should just be mounted from initramfs. That solves all the

On Fri, Jul 8, 2011 at 18:43, Dr. Werner Fink wrote: problems. The artificial split of / and /usr makes not much sense in today's setups. What / was for UNIX, is the initramfs for Linux. That's good insight! If there's difficulties mounting /usr from initramfs perhaps it's better to not support seperate / & /usr.

...

But things that worked in the past for people, should just continue to work as it is.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bottom line. Agreement! by inference, separate user will still work and ideally, still work w/o ram disk (as my system currently boots). Modern systems disks spin up to speed fast enough (faster with SSD's) to make a RAMDISK an extra-complexity that isn't always needed. But why do I want separate partitions: I have been known to run 'pre-production SW... (GOSH!)....and if anyone here thinks this doesn't apply to them they are in naive, I mean who here, doesn't? As a result, things like the kernel and file systems sometimes crash in inconvenient and bad ways. ***LIKE, in 11.4 ***...last night -- a 'normal' /etc/rc.d/restart. Except that it wasn't...didn't come up like it was supposed to. (I still have NO idea what caused it!) "/var" somehow had gotten corrupted going down and wouldn't mount. Fortunately, damage was *contained* to a small partition of files that didn't even need to be restored. boot-rescue, run xfs-repair, -- back in business. if it was my whole disk -- I might still not be up. But more important is that over the years, I've had various partitions get "hosed" separately. I STRONGLY appreciate the containment of damage I've lost /usr by itself, but was still able to boot to single user at the time (an older suse that had all it's boot stuff in /bin, /lib, /sbin).... I was even able to repair (restore actually) by mounting a /usr partition from a repair DVD!...).... have also lost /home, and data partitions (and root, but never yet 'boot')... ... I mean we are talking maybe once of each of those over the past 10 years. I've almost always been fortunately to have daily backups to recover from (cept when backup drive and a regular drive both went dead in similar time frame....but fortunately even that I had a copy as had upgraded the hard disk recently, and still had a fairly recent copy).... Those are my strongest reasons and feelings for wanting to keep things separated into smaller containers --- with LVM it becomes even more possible since you can dynamically resize partitions after the fact! And even 15-20 year old file systems can expand to fill a larger paritition! So with software become less stable and predictable as it gets more complex, and running downloaded SW with latest features, as well as keeping current on my suse release, having damage containment has been a help -- because damage *will* occur. It's just a matter of how ugly or just time-consuming to recover from it. One of the reasons I went to a RAID system (including for backup) was exactly being able to recover more quickly. With it taking hours to restore 1 large HD (a full speed disk image of 2TB would take over 5 hours) -- more if you you are going through a file system. So it's not about "big iron" or corporate customers....it's about a home user who's grown tired over the years of waiting around spinning thumbs while a system is down, and who's health isn't as great, for who a working computer is important -- and 'downtime' measured in hours gets very unhealthy for me (since I have no one to repair or fix it, but me!)... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Kay Sievers

02:39

New subject: [opensuse-factory] Re: Some second thoughts on systemd/sysvinit/udev

On Mon, Jul 11, 2011 at 04:22, Linda Walsh wrote:

...

Kay Sievers wrote:

...
On Fri, Jul 8, 2011 at 21:10, Rob OpenSuSE wrote:

...
On 8 July 2011 18:18, Kay Sievers wrote:

...
On Fri, Jul 8, 2011 at 18:43, Dr. Werner Fink wrote:

...
I'd like to do some notes on the topic how become systemd or should I better say udev better integrated in the current system scheme regardless of the used init.

/usr should just be mounted from initramfs. That solves all the problems. The artificial split of / and /usr makes not much sense in today's setups. What / was for UNIX, is the initramfs for Linux.

That's good insight! If there's difficulties mounting /usr from initramfs perhaps it's better to not support seperate / & /usr.

...
But things that worked in the past for people, should just continue to work as it is.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bottom line. Agreement! by inference, separate user will still work and ideally, still work w/o ram disk (as my system currently boots).

As said, it probably will, even without initramfs support for mounting /usr. Some things didn't work in the past and more things are likely to break in the future, but there should be no real change. But we just can not really support such setups officially. Supported separate-/usr systems will need initramfs support. Without initramfs it will log errors during bootup, systemd will mark the bootup as 'tainted' and point to this page: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken Nothing really different, besides that the errors where just silently ignored in the past. Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rob OpenSuSE

09:00

New subject: [opensuse-factory] Re: Some second thoughts on systemd/sysvinit/udev

On 11 July 2011 03:39, Kay Sievers wrote:

...

But we just can not really support such setups officially. Supported separate-/usr systems will need initramfs support. Without initramfs it will log errors during bootup, systemd will mark the bootup as 'tainted' and point to this page: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Nothing really different, besides that the errors where just silently ignored in the past.

Just in case initramfs support doesn't work out, I'll knock off a prototype script that deduces a list of common broken things, with idea to report a summary via Mail whenever the system "grows" a new broken feature via daily & after boot up. Errors can surely be reduced by uninstalling broken things, like bluetooth which are probably unwanted on a seperate /usr system anyway, so could be made "Taboo" by the admin. The idea would be to fill the information vacuum, rather than have ppl Googling "systemd broken /usr" etc and getting frustrated and upset with 12.1 & changes to init(8), and falling for the FUD. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

4681

Age (days ago)

4684

Last active (days ago)

List overview

Download

6 comments

4 participants

participants (4)

Dr. Werner Fink
Kay Sievers
Linda Walsh
Rob OpenSuSE