Re: Getting a grip on systemd, just in case.

Personally, I'll try to stay with the standard sysvinit/initscripts for as long as I can, until such a time as when/if the Arch devs force systemd to be the default init system and deprecate sysvinit/initscripts.

Of course, this isn't to say I won't try to learn a bit about systemd, but I have my own personal philosophical gripes about it not being particularly Unixy (the systemd dev himself has stated that in his opinion "Unix is broken" <.<), but if it really comes down to it, I'm willing to convert.

EDIT: This is just an expression of opinon; I really, really hope this doesn't spark an off-topic debate about the Unix philosophy, how it relates to systemd, etc. :x

Re: Getting a grip on systemd, just in case.

Good ansewer, I dont care about the boot time, but I preffer more efficient softwareIf you give em select fast bot or slow boot I select eficient boot not caring about the time (obiouus not like a win7 in a pentium I (yes boot take 2Hrs but boot))

I prefer efficience over feature rch and other, this is why I use systemd

f you ask the adecuate question and provide the adecuate and good ansewer you not reseive any bad reseivenment fomr other but if yu provibide bad questions or/and bad ansewers espect bad reaction like many others aroun thge forum

Re: Getting a grip on systemd, just in case.

Jristz wrote:

I prefer efficience over feature rch and other, this is why I use systemd

This is why I use Arch, you start of with a bare installation and make it what you want, most other distros give you a default install based on their perceived audience. There is nothing wrong with that because it's what they are aiming for and I could (with some time) make the other distro leaner and faster, but it is already done for me with Arch

My current install of Arch running Xfce does everything I want, it is fast and very rarely causes problems, it probably sounds silly but each time I boot the thing up I have a smile on my face because I enjoy using it.

Re: Getting a grip on systemd, just in case.

Lennart seems to think (13.00-18.30) that systemd is both less bloated and more UNIXey that sysvinit at least at some sense. His arguments are essentially that:-systemd does a lot of stuff more efficently that sysvinit leading to simpler system.-systemd is modular so there's no downside to unused features.-services are exposed as files.-services are also exposed at runtime as files through cgroups.

I personally like how easy systemd is to manage and the integration that it provides with rest of the Linux stack. One of the cool things that comes to mind is that systemd-analyze can collect data from gummiboot, intramfs, kernel and system itself and show how much each of them took time to boot. On simple desktop system as long as init system works just about only thing that really matters is the boot time and systemd has very strong focus on it. The on-demand loading of services like CUPS and bluetooth also comes in handy.

Re: Getting a grip on systemd, just in case.

Jristz wrote:

Good ansewer, I dont care about the boot time, but I preffer more efficient softwareIf you give em select fast bot or slow boot I select eficient boot not caring about the time (obiouus not like a win7 in a pentium I (yes boot take 2Hrs but boot))

I'm with triton60 on this. The faster boot is a pleasant surprise, but it's mostly just a useful side effect. I generally don't (re)boot that often so it doesn't really impact my usage that much.

As Teho mentioned, the fact that systemd's configuration is exposed as easily configured files (rather than scripts), creating your own service is mostly trivial. Gone is the need for convoluted daemon start-ups, start-stop-daemon, and (mostly) complicated start/stop logic.

Re: Getting a grip on systemd, just in case.

Eliminate one by one from rc.conf and see what happens. Some, like dbus, are already native and are already enabled. Some *.services needs to be created by you some needs only to be enabled n systemd. The transition from rc.conf is harder than a clean systemd from scratch, I think. Moreover systemd is still new and some service/unit files is still waiting to be created upstream.

Re: Getting a grip on systemd, just in case.

Said by swanson: "Eliminate one by one from rc.conf and see what happens."

Ok, I am trying to work through this, too. I had just discovered (before seeing this post) that my ntpd was not running, even though I have it in my rc.conf daemons array. I had enabled it as a systemd service and started it and it seems to be working, although I have not yet rebooted. I assume it will continue to run after reboots. So now I suppose I should remove ntpd from the daemons array.

