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 DF570138CD0 for ; Wed, 20 May 2015 08:01:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A3D02E08BF; Wed, 20 May 2015 08:01:23 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C7215E088F for ; Wed, 20 May 2015 08:01:22 +0000 (UTC) Received: from marcec ([93.181.44.4]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MFcg9-1YyV3E0g6P-00EeKp for ; Wed, 20 May 2015 10:01:21 +0200 Date: Wed, 20 May 2015 10:01:13 +0200 From: Marc Joliet To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Systemd migration: opinion and questions Message-ID: <20150520100113.1c44169f@marcec> In-Reply-To: <20150224211545.50495cc0@marcec.fritz.box> References: <20150224211545.50495cc0@marcec.fritz.box> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/ApvsxNru4IsRi5j7/tXtq2l"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:TWHbxIfEM1M5xXE7dXh1yqHYUzgG97ZKuEtEJDKj9UKnFVP50nM X7zzSUlv1/tLuQek/3GdP/cKmuw4R4lY3kR2D1hNHIj8tJrJILRPcL+JqBZ0/Gi2dowT/tK saOREP8xqBI5uzYt1TaO+CmPOa4I+g2IG72jQc3izwu11Q9qLIwNXG5mfBlKTkBD5Uy1hRr 4u2kwSnohRt+DpHBkdZmg== X-UI-Out-Filterresults: notjunk:1; X-Archives-Salt: bc2d8331-2757-4a54-9f37-8243482cadc5 X-Archives-Hash: 9e84617be77428668b0d72eddb33ddb0 --Sig_/ApvsxNru4IsRi5j7/tXtq2l Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, it's been a while, but there are a few things to report. So here it goes: Am Tue, 24 Feb 2015 21:15:45 +0100 schrieb Marc Joliet : [...] > =3D=3D Network migration on my desktop =3D=3D >=20 > My desktop has a somewhat more complicated network setup than the laptop = (which > uses NetworkManager). The wan0 network device is no problem, but I also = have a > bridge with one physical device connected to it, and one dummy device. >=20 > Thus, I had to migrate my netifrc based configuration. Due to word of mo= uth, I > decided on netctl. I originally ignored systemd-networkd because I keep > hearing that it's only for simple networks, but after looking at the man = page > it appears that it can do (almost) everything that I needed it to, althou= gh I'm > not sure about dummy device support. I need that for MATLAB, which stupi= dly > requires the presence of an interface named eth0, whose MAC address it ve= rifies > during its licence check. This became a problem after renaming my network > devices following the news entry 2013-03-29-udev-upgrade ("Upgrading udev= to > version >=3D200"). >=20 > What surprised me was that netifrc doesn't seem to integrate dummy devices > properly, i.e., it doesn't seem to be possible to rename them in > /etc/conf.d/net directly. I implemented that via an appropriate call to = ip in > an /etc/local.d file, and had "net.eth0" depend on "local". So /etc/conf= .d/net > looked like this: >=20 > config_eth0=3D"172.16.1.1/24" > mac_eth0=3D"00:18:f3:97:17:72" > rc_net_eth0_provide=3D"!net" > rc_net_eth0_need=3D"local" >=20 > And the local.d script executed >=20 > ip link set dev dummy0 name eth0 >=20 > In comparison, the netctl configuration has everything in one place: >=20 > # cat /etc/netctl/dummy > Description=3D'A dummy interface (for MATLAB)' > Interface=3Deth0 > Connection=3Ddummy > IP=3Dstatic > Address=3D172.16.1.1 > IPCustom=3D( 'link set dev eth0 address 00:18:f3:97:17:72' ) >=20 > It also takes care of loading the dummy kernel module, so I don't don't n= eed an > /etc/modules-load.d/ entry, whereas with netifrc/OpenRC I needed to load = it > manually via /etc/conf./modules (though maybe that has changed?). A few days ago I finally got around to giving systemd-networkd a whirl, as I said I would in the sub-thread started by Rich. It turns out that it fulfi= ls the needs of my computers just fine, and has (together with systemd-resolve= d) fully replaced netctl. The only thing I'm not sure of is how extensive IPv6 support is. The man page suggests that only DHCPv6 is supported, but not stateless configuration. Not that my LAN has IPv6, but it'd be nice to know how future proof it is. (This was made a tiny bit easier since I recently got rid of most of the se= rver functionality of my desktop, i.e., it has stopped acting as a router. So I= 'm only using the built-in ethernet port now, and will remove the other soon.) I also switched the laptop over, which was using NetworkManager, but now us= es wpa_supplicant directly with systemd-networkd on top (basically swapping out one upper layer for another). It required a small bit of configuration so = that wpa_gui had a socket to connect to, and so that it could save the configura= tion file, but that was just two additional lines (along with two minimal *.netw= ork files, although now that I think about it I'm not even sure whether they're needed). It appears to work as fine as it did when running NetworkManager, = so I'm happy to be rid of NM. One thing I noticed about systemd-networkd is that it, too, follows the the= me of being designed around dynamic changes, namely network/device addition/removal. This becomes apparent when you learn that you can use wi= ld cards to match devices. For example, when using the new udev network device naming scheme (aka "predictable names"), "en*" matches all ethernet ports a= nd "wl*" matches all wireless ports. So that's interesting, I think, and I'm curious to see how systemd-networkd will evolve. I would now like to take a moment to mourn the unmerging of dhcpcd, which fulfilled its task of configuring the IP address (and other associated task= s) of my computers marvellously for over 8 years (first emerged on: Wed Jan 10 14:44:09 2007). Done? Great, now let's celebrate the unmerging of NetworkManager :-D . *phweeee* *balloon popping* *other generic party sounds* > =3D=3D Stuff I liked =3D=3D >=20 [...] > =3D=3D Questions =3D=3D=3D >=20 > =3D=3D=3D ACPID: needed or not? =3D=3D=3D >=20 > Does acpid provide anything that systemd does not, and if so, what kind of > "conflicts" might I see? The Gentoo Wiki page says that acpid is likely = not > needed. >=20 > FWIW, I already unmerged it and have not noticed any missing functionalit= y, > even after over a week of regular usage. So I'm tending towards "no, not > needed". I have not noticed anything amiss in the many months I have been using my systems without acpid. So my "tendency" has morphed into "assuredness". > =3D=3D=3D Timers =3D=3D=3D >=20 > Can a systemd timer depend on a mount point such that it waits until the = mount > point exists before running? Or will it fail after a timeout? I want to > research this myself, but haven't gotten around to it yet. >=20 > The problem I have is that my external HDD does not come up properly on c= old > boot, so that I have to unplug it and plug it back in in order for the ke= rnel > to fully initialise it and for it to mount, which is problematic for my b= ackup > fcron jobs, since they have &bootrun set. This means that the backup scri= pt > will fail, unless I'm a) fast enough at re-plugging the HDD, and b) fast = enough > at logging in (so that my automounter mounts the HDD. I will then have to > manually re-run it (i.e., fcrondyn -x "run ") or wait for the next ti= me > it's supposed to run. >=20 > Naturally, I would like a more robust system than that, and hope that sys= temd > timers can make my life easier here. I ended up asking specifically about the HDD problem on gentoo-user, and was redirected to the linux-usb ML. I already mentioned the final diagnosis on gentoo-user, but haven't repeated it here yet: "After diagnosing the problem with the help of Alan Stern and Matthew Dharm, the conclusion was that the sector size translation must be triggered by some interaction between the drive and the BIOS. The test= I performed to determine this was: - unplug the drive, - turn on the computer, - plug the drive in once GRUB has started, and - boot the kernel, after which the drive worked fine. So this does not seem to be anything that can be fixed in the kernel. Perhaps if I had an EFI compatible mainboard, I wouldn't be seeing this problem, but I don't, so I can't e= ven try it out :-/ ." So, as sad as it is, my "solution" is to follow those four basic steps when= ever I turn my computer on, and then I don't get any problems. [...] > =3D=3D=3D Suspend on the desktop =3D=3D=3D >=20 > Like I mentioned above, my Desktop can *almost* suspend reliably, after t= rying > it out once every year or two (it's over 8 years old). Mostly it would j= ust > not wake back up. The latest status (before systemd) was that the kernel > crashed after waking up (but I think that was a known bug that was fixed = in the > meantime). >=20 > Now with systemd, it wakes back up properly, but one of the soundcard dri= vers > (ice1724) is apparently unreliable, so that sound stops working after wak= eup. > Plus, access to the soundcard was blocked by rtkit. I believe what one w= ould > normally do is unload the module before suspending, but the only way I co= uld > find to tell systemd to do that requires creating a file in /usr (as done= here, > for example: http://forums.fedoraforum.org/showthread.php?t=3D294065). I= s there > a better way? Well, I ended up doing this, and suspend/resume *almost* works, but still n= ot quite: I couldn't access my USB3 HDD as a regular user anymore after resume= , and it seems that my desktop shuts itself off after a while. Although maybe th= at has to do with the empty CMOS battery? Or a failed hibernation attempt? Ju= st some random ideas. Again, I'm not pushing this, I'm just trying it out every now and then. My main motivation here is to waste as little electricity as is possible with = this old desktop. What I would like to be able to do is to pause whatever I'm doing, suspend, do something else for a while, and then resume, *without* having to restart applications. (Even better would be to buy a new, more e= nergy efficient computer, but I cannot afford that right now.) @Duncan: it seems to me that the btrfs RAID has yet to be a problem during resume (doesn't mean it won't be, but that's what I've seen so far). [...] Greetings --=20 Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup --Sig_/ApvsxNru4IsRi5j7/tXtq2l Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVXD9OAAoJEL/Q5oYsiHj0rusP/iZqt23iqQokastKbuQbofAP kL6BzIJ2sk7lGpQwdDBbJddmYqYmYHxAgNbzLG8g1fHQ/94PlpHgKYGPQKDfUusL 8jUYig8wo7iJxKmgFePqwMGHghtZs6SnUaeRSJTjiiJqGrAou+Wr1pwj53viI3jx PDYl5lNa5xXrisJ+Dv/+IzOBSkDtPtGwQCW2ZZdsDBe0lbsOWo/Y3azetcBcP05K 4sBV+k8f8yWCCYegpdBs1v5/IKMJK/PeGeUc+59XurYiOdzmBKJKqrSeKbbxpxtF 76UF7YwGwwY1vlEF4CQXhr+hZ9j5uTOSEF/xnBUHwLHgBY5rgomG4pNp2brjCIbD Mc/DTQP7z0GN9KUmvgsjHj/y73hltaxGfFNqKCp7RdBkyhjpsz0kDWqSvzMOkJTb 9KZy3RStGhG76xCT0l5cM6guhXMFV7vwC89Svslb6Q2XYIVTEhFuBEmOjnfOw2RF hVc/be1WR1w0iVxM37cTOR9YGXe2uLCUKT5+Y11Bdn0CLDIHcgr+DmJFJbKK1JYn JEaRtChknFk4GCBNBs38y8WjFHHfUkLQPPg5/2foYXE+l8MoLcPN/DhY7DHsX5ym vDODWh49bECYirfiHzytiWM97061NlrnuGQwbqN9W5Lu6QU254h6Tl8MYKGW07cK zKgrRqVbaLoZmwXXHNBA =XCnB -----END PGP SIGNATURE----- --Sig_/ApvsxNru4IsRi5j7/tXtq2l--