Brian K. White said the following on 11/11/2011 01:27 PM:
Ultimately I guess the ideal would be for one or more scripts to be written to optionally parse inittab and sysv init scripts if they exists to make systemd read sysv init files as an optional compatibility bridging part of it's processing.
On day there will be a GUI like YAST for all this ... Er ... http://packages.debian.org/search?keywords=systemd-gui As it is, some of the /etc/init.d on a SystemD system are 'wrappers'. Its early days and the answer is 'some'
systemd appears perfectly configurable and customizable, at least or more than sysv init, so things like after.local and pretty much any desired action look pretty straight forward to replicate, merely the names and places of scripts and the methods to specify dependencies & order of operations are different, but no harder.
Its bloody wonderful! The old /etc/init.d/rc5.d/ just executed in sequence. "damn the torpedoes and full steam ahead' mode. I've had many problems with that and had to invent kludges to achieve 'wait for' and as a result slowed down booting. My Fedora-15 system boots so fast - and shuts-down fast as well. Forget sleep mode!
The difficulties I see are all in breaking so much existing system integration and assumptions by existing software.
There is that. Some of it good, some bad. I found the auto-mounter still works, but migrating it into /etc/fstab with entries like server:/home/anton/Media /mnt/server/Media nfs \ noauto,comment=systemd.automount 0 0 Make is much more manageable. I suppose the autofs files make sense if you have 'delegated' system admin and while the files are owned by root they are editable by the 'automountsysadmin' group. There might be better ways to delegate, though :-)
The differences are not that baffling or hard to adapt to, taken individually, but the fact that it has been sysv init forever, since before even linux existed,
Yes, well, before that there was other ways and the BSD people still have some odd ways.. and if you are administering a mixed environment you may have to learn them all, so this is just another.
In my case I have to deal with drivers and proprietary daemons [snip] Unless systemd can seamlessly support sysv init files, it will simply break ALL of those. requiring me, and every other user using products like these, to hand craft their own replacements for the vendor supplied init scripts, and manually fix the supplied installers, where possible, or figure out various ways to fake out the installers so that they think they installed onto a system that's laid out the way they expect, then go rearrange the stuff that got installed after the fact to work on systemd.
You have to deal with a lot more than I do, but my experience with the ones I deal with (disk and multiports) is that the drivers have dependencies. Things have to be set up before; precursors. I've met some deadly-embrace situations and had to use tricks to defer initialization or shut-down sequences and 'try again later'. I'm fighting this art the moment with a drive controller under Mandriva which crashes the system if you unmount certain volumes. It means that automatic shut-down crashes and hangs and requires a FSCK ALWAYS on the next restart. Manual unmounting - in the right sequence, which is not the sequence the automatic shut-down wants - gets around this. BAH! -- I have never made but one prayer to God, a very short one: "O Lord, make my enemies ridiculous." And God granted it. --Voltaire -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org