Now, looking at this thread, I am starting to look at each daemon in my rc.conf. So right now, I am looking at syslog-ng. systemd says it is disabled. I am guessing that I should enable it in systemd, start it, and remove it from rc.conf to avoid future confusion. And so on with the other daemons in my rc.conf.

Re: Getting a grip on systemd, just in case.

89c51 wrote:

skanky wrote:

For start-up times:

man systemd-analyze

Yes but isn't it supposed to be consistent more or less?

Yes. My understanding is that systemd-analyze helps you examine which services are taking the longest to start up. Although systemd starts as many services in parallel as it can, there may be dependencies that must be started before subsequent services can start. I suppose it's also helpful in the event a service is taking longer than it should which may be indicative of a problem or unusual condition even if the service otherwise starts normally.

From my experience, systemd is surprisingly consistent across platforms. My HTPC starts up in about 17 seconds. My desktop (with many, many more daemons running) takes about 22 seconds.

Re: Getting a grip on systemd, just in case.

Although systemd starts as many services in parallel as it can, there may be dependencies that must be started before subsequent services can start.

Forgive me if this is a gross misunderstanding, but is this not similar to the "@<daemon>" syntax in rc.conf with the standard initscripts? Perhaps what you're referring to is the pre-daemons stage?

It is similar, but with three differences:

1) the parallelism logic applies both to stuff happening in "rc.sysinit" as well as DAEMONS;2) the ordering is encoded in the unit files themselves, so it is not something the admin has to worry about; and3) in DAEMONS you can only say "@foo" which means "no other daemon will wait for foo to start". However, if you want foo and bar to start in parallel, but baz to wait for both to finish, then there is no way to do that using the DAEMONS array.

Re: Getting a grip on systemd, just in case.

Although systemd starts as many services in parallel as it can, there may be dependencies that must be started before subsequent services can start.

Forgive me if this is a gross misunderstanding, but is this not similar to the "@<daemon>" syntax in rc.conf with the standard initscripts? Perhaps what you're referring to is the pre-daemons stage?

@daemon is a dirty hack compared to what systemd does. Basically systemd starts things in parallel, but does so intelligently, so for example if service A requires service B to be started, it will automatically handle that.

Re: Getting a grip on systemd, just in case.

89c51 wrote:

skanky wrote:

For start-up times:

man systemd-analyze

Yes but isn't it supposed to be consistent more or less?

I think so, and mine generally is - though it's so fast small differences are relatively large.From what little I've tracked it (the laptop was quite quick to boot before, but booting now is as quick as resume from suspend to disk now so I'm not fussed by the odd inconsistency), the main differences are down the the wireless connection at start-up, which is down to the vagaries of wireless.

"...one cannot be angry when one looks at a penguin." - John Ruskin"Life in general is a bit shit, and so too is the internet. And that's all there is." - scepticisle

Re: Getting a grip on systemd, just in case.

I believe that things like dhcp-leases and to some small extent udev-automagic would be the most time-consuming on my systems,though i use a static ip to remedy that.

Another is if i have my USB-drive mount at boot (i do not anymore, added noauto and mount it manually when needed instead)Since it has some hardware set irritating wake-up time.

Then what is mostly timesaving is not having too many extra daemons or services at boot is a good thing too.

My current "native" init-script-setup boots to tty-login in about 6-8 seconds already,and openbox (autostarting firefox & lxterminal without waiting) gives 2-3 seconds on top of that.

Figuring how seldom i boot, i cannot imagine what a few less seconds would actually mean in my usecase for productivity.

Example: DAEMONS=(syslog-ng network ntpd crond alsa !oss)

(i don't use the @ way, since it goes fast anyways and i like seeing how things went as soon as possible, if i need to fix anything)

systemd might be good in the long run, if it doesn't steer towards an all too overdone or "everyone should use their system this way"-like path.this, along with a feel of loss of "power user"-control or quick insight have been my main concerns here,since everything i have been using my computer for already works to be honest.

But should those be remedied or proved non-concerns, then i will have no objections left.I still see pulseaudio and/or avahi as added fluff on top of neat things that already works when set up with a grain of competence - that brings in some non-inflammatory doubts.