On Sun, Feb 23, 2014 at 5:06 AM, <[email protected]> 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 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. >>> 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. [ 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=/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 -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
