From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E5723138E66 for ; Sun, 23 Feb 2014 18:01:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 80431E0A5E; Sun, 23 Feb 2014 18:01:39 +0000 (UTC) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1106DE094F for ; Sun, 23 Feb 2014 18:01:37 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id gl10so1531436lab.28 for ; Sun, 23 Feb 2014 10:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=pq26/jq7wmNX5uP7AH2TqlAgfEG+mWqgjpUFA6KVmZ8=; b=dt1Qm+KsRRq8o46m7Jznh8Rjn65yH9V8tE37OElDdJqluq7hPnNJnWdQt32//VdUS8 zi9b4I+62F/pavb8DFjF/E/sqB62VIdNI++FNKd9cceWg3PeEFAQaqvxslniqvQXwDs+ 7CLI0Hi47SyJieMK6Qy0I4ZmGrzPXHAj/LnvzoUDp5bmBiyAhWMVWKttek4ABez+COkR ynG3bDoXQeJYsGIG/S2PlElCgSA7kKeSnO3qzceMR+jMjGapcmPM1Zn2KyJnSWVebM1F 17AXxxSAxc63VHxtrarFpey0V/7xqpxSSHqJg02pSovqT0eV6qhQTbSZqSgYujzQZejx 8zxA== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.152.190.69 with SMTP id go5mr9717559lac.79.1393178496375; Sun, 23 Feb 2014 10:01:36 -0800 (PST) Received: by 10.114.170.67 with HTTP; Sun, 23 Feb 2014 10:01:36 -0800 (PST) In-Reply-To: <2cdf6b0bc8fddc60282b693e360bb2d3.squirrel@192.168.151.11> References: <07d8cf1108b4a5d52cdf81cb51db1887.squirrel@192.168.151.11> <2cdf6b0bc8fddc60282b693e360bb2d3.squirrel@192.168.151.11> Date: Sun, 23 Feb 2014 12:01:36 -0600 Message-ID: Subject: Re: [gentoo-user] technical review of systemd From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: ec6dff1b-d04f-4683-bc39-fd7c176a89eb X-Archives-Hash: c694cdc6288486d41a5cb376ae4587d9 On Sun, Feb 23, 2014 at 5:06 AM, wrote: [ snip ] >> Corrupt filesystems or logs? > > logs. currently if fsck runs anywhere on boot i get zero log about what > was done, so i prefer to do this on a running system. / is obviously > special, so this is a pro that fsck is logged, but of course if / has > issue i'm not sure what systemd would do other than drop you to emergency Mmmmh; centurion ~ # journalctl /usr/lib/systemd/systemd-fsck -b -- Logs begin at Tue 2013-09-24 13:39:03 CDT, end at Sun 2014-02-23 11:37:30 CST. -- Feb 18 23:49:16 centurion systemd-fsck[1047]: Centurion: clean, 1054301/3389904 files, 10171017/13533184 blocks Feb 18 23:49:17 centurion systemd-fsck[1531]: Data: clean, 308819/30531584 files, 105744823/122096390 blocks Feb 18 23:49:17 centurion systemd-fsck[1568]: Files: clean, 509045/9773056 files, 20704341/39072470 blocks I mean; my file systems were clean, but if some output was generated, it would be there. I don't think I understand what do you mean by "zero log"? >> It's been a while since I've read the source code, but it isn't in >> src/activate/activate.c[3]? > > ok so it does look like it would have a systemd-activate process for each > socket being activated on behalf of a service. that makes me feel better > than one process doing all of them. perhaps someone using service > activation can do a 'ps aux' to confirm? It is one instance of systemd-activate for each socket; I don't have any socket activated service waiting for the first connection at this moment, but it's obvious from the source code, I believe. It waits in a loop for a connection, if specified it accepts it, and then launches the service. [ snip ] >>> 7.chroots no longer work. forcing use of nspawn to ensure environment >>> set >>> up correctly. >> >> I'm sorry, chroot doesn't work? First time I heard about it. While >> systemd-nspawn is a gazillion times better than a simple chroot, you >> *can* still use a chroot if you so desire. Where did you found that >> chroot doesn't works? > > agreed nspawn is better due to the filesystem namespaces. chroot itself > works, but the environment doesn't so it is effectively broken. full > explaination from lennart's blog [5] This is quite old so i don't know i= f > this has been fixed, seems unlikely based on what he described Oh, I see. Yeah; you cannot longer start a service inside a chroot; but in the blog post you cited [5], there is a recipe to launch a chroot inside a unit file, working around this limitation. And, if you are running systemd and want jailed services, systemd-nspawn works so much better. For non service-start-up-and-management stuff (for example, boot from a non-systemd LiveCD and emerge something you forgot that you need), chroot still works. So, there is a workaround if you want to keep using chroot for jailed services, and there's a better alternative. [ snip ] >> networkd (again, netctl is the command-line front-end) is not for >> enterprise networks; on the contrary, is for the trivial cases. For >> example, in a little web server I administer I have: >> >> $ cat /etc/systemd/system/network.service >> [Unit] >> Description=3DStatic network service >> After=3Dlocal-fs.target >> Before=3Dnetwork.target >> Documentation=3Dman:ifconfig(8) >> Documentation=3Dman:route(8) >> >> [Service] >> Type=3Doneshot >> RemainAfterExit=3Dyes >> ExecStart=3D/bin/ifconfig enp2s12 192.168.1.2 broadcast 192.168.1.255 >> netmask 255.255.255.0 up >> ExecStart=3D/bin/route add default gw 192.168.1.1 enp2s12 >> >> [Install] >> WantedBy=3Dmulti-user.target >> >> (Yeah, I know, I should switch to ip, I'm sorry, I haven't had the time >> yet). >> >> I'm going to get rid of this trivial network.service unit file when >> 209 (or better 210) hits Gentoo. Cases like this are the use-cases for >> networkd. > > what i don't understand is if you look at how openRC does it, it only > really cares about up/down events and the /etc/conf.d/net is very > comprehensive, in part because it passes everything to iproute2 to handle= , > the only thing i can't do without an additional shell script is tc qdiscs= . > i don't need or want a network manager, just need something that applies > confs on startup / stop of interfaces. I'm a little surprised that there > isn't an iproute2 .service file > > reading through your example, in fact this is preferrable to me than usin= g > a network manager but using iproute2. I would rather you keep this > example in, and have this shown on the wiki or somewhere as this neatly > resolves my network concern. Mmmh. Maybe I wasn't clear; in your case, it seems that iproute2+OpenRC *is* your network manager. Perhaps at some point networkd will gain the ability to use iproute2 (or even absorb it), but right now is only for tiny little setups. >>> 10.strange gotchas: /tmp being tmpfs using up to 50% ram. unless >>> mounted >>> in fstab >> >> That doesn't have nothing to do with systemd: from man:mount(8): >> >> """ >> Mount options for tmpfs >> size=3Dnbytes >> Override default maximum size of the filesystem. >> The size is given in bytes, and rounded up to entire pages. The >> default is half of the memory. The size parameter also >> accepts a suffix % to limit this tmpfs instance to that >> percentage of your physical RAM: the default, when neither size nor >> nr_blocks is specified, is size=3D50% >> """ >> >> systemd just mounts the tmpfs; the default *is* 50%. >> > > I was just highlighting because someone could be putting systemd on > embedded and wondering why memory usage increased over time. no issue if > you have 8GB+, but if you have 256MB is an issue, and if you have less yo= u > are counting every byte. Yeah, but again, it has nothing to do with systemd: the default *is* 50% for tmpfs'. Embedded guys need to know this independently of if they use systemd or not. [ snip ] >>> 12.transitions into systemd are non-trivial. >> >> No, they are not. > > i'm not talkign about new installs. [ sniped rest with which I concur ] I'm sorry, I think I expressed myself incorrectly. When you said "transitions into systemd are non-trivial", I answered "No, they are not", meaning "No, they are not trivial". In other words, I agree with you. Sorry for the confusion. > I think actually that i would just create an iproute2 service file for > each device. so have no network manager at all and have the service file > start after the interface. iproute2.enp2s0.service etc > in there i would have "exec=3D/sbin/ip rule add" etc > i'd also have "exec=3D/sbin/ip addr add" etc Having a "network manager" doesn't necessarily means having a big monolithic thing that sets up your network. If you use some scripts+conf with iproute2 to set up your network, then *that's* your network manager. The point of networkd (if I understand correctly), is that if you *need* iproute2 (I don't have it installed in any of my machines), or highly dynamic non-trivial network configurations, then networkd will not be enough. And, by the way, someone make me notice that netctl is an Arch'ism, and that the command-line front-end for networkd is actually networkctl. >>> As Gentoo is a meta-distro (says Larry the Cow >>> http://www.gentoo.org/main/en/about.xml) and a rolling release distro, >>> I'm >>> all for choice, but I would sincerely hope that unlike all of the other >>> distributions from Arch to Ubuntu systemd is not adopted by default as >>> udev and baselayout transitions were bad enough. >> >> As a systemd supporter, at some point in the long, long future, I >> would be more than happy if systemd was added to the handbook as >> "secondary supported init system" in its own section. I'm completely >> fine with OpenRC as the default. > > that would be the ideal way forwards Glad to see you don't disapprove. >> Also (and I plan to work on this in the future), I would like to have >> LiveCDs and stages with systemd installed (not necessarily hosted in >> the Gentoo infrastructure), because is works really nicely install >> Gentoo from systemd-nspawn instead of a chroot. > > actually I agree - even if it is only to get journactl on a bootable cd! :D >> Someone would have to do that, though; I hope to help with that in the >> future. > > to end on a merry note [6] and kind of why i wrote this Thanks for sharing. Regards. >>> I will however be installing a systemd desktop in a vm to play properly= . >>> YMMV >> >> Thanks again for a succinct, impartial and objective analysis of systemd= . > > very welcome, hope this helps others > >> Regards. >> >> [1] >> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/openssh= /files/sshd.service?view=3Dmarkup >> [2] >> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/openssh= /files/sshd.socket?view=3Dmarkup >> [3] http://cgit.freedesktop.org/systemd/systemd/tree/src/activate [ snip sig ] > [4] http://wiki.gentoo.org/wiki/Systemd > [5] http://0pointer.de/blog/projects/changing-roots.html > [6] > http://allpoetry.com/poem/9326367-Everybody--Anybody--Somebody--Nobody-an= d-Someone-Else-by-YoungDumbCrazy --=20 Canek Pel=C3=A1ez Vald=C3=A9s Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n Universidad Nacional Aut=C3=B3noma de M=C3=A9xico