[systemd-devel] One of my fundamental problems with systemd...

[Michael H. Warfield]

Lennart,

I'm going to quickly top post here so forgive me for being rude.

Serge and I worked out some patches that seem to address the devtmpfs
issues nicely.  Still got a few oddities to iron out but the big
fundamental one got fixed and is working.  Many thanks for that.

The problem with error messages and stderr never did get resolved.  The
error output from the script did not show up on stderr nor in the
journal but showed up with the command was issued to manually restart
the network.  That problem seems to have evaporated once the devtmpfs
problem was resolved and may well have been related.

The console vs gettys on ttys remains problematical but far less severe
now that we can get the network started normally.  If there is some way
to enable those, that would help as it would make our lxc-console
program useful again in terms of when you need more than one console
when the network is non-functional or an access service (sshd) fails.

I have started experimenting with 195 from Fedora Rawhide, Fedora 17 is
at 44 with a whole lotta back commits, and haven't tried the git version
as yet.  I do have 44 working as of right now in a Fedora 17 container,
so that's a really good thing as we do not want to have to customize any
other packages to get LXC to work if at all possible.

Serge has some patches he's going to work into the code tree and I'm
continuing to test and debug at this point, but we have made some
serious progress over the last week.

Thank you very much!

Regards,
Mike

On Tue, 2012-10-30 at 03:08 +0100, Lennart Poettering wrote:
> On Fri, 26.10.12 18:39, Michael H. Warfield (mhw at WittsEnd.com) wrote:
> 
> > My most fundamental problem with systemd is its insistence in hiding and
> > obfuscating errors in ways that makes debugging almost impossible.
> > Almost every upgrade problem I've had in Fedora has been related to
> > systemd's failure to provide comprehendable error messages to things
> > like errors in fstab (#1 fsck up).
> 
> We have been trying hard to make the boot of systemd actually as
> understandable as possible, and are still working on that. The main
> reason why the journal exists is that we can collect stdout/stderr of
> all services cleanly.
> 
> We also are working hard on making system boot cleanly in containers. In
> fact, the systemd test system will create an OS image that we boot up
> both in a KVM and a linux container, and verify that it boots up
> cleanly.
> 
> Now, it's of course disappointing when that work didn't really bcome
> visible to you yet. But a couple of notes on that:
> 
> a) of course, the more recent versions of systemd will have the most
> complete support for these things, so, please before reporting issues,
> check if things are fixed already, there's a very good chance they are.
> 
> b) For containers we focus on systemd-nspawn and libvirt-lxc as
> container managers (which is entirely different from LXC, actually, and
> shares no code, just the name!), but not 'classic' LXC. The non-libvirt
> LXC tool set is a very low-level tool-set that gives you plenty of rope
> to hang yourself with, you can use it to set up containers, but you need
> to know a lot of things for that, about low-level system stuff in
> systemd and elsewhere. We tried to remove a lot of complexity in this
> area, which is why we came up with the container iface doc i already
> linked. The requirements are implemented implicitly in nspawn and
> libvirt-lxc, but if you use raw LXC then you have to do this yourself,
> which is why we documented that stuff.
> 
> c) LXC made a couple of questionnable choices that are not compatible
> with the way systemd expects things. For example, the attempt of
> redirecting for /dev/tty1 (and friends), and /dev/console is a bit
> mislead if I may say so. The latter is problematic, since /dev/tty1 is
> just one interface to a kernel object that is visible in other ways too,
> and used that way, for example in /sys, /dev/vcs1, and so on. Just
> redirecting one part of the iface will break stuff that tries to do more
> than just the most basic things on TTYs, which systemd actually tries to
> do. It also has the effect that things like $TERM are incorrectly
> initialized. Now, the existing guidelines for LXC ignore these issues
> and sysvinit due to its static design works well enough on that, but
> systemd doesn't. That doesn't mean LXC was generally incompatible with
> systemd, but you probably need to do more stuff manually, that will work
> out-of-the-box with the other container managers.
> 
> Anyway, please have a look at the newer versions of systemd, and
> possibly nspawn or libvirt-lxc. Things might already work much better if
> you use those.
> 
> Lennart
> 
> -- 
> Lennart Poettering - Red Hat, Inc.
> 

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20121029/f1b75b20/attachment.pgp>