Canek Peláez Valdés posted on Mon, 03 Mar 2014 11:58:18 -0600 as
excerpted:
> On Mon, Mar 3, 2014 at 11:44 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>> Meanwhile, for the record, the systemd and now udev folks have stated
>> that they would like to eventually merge udev fully into systemd, and
>> indeed, it's already shipped as a single tarball, but that udev is
>> likely to remain a separate binary that can be run stand-alone for some
>> time, because that's necessary in ordered to be able to keep a somewhat
>> small initramfs, with udev but without all the trappings of a
>> full-fledged systemd.
>
> If you use dracut to generate your initramfs, you can get a full-fledged
> systemd inside it, so you can use the systemd in the initramfs to start
> the systemd in the real filesystem. I use it like that.
I had seen hints to that effect, but as I was still running openrc it
didn't have any immediate bearing on my dracut and initr* config, beyond
USE=-systemd for dracut.
>> (This said as an openrc user at least for the time being... even
>> apparently one of the only people actually running the live-git
>> openrc-9999, or at least all the bugs filed on it seem to be mine.
>> I've suspected for some time that I'll eventually switch to systemd,
>> but was at least originally hoping to avoid it until it quits actively
>> blackholing nearly everything it comes across and had some reasonable
>> time to stabilize without gobbling something else up. But when that'll
>> be... who knows? And I'm getting an itch to try it one of these days,
>> or at least seriously read up on it with a view to _consider_ trying
>> it, tho if I do it'll likely still be against my better judgment, since
>> I don't see it really stabilizing any time soon and I had originally
>> planned to wait for that. So I guess I sort of fall in the middle in
>> this debate.)
>
> If you run OpenRC live, I think you'll be fine running systemd, even
> 209/210, which introduced so many changes I've been waiting to upgrade
> my systems.
>
> Come to the dark side. We have cookies.
=:^)
As you /might/ have deduced by now from the hints of the past-tense "was"
and "didn't" above, as well as the fact that I'm dredging up this
slightly (10 days) stale thread to reply to...
Yeah, I'm actually replying from a systemd booted system, now.
As I was privately predicting for myself, but didn't want to promise even
to myself[1], I was getting close to the tipping point and this thread,
plus a couple extra days off, provided the trigger.
Since my experience may be of help to others considering the switch, here
we go...
In addition to unfortunately not finding a proper good detail but not
losing sight of the forest for the trees admin-level-targeted systemd
guide, a problem I overcame by simply immersing myself in the idea, full
systemd for admins series, multiple hour-ish videos, hours of thinking
about it while doing other things, sleeping over what I was learning over
several days...
There were five specific problems, three of which I've now overcome, with
two less pressing ones to go:
1) Various fstab mount configuration issues (local-fs.target).
To my very pleasant surprise, systemd has a reasonably effective nested-
mount-dependency algorithm and can often figure out on its own which
fstab configured mount-points are nested under and thus depend on
others. This actually simplified things considerably as one of my custom
openrc services was basically a localmount that had to come after
localmount but before some other service, in ordered to properly handle
nested mountpoints, and systemd's nested-mount-dependency processing very
nicely solved most of that automatically, without my having to worry
about porting a custom service.
1a) Unfortunately, systemd's nested-mountpoint detection algorithm isn't
smart enough to deal with symlinked paths, at least not in all cases.
One of my mount-related problems was thus a bind-mount configured in
fstab, that wasn't happening because the origin, on a different non-root
filesystem, wasn't mounted yet, so the attempt to bind-mount it elsewhere
failed, and local-fs.target was failing as a result of that failure.
I solved that one by changing the origin/device path for that fstab entry
to point at the canonical path instead of the symlinked path.
1b) My fstab entry for tmpfs on /run had a size=2m option, plenty for
/run on openrc, but NOT for systemd, as by the time it got to the /run
remount it already had an 8-meg early-boot journal file there, so
obviously the remount to 2-meg was failing! Of course that was failing
local-fs.target as well.
That one was hard to track down as I didn't expect systemd to be putting
a journal there and thus couldn't imagine what the problem was, but once
tracked down, given that I'm running 16-gig RAM, upping that to something
a bit more reasonable for the new usage, size=512m, was an easy fix.
With those fixes, local-fs.target finally succeeded, and I could get
farther in the boot, most services of course having an automatic
dependence on local-fs.target.
2) Unit file .include deprecated, replaced by *.d/*.conf files.
2a) systemd-random-seed.service was failing, again due to a mount-point-
detection symlink issue -- my /var is on my rootfs, which is read-only
mounted for normal operation (only rw mounted for updates and config
changes), so /var/lib/ is a symlink to /home/var/lib, /home naturally
being rw mounted in normal operation, and systemd was trying to read the
random-seed off that symlinked /home location before it was mounted,
because all it knew to check for was /var, which being on / was of course
mounted.
This one I solved initially by creating a new systemd-random-seed.service
file in /etc, .including the default service in /usr/systemd/system/, but
with an added RequiresMountsFor= entry.
That worked, but later on I found a note in the TODO to document the fact
that .include was deprecated and to point people to *.d/*.conf files
instead. So I decided to try that. The problem with /that/ was that the
TODO reference (and various other *.conf references I found) weren't
fully fleshed out, and as a systemd newbie I had some difficulty trying
to figure out what they were talking about.
But after absorbing systemd for a few days I finally realized that not
yet fully documented allusions I was seeing were to (paths like, for this
service) /etc/systemd/system/systemd-random-seed.service.d/whatever.conf.
And after adding a *.conf file there with the appropriate
[Unit]
RequiresMountsFor=
... entry, I was able to delete my custom service file and return to
using the shipped service file, appending the appropriate *.conf line to
the shipped configuration that way.
2b) I wasn't satisfied with the default gpm unit file config either, but
by the time I got to that, I knew .includes were deprecated, and was in
the process of trying to figure out what the allusion to *.d/*.conf was
all about.
But once I figured that out for random-seed, I was quickly able to add
/etc/systemd/system/gpm.service.d/execstart.conf , with a customized
ExecStart= line. =:^)
3) Systemd network config.
This one took me awhile too. After the above and a few other minor
tweaks to general systemd/journald/logind configuration[2], the big
problem was that I was still networkless. I didn't want to install
network manager or whatever for a simple single-NIC static IP config, I'm
still on systemd-208 as I've not figured out the systemd/dracut thing
yet, so I don't have the 209+ networkd yet, and the various static-ip-
configuring network.service units I could find via google (plus one on a
systemd bug on bugs.g.o) all used ip, from iproute2, which I had never
installed as the old ifconfig and route from net-tools had to that point
done all I needed it to do.
IMO this one's likely the biggest current problem for the gentoo masses
who might contemplate a systemd switch, as my other problems are due to
my decidedly custom config or are reasonably covered on the wiki.g.o
systemd page, while there's very likely quite a few gentooers still on
ifconfig/net-tools and unfortunately there's very little network
discussion on the wiki page at all, let alone a nice step-by-step in the
gentoo documentation tradition, covering ifconfig/net-tools users among
others. =:^(
I'm actually quite disappointed that the gentoo/systemd folks don't have
some sort of virtual/network-manager package or the like setup, with the
various network.service and similar files for each one, and good coverage
on the wiki. Given all the noise around systemd, and the vital role I'd
guess a working network config plays for most gentoo boxes, you'd think
that would be well covered. Oh, well... At least it appears now to be a
quite temporary problem, to hopefully be solved with the networkd in
210/211/whatever-the-next-unmasked/unblocked happens to be.
Anyway, a quick emerge --pretend iproute2 said it wasn't going to pull
any other deps I didn't already have, and I decided a single additional
reasonably core package that I really probably should have installed
years ago was after all a pretty small price to pay, so I finally just
bit the bullet and installed it, and then setup the network@.service file
using the ip command from iproute2.
Not so painful after all, but it'll still be nice when I get 210 or 211
or whatever installed, and can hopefully use the new networkd solution
instead of the still unofficial custom hack I've installed to deal with
networking for the time being.
Which brings me up to current, with those three issues behind me.
The remaining two issues are:
4) Dracut and systemd
4a) Dracut's USE=systemd, enable or disable?
What does that do and given that the current systemd-less initr* I'm
running now works well booting regardless of whether init=systemd, init
(openrc), or bash (rescue shell), will whatever changes systemd in the
initr* brings be worth it, or not?
Of course since you mentioned that you're running with systemd in your
init, I'm hoping you can be of help on this one. =:^)
4b) The ongoing systemd-209+ file "musical chairs" and the havoc that
plays with dracut, thus the current >=systemd-209 blockage in dracut.
It'd sure be nice to have this resolved one way or another, particularly
so given that 209+ brings the hopefully more final networkd solution to
#3 above, as well. I was actually hoping that the multi-device btrfs
root kernel command-line rootflags issue was resolved so I could just
drop the initr* thing now and thus wouldn't have to worry about dracut
any more, but as I posted in the earlier post, unfortunately not.
5) A couple remaining minor service failures:
5a) ntp.service is still failing, for some reason.
While I was running ntp on the old mobo before I upgraded and thus
haven't ever really run this one without it, I've no reason to think this
machine's hardware is /bad/ at keeping time, so ntp isn't critical. But
it'll be nice to find whatever's going on there and fix it.
Based on an aside-comment I read when researching something else, I
already have one lead to check on this one -- the comment said systemd's
privatetmp option doesn't play well with /var/tmp being a symlink to /
tmp, and that's what I have here (with /tmp in turn being tmpfs), and I
think the ntp unit might use privatetmp, so... But I've yet to confirm,
and then I'll have to look for alternatives, so...
5b) On openrc, I have a custom user-bootclean service that cleans up a
few stray user files at boot, that systemd created an attempted port for,
except it's failing. I've not investigated that one at all yet, but just
as I write this it occurs to me that the problem might be yet another
symlinked path mount-dependency issue, so I now have one lead to
investigate on that one, too.
5c) bind/named (not failing but reduced functionality)
There's a gentoo bug about this as well. Openrc's named/bind initscript
has an optional chroot feature. Systemd has both a legacy chroot support
feature and a newer kernel-namespaces-based chroot replacement, but the
shipped named.service file doesn't make use of either one. If nobody
else gets to that bug before I get comfortable enough with systemd to try
to address it myself, I'll try to come up with a systemd-style solution,
potentially using namespaces, to parallel the gentoo/openrc named
initscript's optional chroot feature.
https://bugs.gentoo.org/show_bug.cgi?id=496198
Other than that... a couple positives already. =:^)
1) As mentioned in problem #1 above, systemd has actually surprisingly
good nested mountpoint dependency resolution. My setup is complicated
enough I really appreciate that, and now that I'm "dual-booting" openrc
and systemd <g>, I definitely miss that feature on openrc! =:^0
2) Speed, WOW!
I've had openrc's parallel boot option enabled for years, but systemd
really does run circles around it! I'd guess a lot of that's due to the
socket-based activation along with the mount dependency resolution such
that services that are only dependent on each other due to that can still
start in parallel, and particularly with socket-based dependencies, the
otherwise depending service can often actually fully initialize if it
gets to that point before the depended service is up, as long as the
socket is already active and buffering any data the depending service
might try to write to it.
The fact that it's all C based and mostly declarative, with near-zero
scripting and far /far/ less forking, thus short-circuiting a good
portion of what even openrc's semi-C-based solution does, certainly helps
as well.
And of course the fact that I'm on SSD, where all those services starting
in parallel doesn't trigger a seek-storm on the spinning rust that's not
there to have a seek-storm on, doesn't hurt! (Systemd has a read-ahead
service to counteract part of the parallel-init seek-storm issue, but
spinning rust will still be a bit of a bottleneck. I had switched to SSD
and my boot times improved, but in hindsight on openrc, only to a point,
because the service-dependency on openrc then became the bottleneck.
With systemd's socket-based-activation and the like killing /that/
bottleneck too, the speed of SSD **REALLY** shows it's stuff! I had no
/idea/!)
I have a feeling that once I get settled in, I'll be doing far more full
shutdowns, since boottimes really /are/ trivial on systemd. And looking
to the future, if logind ends up doing for kde5 login times what systemd
did for boot times... WOW! The idea of shutdown and startup cycles
being so trivial one might as well just shut down when going to microwave
a snack, since bootup and session startup's literally mostly the time
waiting for the human to type in the password...
---
Notes:
[1] Predicting but not promising, even to myself: I've discovered that I
work best without deadlines or too specific goals, which only tend to
demotivate and drive procrastination. Left to itself, at some point the
drive to find some stable conclusion normally takes over, at which point
it's generally a done deal, concluded far more rapidly and with more
finality than it would be, had I tried to artificially drive it myself,
or let others try to drive it for me.
[2] General configuration changes, well enough documented that I didn't
have much problem with them:
(a)/etc/systemd/system/default.target symlink pointing at multi-user,
since I login at the CLI and have XSESSION set so I can startx, so systemd
would quick complaining about the missing *DM service.
(b) /etc/systemd/journald.conf: Storage=volatile at least until I figure
out whether I want to keep syslog-ng or not, appropriate RuntimeMaxUse
and RuntimeKeepFree values, ForwardToConsole=yes and TTYPath=/dev/tty12,
so I get the traditional TTY12 console log.
(c) Setting NAutoVTs and ReserveVT= in /etc/systemd/logind.conf
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
excerpted:
> On Mon, Mar 3, 2014 at 11:44 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>> Meanwhile, for the record, the systemd and now udev folks have stated
>> that they would like to eventually merge udev fully into systemd, and
>> indeed, it's already shipped as a single tarball, but that udev is
>> likely to remain a separate binary that can be run stand-alone for some
>> time, because that's necessary in ordered to be able to keep a somewhat
>> small initramfs, with udev but without all the trappings of a
>> full-fledged systemd.
>
> If you use dracut to generate your initramfs, you can get a full-fledged
> systemd inside it, so you can use the systemd in the initramfs to start
> the systemd in the real filesystem. I use it like that.
I had seen hints to that effect, but as I was still running openrc it
didn't have any immediate bearing on my dracut and initr* config, beyond
USE=-systemd for dracut.
>> (This said as an openrc user at least for the time being... even
>> apparently one of the only people actually running the live-git
>> openrc-9999, or at least all the bugs filed on it seem to be mine.
>> I've suspected for some time that I'll eventually switch to systemd,
>> but was at least originally hoping to avoid it until it quits actively
>> blackholing nearly everything it comes across and had some reasonable
>> time to stabilize without gobbling something else up. But when that'll
>> be... who knows? And I'm getting an itch to try it one of these days,
>> or at least seriously read up on it with a view to _consider_ trying
>> it, tho if I do it'll likely still be against my better judgment, since
>> I don't see it really stabilizing any time soon and I had originally
>> planned to wait for that. So I guess I sort of fall in the middle in
>> this debate.)
>
> If you run OpenRC live, I think you'll be fine running systemd, even
> 209/210, which introduced so many changes I've been waiting to upgrade
> my systems.
>
> Come to the dark side. We have cookies.
=:^)
As you /might/ have deduced by now from the hints of the past-tense "was"
and "didn't" above, as well as the fact that I'm dredging up this
slightly (10 days) stale thread to reply to...
Yeah, I'm actually replying from a systemd booted system, now.
As I was privately predicting for myself, but didn't want to promise even
to myself[1], I was getting close to the tipping point and this thread,
plus a couple extra days off, provided the trigger.
Since my experience may be of help to others considering the switch, here
we go...
In addition to unfortunately not finding a proper good detail but not
losing sight of the forest for the trees admin-level-targeted systemd
guide, a problem I overcame by simply immersing myself in the idea, full
systemd for admins series, multiple hour-ish videos, hours of thinking
about it while doing other things, sleeping over what I was learning over
several days...
There were five specific problems, three of which I've now overcome, with
two less pressing ones to go:
1) Various fstab mount configuration issues (local-fs.target).
To my very pleasant surprise, systemd has a reasonably effective nested-
mount-dependency algorithm and can often figure out on its own which
fstab configured mount-points are nested under and thus depend on
others. This actually simplified things considerably as one of my custom
openrc services was basically a localmount that had to come after
localmount but before some other service, in ordered to properly handle
nested mountpoints, and systemd's nested-mount-dependency processing very
nicely solved most of that automatically, without my having to worry
about porting a custom service.
1a) Unfortunately, systemd's nested-mountpoint detection algorithm isn't
smart enough to deal with symlinked paths, at least not in all cases.
One of my mount-related problems was thus a bind-mount configured in
fstab, that wasn't happening because the origin, on a different non-root
filesystem, wasn't mounted yet, so the attempt to bind-mount it elsewhere
failed, and local-fs.target was failing as a result of that failure.
I solved that one by changing the origin/device path for that fstab entry
to point at the canonical path instead of the symlinked path.
1b) My fstab entry for tmpfs on /run had a size=2m option, plenty for
/run on openrc, but NOT for systemd, as by the time it got to the /run
remount it already had an 8-meg early-boot journal file there, so
obviously the remount to 2-meg was failing! Of course that was failing
local-fs.target as well.
That one was hard to track down as I didn't expect systemd to be putting
a journal there and thus couldn't imagine what the problem was, but once
tracked down, given that I'm running 16-gig RAM, upping that to something
a bit more reasonable for the new usage, size=512m, was an easy fix.
With those fixes, local-fs.target finally succeeded, and I could get
farther in the boot, most services of course having an automatic
dependence on local-fs.target.
2) Unit file .include deprecated, replaced by *.d/*.conf files.
2a) systemd-random-seed.service was failing, again due to a mount-point-
detection symlink issue -- my /var is on my rootfs, which is read-only
mounted for normal operation (only rw mounted for updates and config
changes), so /var/lib/ is a symlink to /home/var/lib, /home naturally
being rw mounted in normal operation, and systemd was trying to read the
random-seed off that symlinked /home location before it was mounted,
because all it knew to check for was /var, which being on / was of course
mounted.
This one I solved initially by creating a new systemd-random-seed.service
file in /etc, .including the default service in /usr/systemd/system/, but
with an added RequiresMountsFor= entry.
That worked, but later on I found a note in the TODO to document the fact
that .include was deprecated and to point people to *.d/*.conf files
instead. So I decided to try that. The problem with /that/ was that the
TODO reference (and various other *.conf references I found) weren't
fully fleshed out, and as a systemd newbie I had some difficulty trying
to figure out what they were talking about.
But after absorbing systemd for a few days I finally realized that not
yet fully documented allusions I was seeing were to (paths like, for this
service) /etc/systemd/system/systemd-random-seed.service.d/whatever.conf.
And after adding a *.conf file there with the appropriate
[Unit]
RequiresMountsFor=
... entry, I was able to delete my custom service file and return to
using the shipped service file, appending the appropriate *.conf line to
the shipped configuration that way.
2b) I wasn't satisfied with the default gpm unit file config either, but
by the time I got to that, I knew .includes were deprecated, and was in
the process of trying to figure out what the allusion to *.d/*.conf was
all about.
But once I figured that out for random-seed, I was quickly able to add
/etc/systemd/system/gpm.service.d/execstart.conf , with a customized
ExecStart= line. =:^)
3) Systemd network config.
This one took me awhile too. After the above and a few other minor
tweaks to general systemd/journald/logind configuration[2], the big
problem was that I was still networkless. I didn't want to install
network manager or whatever for a simple single-NIC static IP config, I'm
still on systemd-208 as I've not figured out the systemd/dracut thing
yet, so I don't have the 209+ networkd yet, and the various static-ip-
configuring network.service units I could find via google (plus one on a
systemd bug on bugs.g.o) all used ip, from iproute2, which I had never
installed as the old ifconfig and route from net-tools had to that point
done all I needed it to do.
IMO this one's likely the biggest current problem for the gentoo masses
who might contemplate a systemd switch, as my other problems are due to
my decidedly custom config or are reasonably covered on the wiki.g.o
systemd page, while there's very likely quite a few gentooers still on
ifconfig/net-tools and unfortunately there's very little network
discussion on the wiki page at all, let alone a nice step-by-step in the
gentoo documentation tradition, covering ifconfig/net-tools users among
others. =:^(
I'm actually quite disappointed that the gentoo/systemd folks don't have
some sort of virtual/network-manager package or the like setup, with the
various network.service and similar files for each one, and good coverage
on the wiki. Given all the noise around systemd, and the vital role I'd
guess a working network config plays for most gentoo boxes, you'd think
that would be well covered. Oh, well... At least it appears now to be a
quite temporary problem, to hopefully be solved with the networkd in
210/211/whatever-the-next-unmasked/unblocked happens to be.
Anyway, a quick emerge --pretend iproute2 said it wasn't going to pull
any other deps I didn't already have, and I decided a single additional
reasonably core package that I really probably should have installed
years ago was after all a pretty small price to pay, so I finally just
bit the bullet and installed it, and then setup the network@.service file
using the ip command from iproute2.
Not so painful after all, but it'll still be nice when I get 210 or 211
or whatever installed, and can hopefully use the new networkd solution
instead of the still unofficial custom hack I've installed to deal with
networking for the time being.
Which brings me up to current, with those three issues behind me.
The remaining two issues are:
4) Dracut and systemd
4a) Dracut's USE=systemd, enable or disable?
What does that do and given that the current systemd-less initr* I'm
running now works well booting regardless of whether init=systemd, init
(openrc), or bash (rescue shell), will whatever changes systemd in the
initr* brings be worth it, or not?
Of course since you mentioned that you're running with systemd in your
init, I'm hoping you can be of help on this one. =:^)
4b) The ongoing systemd-209+ file "musical chairs" and the havoc that
plays with dracut, thus the current >=systemd-209 blockage in dracut.
It'd sure be nice to have this resolved one way or another, particularly
so given that 209+ brings the hopefully more final networkd solution to
#3 above, as well. I was actually hoping that the multi-device btrfs
root kernel command-line rootflags issue was resolved so I could just
drop the initr* thing now and thus wouldn't have to worry about dracut
any more, but as I posted in the earlier post, unfortunately not.
5) A couple remaining minor service failures:
5a) ntp.service is still failing, for some reason.
While I was running ntp on the old mobo before I upgraded and thus
haven't ever really run this one without it, I've no reason to think this
machine's hardware is /bad/ at keeping time, so ntp isn't critical. But
it'll be nice to find whatever's going on there and fix it.
Based on an aside-comment I read when researching something else, I
already have one lead to check on this one -- the comment said systemd's
privatetmp option doesn't play well with /var/tmp being a symlink to /
tmp, and that's what I have here (with /tmp in turn being tmpfs), and I
think the ntp unit might use privatetmp, so... But I've yet to confirm,
and then I'll have to look for alternatives, so...
5b) On openrc, I have a custom user-bootclean service that cleans up a
few stray user files at boot, that systemd created an attempted port for,
except it's failing. I've not investigated that one at all yet, but just
as I write this it occurs to me that the problem might be yet another
symlinked path mount-dependency issue, so I now have one lead to
investigate on that one, too.
5c) bind/named (not failing but reduced functionality)
There's a gentoo bug about this as well. Openrc's named/bind initscript
has an optional chroot feature. Systemd has both a legacy chroot support
feature and a newer kernel-namespaces-based chroot replacement, but the
shipped named.service file doesn't make use of either one. If nobody
else gets to that bug before I get comfortable enough with systemd to try
to address it myself, I'll try to come up with a systemd-style solution,
potentially using namespaces, to parallel the gentoo/openrc named
initscript's optional chroot feature.
https://bugs.gentoo.org/show_bug.cgi?id=496198
Other than that... a couple positives already. =:^)
1) As mentioned in problem #1 above, systemd has actually surprisingly
good nested mountpoint dependency resolution. My setup is complicated
enough I really appreciate that, and now that I'm "dual-booting" openrc
and systemd <g>, I definitely miss that feature on openrc! =:^0
2) Speed, WOW!
I've had openrc's parallel boot option enabled for years, but systemd
really does run circles around it! I'd guess a lot of that's due to the
socket-based activation along with the mount dependency resolution such
that services that are only dependent on each other due to that can still
start in parallel, and particularly with socket-based dependencies, the
otherwise depending service can often actually fully initialize if it
gets to that point before the depended service is up, as long as the
socket is already active and buffering any data the depending service
might try to write to it.
The fact that it's all C based and mostly declarative, with near-zero
scripting and far /far/ less forking, thus short-circuiting a good
portion of what even openrc's semi-C-based solution does, certainly helps
as well.
And of course the fact that I'm on SSD, where all those services starting
in parallel doesn't trigger a seek-storm on the spinning rust that's not
there to have a seek-storm on, doesn't hurt! (Systemd has a read-ahead
service to counteract part of the parallel-init seek-storm issue, but
spinning rust will still be a bit of a bottleneck. I had switched to SSD
and my boot times improved, but in hindsight on openrc, only to a point,
because the service-dependency on openrc then became the bottleneck.
With systemd's socket-based-activation and the like killing /that/
bottleneck too, the speed of SSD **REALLY** shows it's stuff! I had no
/idea/!)
I have a feeling that once I get settled in, I'll be doing far more full
shutdowns, since boottimes really /are/ trivial on systemd. And looking
to the future, if logind ends up doing for kde5 login times what systemd
did for boot times... WOW! The idea of shutdown and startup cycles
being so trivial one might as well just shut down when going to microwave
a snack, since bootup and session startup's literally mostly the time
waiting for the human to type in the password...
---
Notes:
[1] Predicting but not promising, even to myself: I've discovered that I
work best without deadlines or too specific goals, which only tend to
demotivate and drive procrastination. Left to itself, at some point the
drive to find some stable conclusion normally takes over, at which point
it's generally a done deal, concluded far more rapidly and with more
finality than it would be, had I tried to artificially drive it myself,
or let others try to drive it for me.
[2] General configuration changes, well enough documented that I didn't
have much problem with them:
(a)/etc/systemd/system/default.target symlink pointing at multi-user,
since I login at the CLI and have XSESSION set so I can startx, so systemd
would quick complaining about the missing *DM service.
(b) /etc/systemd/journald.conf: Storage=volatile at least until I figure
out whether I want to keep syslog-ng or not, appropriate RuntimeMaxUse
and RuntimeKeepFree values, ForwardToConsole=yes and TTYPath=/dev/tty12,
so I get the traditional TTY12 console log.
(c) Setting NAutoVTs and ReserveVT= in /etc/systemd/logind.conf
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman