On 02/23/2014 06:01 PM, Canek Peláez Valdés wrote: > On Sun, Feb 23, 2014 at 5:06 AM, <thegee...@thegeezer.net> 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"?
using openrc if i reboot a system that requires fsck on /mnt/data it will do an fsck. but not log anything anywhere about the result, which is why i put this as a pro. does systemd have configurable options for '/' so that it can run readonly rather than dropping to emergency in case of problems? >>> 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 if >> 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=Static network service >>> After=local-fs.target >>> Before=network.target >>> Documentation=man:ifconfig(8) >>> Documentation=man:route(8) >>> >>> [Service] >>> Type=oneshot >>> RemainAfterExit=yes >>> ExecStart=/bin/ifconfig enp2s12 192.168.1.2 broadcast 192.168.1.255 >>> netmask 255.255.255.0 up >>> ExecStart=/bin/route add default gw 192.168.1.1 enp2s12 >>> >>> [Install] >>> WantedBy=multi-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 using >> 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. can you please clarify what you mean by absorbing iproute2? >>>> 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=nbytes >>> 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=50% >>> """ >>> >>> 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 you >> 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. the only reason that i bring this up is because if you _don't_ use systemd then /tmp is a folder hanging off / if you _do_ use systemd it will try to mount it tmpfs not everyone will realise this which is why i listed it as a 'gotcha' -- a nuance in working with it but not a major issue. > [ 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. thanks for the clearing up >> 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=/sbin/ip rule add" etc >> i'd also have "exec=/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=markup >>> [2] >>> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/openssh/files/sshd.socket?view=markup >>> [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-and-Someone-Else-by-YoungDumbCrazy
