From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 8080D139083 for ; Fri, 15 Dec 2017 01:16:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 72020E1005; Fri, 15 Dec 2017 01:16:49 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9AADEE0F15 for ; Fri, 15 Dec 2017 01:16:48 +0000 (UTC) Received: from thetick.localnet ([93.181.44.247]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M7pku-1fCH5Q0foG-00vQSm for ; Fri, 15 Dec 2017 02:16:36 +0100 From: Marc Joliet To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Is gnome becoming obligatory? Date: Fri, 15 Dec 2017 02:16:30 +0100 Message-ID: <2040723.mP6naBNKoA@thetick> In-Reply-To: <20171214155259.fbsblxsmkrsem42d@matica.foolinux.mooo.com> References: <6582741.F9gJHCEsXr@dell_xps> <3983017.G5TYQ15G4j@thetick> <20171214155259.fbsblxsmkrsem42d@matica.foolinux.mooo.com> 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 Content-Type: multipart/signed; boundary="nextPart5201580.Wz15M2GXV4"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:U93MDN1bKea/T7OB38UC8Z1SWKH9vfeD0g4YLLt0rBFCV+SQ76y PDx4pxC/YPXePjb+qyj/9vruFCCRU+IJ1bHWdbr5CQFXjS/G1SQluJxsLwtR+jXD25UdXYi lPwnCPJbP6PbPY/+RUCSSrJIbXMvPqVqNAlA+inGe62FqxNAiaDqG9fk5MhGEHBljRp6oi7 8davs8FpV67Jv+jywZpKw== X-UI-Out-Filterresults: notjunk:1;V01:K0:AU/d+h9ng0k=:e5IYfuclucNjvD2qEgUwX+ zYjoBQWwt5pzzxQKuqoueKYQua9MtukHlYMDZ5hD/w0sWSlm5xfY6TIe2iIzHOgrboSgJIwK9 uls6DvqwS8vQKNH1EFqvavpLvW0tkXqOVmfYEtQg+gKEaeulzjH5s3vC4B1YG9uTuRa64Zg6K Lt6osC6HUIQyzp2iBPU8I48BrZ+NqqJs5Jx8NKBLj7pYcvBJ1WWsK/E0rMAdWRbHse7H7W4rG 9H4ejtV079tPoDJjtImR6aQpJ8nnORD0nLqHXlj7i3tq3+5s7HWFVd/TWyWqHOOZP7SwHx8ll gRPqWFyUNJSTcQ80ykUaDjgQjhcro7c8KE48+BO7w4eAndrD9J7g6yhrLSe8dUXt3wt204UYD wSn29/E+oJTNELFjDEdN1jmQpQLLYyY3E/rL0Y2HWvTzzvGw1T3hCELxY8dpor16s0t+fWumT AQgfbrsQ771palmo2CCaR8SyQdjrETQLOS6mBvlUN+r+RTZkxQytDhXMG8BUbo4n+LFuibw8X WV2hULLdAEz0zy4R+8hQvepjmp1PR8zL+PZsgvoiBxx5QuXmHqpmzIWxKExaWAWiOw7v3nNO9 Hyi8VLW+7HfWTkzsTvOg2vNLrbFBzFdzhl46bUHmIwO9VUYzQ6Eo/n0arQhMfgKjZFUUHB45U H+43IR26cNMFmZeb1jdSnGvhnVPVPu0N/kGhDdF2i4TXpu/rB5xqv+29UOEmDbYrfZ71Wk9Qj v4j5y1Tx9RyTH5LlbtzBWbCmfjp331dYFIbWMP4sO9PIWjVnfKJ+GMFE19f1DkAR68Br4O+aE go5X1VCFK8G6CHxwJkGg44cOjZu5w== X-Archives-Salt: a0af08a7-ca01-4dcc-9d57-918eac066986 X-Archives-Hash: a64d23a88e6c822ea964e464734d0611 --nextPart5201580.Wz15M2GXV4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Am Donnerstag, 14. Dezember 2017, 16:52:59 CET schrieb Ian Zimmerman: > On 2017-12-14 11:57, Marc Joliet wrote: > > I could list specific features of systemd that I like and make use of > > (such as socket activation, autofs integration, user units, nspawn, or > > the journal), but thinking about it, it's a "more than the sum of its > > parts" kind of deal. Managing a system with systemd is just overall > > pleasant for me. >=20 > I am probably not the only one who would still dearly like such a > detailed list, from someone I don't see as biased to start with. I > understand this is a drain on your time, so I'll understand if you > decline. I don't mind per se, but whether I'm inclined to do so depends on the attit= ude of who's asking. If I'm asked politely the way you did then I don't mi= nd at all, in fact it can be quite pleasant :) (and it also serves to refre= sh my memory). Before I begin, to avoid making this sound all rainbows and glitter, I will= mention one thing that annoys me about systemd: regressions. None of the= m have been horrible, and I think I was only ever hit by 2 or 3 over the co= urse of by now several years, but they're still annoying. The one I'm curr= ently waiting on is the systemd-run bug when both cgroup V1 and V2 trees ar= e mounted. I could work around it (by deactivating cgroup V2 support or so= me such), but I don't miss systemd-run so much that I could be bothered to.= Regardless, I wish upstream would handle them better. Also, this is just my perspective as a hobbyist (although I've used systemd= in a professional context). I could recommend some presentations that pro= vide a different perspective (e.g., by a company that uses systemd in IP ca= meras, where the cgroups based resource management features of systemd came= in very handy). There's also a presentation by Klaus Knopper of Knoppix f= ame that is overall more negative, but still mostly fair -- though IMHO not= completely -- and as I recall one of the better criticisms I've seen. His= perspective is that of somebody trying to provide a Linux OS for computers= destined for poorer countries, where he has to deal with less capable hard= ware (i.e., no SSDs, booting from CD/DVD). (Also also, sorry in advance for the wall of text, this kind of, uh, spun o= ut of control. Sorry also to Ian and Peter for continuing to feed the mons= ter thread ;-) .) Alright, so here's what I can think of now, starting off with what I listed= above and then continuing with anything else I can remember. This include= s more or less verbose descriptions of what the features bring to the table= , including specifically how they help *me*. 1.) Socket activation sounds like a detail, but it has several positive sid= e effects. It can make dependency specifications unnecessary, thus making = unit files simpler, and it increases the number of services that can start = in parallel. It also enables on-demand services =C3=A1 la (x)inetd, only g= eneralised for all system services (I use SSH this way by only enabling the= socket unit). You can't use systemd without using this feature, something= 's bound to use it. This is the main reason systemd can boot so fast (on flash storage, at leas= t). That may not be important to some people, but it is to me (and embedde= d projects). 2.) Autofs integration via automount units allows dynamic mounting (and opt= ionally unmounting) of file systems, which I use on my desktop to asynchron= ously mount my data dump (a 2x1TB btrfs RAID1). To be honest, I mostly did= this to speed up boot time (I think I mention timings in the Email thread = I referenced), but it also makes boot-up finish independent of mount failur= es. On my home server (an old Mac Mini) I use it for a USB drive for the s= ame reasons (although boot time isn't so important there). [ Just to be clear: autofs is a Linux kernel feature, systemd just exposes = it in an easy to use way. That is, BTW, a theme with systemd. ] 3.) Personally I find user units (systemd units that run as your user) supe= r practical. There is a system location for them, but you can place your o= wn in your home directory under ~/.config/systemd/user/ and have them start= when you log in. If you configure your user session -- which is basically= a systemd instance running as your user -- as "lingering", you can have pe= rsistent user services that run as long as your computer is on (strictly sp= eaking, for as long as your user session is active). For example, my deskt= op looks like this: > % systemctl --user list-units -t service -t timer -a > UNIT LOAD ACTIVE SUB DESCRIPTION = =20 > ctags.service loaded inactive dead Regenerate ctags f= iles =20 > gpg-agent.service loaded active running Start gpg-agent (w= ith SSH support) =20 > mpd.service loaded active running Music Player Daemo= n =20 > newsboat.service loaded inactive dead Run newsboat -x re= load =20 > =E2=97=8F syncthing-inotify.service not-found inactive dead syncthing-= inotify.service =20 > syncthing.service loaded active running Syncthing - Open S= ource Continuous File Synchronization > ctags.timer loaded active waiting Regenerate ctags f= iles (timer) =20 > newsboat.timer loaded active waiting Run newsboat -x re= load (timer) =20 > > LOAD =3D Reflects whether the unit definition was properly loaded. > ACTIVE =3D The high-level unit activation state, i.e. generalization of S= UB. > SUB =3D The low-level unit activation state, values depend on unit typ= e. > > 8 loaded units listed. > To show all installed unit files use 'systemctl list-unit-files'. So I run MPD, gpg-agent, and syncthing continuously, while ctags and newsbo= at are executed on a schedule via timers (a cron-like feature, see point 6 = below), hence their low-level activation state "dead". Oh, and all units' output gets collected in the journal (see point 5 below)= , which doesn't work with the alternatives (e.g., ~/.xprofile, which I used= to use). 4.) I use nspawn occasionally for running a Gentoo amd64 container for test= ing asciidoc (I wound up proxy maintaining it). It's kind of a chroot on s= teroids, hence you can use it in place of chroot, but you can also do thing= s like run containers as services (i.e., there's such a thing as an nspawn = unit), but I don't use that feature. Just as an example, the container I u= se is configured like this: % cat /etc/systemd/nspawn/gentoo-amd64-systemd.nspawn=20 [Files] BindReadOnly=3D/home/marcec/projects/gentoo/:/home/marcec/gentoo/ BindReadOnly=3D/usr/portage/distfiles/:/usr/portage/ro_distfiles/ TemporaryFileSystem=3D/var/tmp/portage/ (I bet you never heard of ro_distfiles! I learned about it while setting u= p the container (look up PORTAGE_RO_DISTDIRS in make.conf(5)).) So this is pretty much like docker, which makes sense, since they use the s= ame underlying Linux kernel features. Systemd simply enables the treatment= of containers as services (including the ability to connect to a systemd i= nstance running inside a container, in the event that the container uses sy= stemd as its service manager). 5.) The journal is another element of systemd that one could write a lot ab= out. My usage is mostly limited to inspecting the state of a service ("sys= temctl status " includes the last 10 lines of log output by default) = and looking for stuff in a specific time range. However, it has a few adva= ntages over classic syslog implementations: =2D By default it captures all stdout and stderr of service units, so you c= an't miss anything. =2D It groups all log output of a service, regardless of how many processes= it consists of, i.e., you can't miss anything (I'm thinking of naive greps= here). =2D While you can just use grep (and I sometimes do), it's often better to = use the builtin search functionality, e.g., you can output journal entries = corresponding to a specific kernel device (not useful to me, personally, bu= t illustrates that there are a lot of filters you can use). =2D As the prior point illustrates, journal entries consist of a *lot* of m= etadata, whereas with syslog, you have a quasi-structured text file that co= ntains less information. =2D It helps unclutter /var/log/ ;-) . =2D Probably more that I can't think of right now. If you don't care for it, you can also turn off persistent journal storage = and run a syslog daemon instead, or in parallel (you can't completely turn = off the journal, though, as it is still required for capturing stdout and s= tderr). 6.) I also happen to like timers a lot, because I can forego a cron daemon,= and I happen to like the "systemctl list-timers" output very much. But re= ally, you can just keep using cron, it's not a world shattering feature for= me. It does have the advantage of allowing dependencies to other units, t= hough, since timer units are units like anything else in systemd. This can= be really powerful, since, e.g., devices and mount points have correspondi= ng unit types. Actually, the main advantage of using timer units for me is that I can put = them in git and synchronise them across different computers, which I couldn= 't really do with cron, because crontabs live somewhere in /var/ (right? Or= was that only the root crontab?). Also, since timers trigger service unit= s, their output goes to the journal, too. 7.) Use of ACLs. This is just a detail, but I like that my user looks like= this: % id uid=3D1000(marcec) gid=3D100(users) Gruppen=3D100(users),10(wheel),35(games= ),1019(realtime) So I'm left with wheel (used by sudo), games (which will go away with time,= what with the games eclass being deprecated), and realtime, which doesn't = deal with device access anyway. The point is, I don't need to add myself to the right groups to gain access= to certain devices, because systemd adds the right ACLs to the right devic= e nodes once you log in (this is one of the jobs of logind, BTW), e.g.: % getfacl /dev/snd/seq=20 getfacl: Removing leading '/' from absolute path names # file: dev/snd/seq # owner: root # group: audio user::rw- user:marcec:rw- group::rw- mask::rw- other::--- This is specifically to support multi-user systems, where the current activ= e user gets access to required devices, but I like not having to bother wit= h adding myself to the right groups most of the time. Of course, there are= situations in which it still makes sense to add yourself to a specific dev= ice group. For example, on my home server my user is still part of the "au= dio" group, because otherwise I would never be granted the proper ACLs sinc= e there's no persistent login session. That would be a problem for pulseau= dio, and hence for MPD. ACLs are also used for users' persistent journal storage, i.e., you can rea= d your user's journal entries via "journalctl --user" and "--user-unit", bu= t not the system journal. 8.) Nothing super important, but I like how you can see an overview of the = differences between the default configuration files and your own overrides = with systemd-delta: > % systemd-delta > [OVERRIDDEN] /etc/tmpfiles.d/tmp.conf =E2=86=92 /usr/lib/tmpfiles.d/tmp.c= onf >=20 > --- /usr/lib/tmpfiles.d/tmp.conf 2017-12-05 17:11:28.999238832 +01= 00 > +++ /etc/tmpfiles.d/tmp.conf 2016-03-10 23:39:49.343619664 +0100 > @@ -8,15 +8,12 @@ >=20 > # See tmpfiles.d(5) for details > =20 > # Clear tmp directories separately, to make them easier to override >=20 > -q /tmp 1777 root root > -q /var/tmp 1777 root root > +# undo the Gentoo patch 226-noclean-tmp.patch > +v /tmp 1777 root root 10d > +v /var/tmp 1777 root root 30d >=20 > # Exclude namespace mountpoints created with PrivateTmp=3Dyes > x /tmp/systemd-private-%b-* > X /tmp/systemd-private-%b-*/tmp > x /var/tmp/systemd-private-%b-* > X /var/tmp/systemd-private-%b-*/tmp >=20 > - > -# Remove top-level private temporary directories on each boot > -R! /tmp/systemd-private-* > -R! /var/tmp/systemd-private-* > > [EXTENDED] /usr/lib/systemd/system/irqbalance.service =E2=86=92 /etc/sy= stemd/system/irqbalance.service.d/override.conf > [EXTENDED] /etc/systemd/system/portage-sync.service =E2=86=92 /etc/syst= emd/system/portage-sync.service.d/network.conf > [EXTENDED] /usr/lib/systemd/system/chronyd.service =E2=86=92 /etc/syste= md/system/chronyd.service.d/arguments.conf > [EXTENDED] /usr/lib/systemd/system/btrbk.service =E2=86=92 /etc/systemd= /system/btrbk.service.d/deps.conf > [EXTENDED] /usr/lib/systemd/system/cpupower-frequency-set.service =E2= =86=92 /etc/systemd/system/cpupower-frequency-set.service.d/00gentoo.conf > [EXTENDED] /usr/lib/systemd/system/btrbk.timer =E2=86=92 /etc/systemd/s= ystem/btrbk.timer.d/schedule.conf >=20 > 7 overridden configuration files found. Aha, so this tells me that I need to update my tmp.conf override. Oh, also you can override parts of system unit files by creating appropriat= e *.conf files in .d/ directories. 9.) systemd-tmpfiles provides a unified way of creating users, groups, dire= ctories, etc. required by the system in some way (it also has a cleanup fea= ture like app-admin/tmpwatch). This makes more sense when you realise that= these files are (also) supposed to be provided by upstream projects, just = like unit files. So you end up with one canonical definition of what direc= tories, users, etc. a project requires at run-time. This is a feature that= makes software developer's lives easier. It's also useful for containers = and stateless systems, though. (OpenRC gained support for this via sys-apps/opentmpfiles.) 10.) One last thing: btrfs integration. If the underlying file system is b= trfs, systemd will make use of subvolumes (the "v" and "V" specifiers in tm= pfiles files) and qgroups ("q" and "Q"), and will exploit its copy-on-write= semantics, e.g., when working with containers (which docker does, too, I b= elieve). The former two are nice to have and can help with snapshotting, t= he latter simply saves space. 11.) No, sorry, *one* more thing: generators. These are programs that gene= rate systemd units at run-time, which is, e.g., used by sys-apps/gentoo-sys= temd-integration for generating service units from the files in /etc/local.= d/, or by systemd for generating mount units from fstab, or (my favourite) = by sys-process/systemd-cron for generating timer units from files in /etc/c= ron.*/. OK, I'm done now. I hope that the "integrated toolkit" nature of systemd came across here, si= nce that's pretty much what systemd is: a toolkit for managing Linux system= s, to which belongs a service manager (init system), system logger, periodi= c job execution, and various other bits and piece that often enough supplem= ent each other to yield a system that is, in my view, more than the sum of = its parts. > This is also equally directed at Neil, who also posted a similar > abbreviated list of features. I'm curious about what he, and others in general, would say, too. I can im= agine some people who might have a more differentiated opinion. HTH =2D-=20 Marc Joliet =2D- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup --nextPart5201580.Wz15M2GXV4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEax7Ya5gDQFOJHKGQv9DmhiyIePQFAlozIm4ACgkQv9DmhiyI ePQc9RAAjSMJbYGSUBc2dCmYJWCf3rAwiliB2aHNCOYoJ5oaGqG43XL+yVm1vCPc K7xIXkaeacE5k+V0QZ+RLtw4CBtu3lVu5TB1oHH18idrSUT1BafqPRiSAvCEIR99 YTy5GsGJfhZHkZVC0ejvFWi4xCPWLQxQee1+QXUxqAjqevP3jD8bvKrswYYsHYAl AsosyzmjepQ1w3kfL3Yi01s6SgXX7cMRGjDl4O62IuzeXQzryxURA0bbbKhY2yBW XTlQU6sKk/hCzSkCJfABNa/Czz5SnrsfD3h1FKzAhmqbZt/K8AIiXUkcp/OhT38v nMjL1AWrzxf4bH4axapO/pqRltC1S60QWo8N7Ks3rNI5JGGZ5Fx/7ZnQj6zvRcMP MahSHxR9n2pLcPCSfCfkjhD0Y7CB+oKswxTPk0jBK5LPVCg75eCzcClnTqo9Ggin LGgYbLVxLwjeUNB+T2WoC8wF3aR/xO6ZEpVXL/m5jLz1cJwC8rf7CS6ENe7AgVoh EvIsAbj0eRtDLzDga5cpY1lkiJUq9l88g6vEi6z+7bLlrMAHo3TC8kgVVW8OFDOh io3XB+kaD3nJgcC/4mvIBh4FyYbZo9G4Kwm+t3dSExNQpJltFxpWARsX34dqC6EW U6CM7BGPf06p5hPdjoWbVuZHqRhpDd7XmdRBauOL7d7J4gUhtDg= =U31Y -----END PGP SIGNATURE----- --nextPart5201580.Wz15M2GXV4--