You are not logged in.

#601 2011-05-18 10:45:08

WorMzy
Administrator
From: Scotland
Registered: 2010-06-16
Posts: 12,456
Website

Re: systemd: Yet Another Init Replacement

Zom wrote:

That's pretty much wrong. AFAIK, systemd just uses some variables from rc.conf, things like hostname, while the DAEMONs part is completely skipped.

Not according to the wiki: https://wiki.archlinux.org/index.php/Sy … ntegration

DAEMONS (ordering and blacklisting is respected, if a native systemd service file by the same name as a daemon exists, it will take precedence, this logic can be disabled by 'systemctl disable arch-daemons.target')


Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Offline

#602 2011-05-18 11:22:36

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: systemd: Yet Another Init Replacement

WorMzy wrote:
Zom wrote:

That's pretty much wrong. AFAIK, systemd just uses some variables from rc.conf, things like hostname, while the DAEMONs part is completely skipped.

Not according to the wiki: https://wiki.archlinux.org/index.php/Sy … ntegration

DAEMONS (ordering and blacklisting is respected, if a native systemd service file by the same name as a daemon exists, it will take precedence, this logic can be disabled by 'systemctl disable arch-daemons.target')

Let me clarify. IF you have the systemd-initscripts pkg. installed AND you haven't disabled the arch-daemons.target then:

    arch-daemons.target

    Parses the DAEMONS array in rc.conf and starts the services. If a native systemd unit exists (by the same name) for a given daemon, this is used, otherwise the script in /etc/rc.d/ is used to control the unit.

As I said, I do NOT have the systemd-intscripts pkg. installed and therefore no arch-daemons.target. Without it, I don't think systemd is doing anything with daemons scripts from /etc/rc.d/. In this situation you would have to manually load the daemon with the new /sbin/rc.d script. As I said, I've tested this and am typing this with a system booted under systemd with the only line enabled in my rc.conf being the line to autoload modules. I have created a /etc/hostname file to set hostname for systemd. I have created or edited the other native systemd config files as per the mentioned wiki to enable those configs natively in systemd. Again, my DAEMONS line is double commented out, so I don't think anything is parsing it. I'll try with an rc.conf with just one active line and let you know what happens. But I can assure you, that on my system, the only thing rc.conf is doing for me now is telling some other part to autoload modules. The wiki says that systemd ignores the inittab file, but I don't know if any of the service files are calling on other sysvinit scripts or not.

UPDATE: Confirmed. My /etc/rc.conf file now has only 1 line it:  MOD_AUTOLOAD="yes" and my system boots up just fine with systemd handling everything with *.service files and *.targets and such that I used to be starting up with /etc/rc.conf and /etc/inittab. Now on to try to build a liquorix kernel again. The first attempt bombed out at the very end - a wasted hour or so of waiting. smile

Last edited by sidneyk (2011-05-18 12:18:19)

Offline

#603 2011-05-18 11:26:04

Zom
Member
From: Sweden
Registered: 2007-10-27
Posts: 430

Re: systemd: Yet Another Init Replacement

litemotiv wrote:

Actually, that's exacty what initscripts-systemd does, see https://wiki.archlinux.org/index.php/Sy … md_package

I meant systemd by itself from a stock install, not with initscripts-systemd, which was what the post i quoted seemed to assume.

E: Missed a page, apparently.

WorMzy wrote:
Zom wrote:

That's pretty much wrong. AFAIK, systemd just uses some variables from rc.conf, things like hostname, while the DAEMONs part is completely skipped.

Not according to the wiki: https://wiki.archlinux.org/index.php/Sy … ntegration

DAEMONS (ordering and blacklisting is respected, if a native systemd service file by the same name as a daemon exists, it will take precedence, this logic can be disabled by 'systemctl disable arch-daemons.target')

Yes, and what package owns arch-daemons.target?

...
initscripts-systemd /lib/systemd/system/arch-daemons.target
...

Last edited by Zom (2011-05-18 11:29:15)

Offline

#604 2011-05-18 12:29:03

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: systemd: Yet Another Init Replacement

Zom wrote:
litemotiv wrote:

Actually, that's exacty what initscripts-systemd does, see https://wiki.archlinux.org/index.php/Sy … md_package

I meant systemd by itself from a stock install, not with initscripts-systemd, which was what the post i quoted seemed to assume.

E: Missed a page, apparently.

WorMzy wrote:
Zom wrote:

That's pretty much wrong. AFAIK, systemd just uses some variables from rc.conf, things like hostname, while the DAEMONs part is completely skipped.

Not according to the wiki: https://wiki.archlinux.org/index.php/Sy … ntegration

DAEMONS (ordering and blacklisting is respected, if a native systemd service file by the same name as a daemon exists, it will take precedence, this logic can be disabled by 'systemctl disable arch-daemons.target')

Yes, and what package owns arch-daemons.target?

...
initscripts-systemd /lib/systemd/system/arch-daemons.target
...

Actually, I didn't see where your original post quoted anyone, but since it was directly after mine and dealing with the same context I assumed you were talking to me. From my original post:
"and then I installed ONLY systemd and systemd-arch-units and enabled the services and targets I needed"

No initscripts-systemd mentioned. So far I've been able to get everything except the auto loading of modules enabled from somewhere other than rc.conf. I think the only thing holding me back are the modules for my usb wireless keyboard and mouse, which apparently don't get loaded if I comment out autoloading of modules in rc.conf. I need to figure out what is needed and add the appropriate *.conf files under /etc/modules-load.d/ which is where native systemd module conf files go.

Offline

#605 2011-05-18 12:58:31

Zom
Member
From: Sweden
Registered: 2007-10-27
Posts: 430

Re: systemd: Yet Another Init Replacement

sidneyk wrote:

Actually, I didn't see where your original post quoted anyone, but since it was directly after mine and dealing with the same context I assumed you were talking to me. From my original post:
"and then I installed ONLY systemd and systemd-arch-units and enabled the services and targets I needed"

No initscripts-systemd mentioned. So far I've been able to get everything except the auto loading of modules enabled from somewhere other than rc.conf. I think the only thing holding me back are the modules for my usb wireless keyboard and mouse, which apparently don't get loaded if I comment out autoloading of modules in rc.conf. I need to figure out what is needed and add the appropriate *.conf files under /etc/modules-load.d/ which is where native systemd module conf files go.

Yeah, sorry, I thought I quoted your post but I must've misremembered.

I also missed your earlier post about not using initscripts-systemd. Strange though, since AFAIK it shouldn't care for the DAEMONs array in rc.conf.

We'll see what falconindy says.

Offline

#606 2011-05-18 13:08:59

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

sidneyk wrote:

So far I've been able to get everything except the auto loading of modules enabled from somewhere other than rc.conf. I think the only thing holding me back are the modules for my usb wireless keyboard and mouse, which apparently don't get loaded if I comment out autoloading of modules in rc.conf. I need to figure out what is needed and add the appropriate *.conf files under /etc/modules-load.d/ which is where native systemd module conf files go.

Commenting out MOD_AUTOLOAD in rc.conf has a whole different effect -- it causes /lib/udev/load-modules.sh to misbehave. This is unrelated to systemd and would illicit the same effect under sysvinit. There's plans to remove load-modules.sh now that module-init-tools offers proper module blacklisting -- you can either wait for that to happen, use udev-vanilla, or leave MOD_AUTOLOAD alone.

Offline

#607 2011-05-18 13:19:25

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: systemd: Yet Another Init Replacement

falconindy wrote:
sidneyk wrote:

So far I've been able to get everything except the auto loading of modules enabled from somewhere other than rc.conf. I think the only thing holding me back are the modules for my usb wireless keyboard and mouse, which apparently don't get loaded if I comment out autoloading of modules in rc.conf. I need to figure out what is needed and add the appropriate *.conf files under /etc/modules-load.d/ which is where native systemd module conf files go.

Commenting out MOD_AUTOLOAD in rc.conf has a whole different effect -- it causes /lib/udev/load-modules.sh to misbehave. This is unrelated to systemd and would illicit the same effect under sysvinit. There's plans to remove load-modules.sh now that module-init-tools offers proper module blacklisting -- you can either wait for that to happen, use udev-vanilla, or leave MOD_AUTOLOAD alone.

That was what I was assuming that it was effecting udev, preventing my modules for keyboard and mouse to load because that was the only thing I could see that was working before that didn't work with module autoloading disabled, but then I couldn't get logged in to check it out further. I have chosen to leave MOD_AUTOLOAD in place for now and am quite happy so far with this system. Thanks for clarifying.

Offline

#608 2011-05-18 13:29:29

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: systemd: Yet Another Init Replacement

Zom wrote:

I also missed your earlier post about not using initscripts-systemd. Strange though, since AFAIK it shouldn't care for the DAEMONs array in rc.conf.

We'll see what falconindy says.

That was kind of my point, systemd isn't doing anything with the DAEMONS array unless you have the initscripts-systemd pkg installed and have enabled the arch-daemons.target which may call other scripts, too, but long and short of it that target directs the DAEMONS array to be parsed and to either grab a native systemd service unit or to use the corresponding rc.d script if none exist. I currently have no DAEMONS array in my rc.conf, but I do have enabled the appropriate service and target units that call everything up just fine.

Last edited by sidneyk (2011-05-18 13:30:21)

Offline

#609 2011-05-18 14:22:45

Zom
Member
From: Sweden
Registered: 2007-10-27
Posts: 430

Re: systemd: Yet Another Init Replacement

sidneyk wrote:

That was kind of my point, systemd isn't doing anything with the DAEMONS array unless you have the initscripts-systemd pkg installed and have enabled the arch-daemons.target which may call other scripts, too, but long and short of it that target directs the DAEMONS array to be parsed and to either grab a native systemd service unit or to use the corresponding rc.d script if none exist. I currently have no DAEMONS array in my rc.conf, but I do have enabled the appropriate service and target units that call everything up just fine.

Oh, okay then I completely misunderstood your post. Sorry! smile

Offline

#610 2011-05-18 14:41:38

PReP
Member
From: Sweden
Registered: 2010-06-13
Posts: 359
Website

Re: systemd: Yet Another Init Replacement

I am wondering  a bit about this might-be-replacement.
I have read some of this thread, and a semi-heated discussion on the mailing list.

What i have not gotten an impression of yet, is why one would need systemd as opposed to the simple, and from all my time on arch, stable init and deamon-style we already have,
what is the reasoning, and what are the critically needed benefits of systemd in reality?

1. Performance?,

Is something i do not buy in to, mostly because the latest year or two (or more) i have not feelt nr-of-seconds-to-boot have any tangible differences.
I see no troublesome delay as it is now, from grub to login, it just breezes trough my daemons start.

I can boot, scratch my back, and the system is booted - so faster booting is not needed as i see it (i am speaking for me)
Neither my current system: i5 2500k @ 3.5 ghz, nor my pentium 4 @ 2.8 ghz, has any particular delay in booting these days.

2.Stability?,

This probably differs for different system, as software and stuff always does - but i have had no issues with stability with booting or init or the easy daemon start and stop system to this date, atleast.

3. Simplicity?,

I find the current init-system very nice to work with, as a user of my own computer, fast and manageable,
from what i have read, i see more work getting systemd going, and it feels to abstract away a bit, put more things between me and my system?

Though perhaps there are different views on this, i don't use dbus, or "ck-launch-session" or such things either,
I find setting my partitions up in /etc/fstab to be quick and painless (though that is probably not the main and sole scope of this new initsystem)

And i mostly just set up as little things and have as little stuff as possible, i just need to access and simply use my arch setup, and that works splendidly.

4. Need?

I think this is what my main question boils down too, for what does one need systemd?

I am neither bashing nor complaining, i am just curious of everyones take on this. smile


. Main: Intel Core i5 6600k @ 4.4 Ghz, 16 GB DDR4 XMP, Gefore GTX 970 (Gainward Phantom) - Arch Linux 64-Bit
. Server: Intel Core i5 2500k @ 3.9 Ghz, 8 GB DDR2-XMP RAM @ 1600 Mhz, Geforce GTX 570 (Gainward Phantom) - Arch Linux 64-Bit
. Body: Estrogen @ 90%, Testestorone @ 10% (Not scientific just out-of-my-guesstimate-brain)

Offline

#611 2011-05-18 14:46:28

wonder
Developer
From: Bucharest, Romania
Registered: 2006-07-05
Posts: 5,941
Website

Re: systemd: Yet Another Init Replacement

@PReP add in your list obligated. systemd was just proposed as dependency for gnome 3.2


Give what you have. To someone, it may be better than you dare to think.

Offline

#612 2011-05-18 15:10:33

nordmoen
Member
Registered: 2010-09-25
Posts: 37

Re: systemd: Yet Another Init Replacement

PReP wrote:

1. Performance?,

On my laptop with an SSD I have noticed much better(might be a couple of secounds) boot times

PReP wrote:

2.Stability?,

I have noticed some problems, but if Arch adopted systemd it would be better

PReP wrote:

3. Simplicity?,

systemctl enable gdm.service

and nothing more was needed for me to get Gnome up, then just add what you need

Offline

#613 2011-05-18 17:08:24

PReP
Member
From: Sweden
Registered: 2010-06-13
Posts: 359
Website

Re: systemd: Yet Another Init Replacement

nordmoen wrote:
PReP wrote:

1. Performance?,

On my laptop with an SSD I have noticed much better(might be a couple of secounds) boot times

PReP wrote:

2.Stability?,

I have noticed some problems, but if Arch adopted systemd it would be better

PReP wrote:

3. Simplicity?,

systemctl enable gdm.service

and nothing more was needed for me to get Gnome up, then just add what you need

1: Well my point was that even my pentium 4, does not take much time in the init-part of the booting, nor firing up the daemons,
    And the difference between that and my new core i5 2500k is very small aswell.

   The point is that boot time is very fast already, and that i stopped giving though to it these last year, 1-5 secs here and there
   before using the system smile

2: I didn't say anything about systemd stability, but i said that the current system in arch has not had any stability issues.

3: I find the current system simple and usable to say the least, i don't know about systemd that much, so i cannot say anything there
   - just that it feels further from simplicity then stuff does right now. smile
   
   I run openbox though.


. Main: Intel Core i5 6600k @ 4.4 Ghz, 16 GB DDR4 XMP, Gefore GTX 970 (Gainward Phantom) - Arch Linux 64-Bit
. Server: Intel Core i5 2500k @ 3.9 Ghz, 8 GB DDR2-XMP RAM @ 1600 Mhz, Geforce GTX 570 (Gainward Phantom) - Arch Linux 64-Bit
. Body: Estrogen @ 90%, Testestorone @ 10% (Not scientific just out-of-my-guesstimate-brain)

Offline

#614 2011-05-18 17:09:34

PReP
Member
From: Sweden
Registered: 2010-06-13
Posts: 359
Website

Re: systemd: Yet Another Init Replacement

wonder wrote:

@PReP add in your list obligated. systemd was just proposed as dependency for gnome 3.2

Obligated, oh damn. smile

I don't run gnome myself though, and if they need yet another dependency for gnome, then i guess a _gnome_ dependency it is smile

-------------------------------

Last edited by PReP (2011-05-18 17:17:35)


. Main: Intel Core i5 6600k @ 4.4 Ghz, 16 GB DDR4 XMP, Gefore GTX 970 (Gainward Phantom) - Arch Linux 64-Bit
. Server: Intel Core i5 2500k @ 3.9 Ghz, 8 GB DDR2-XMP RAM @ 1600 Mhz, Geforce GTX 570 (Gainward Phantom) - Arch Linux 64-Bit
. Body: Estrogen @ 90%, Testestorone @ 10% (Not scientific just out-of-my-guesstimate-brain)

Offline

#615 2011-05-18 17:09:42

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: systemd: Yet Another Init Replacement

I agree with the above. I think most of the seeming trouble in the thread comes from misunderstanding and perhaps expecting it to be more complex. Once the understanding kicks in it's a breeze. Systemd is intended to try and get rid of the many slow bash scripts being used to get the system going now. To Arch people it seems they tend to see only rc.conf, which is really only holding variables to pass to the other scripts, and think simple because they're not worrying about what's going on under the hood, so to speak. Some realize faster bootup with systemd, there seems to better response in my Gnome 3 system. Most of the stuff of systemd is under the hood also, but it's compiled C code instead of slow scripts. It is able to start and stop and reload daemons and keeps better track of them, not letting forked processes escape. I'd recommend reading the developer's blog and searching for some of the videos where he presents the breakdown and explains it. I did and it really helped me to see that I was over complicating it in my own mind.

Last edited by sidneyk (2011-05-18 17:53:21)

Offline

#616 2011-05-18 17:17:44

PReP
Member
From: Sweden
Registered: 2010-06-13
Posts: 359
Website

Re: systemd: Yet Another Init Replacement

On another note, and this is not based on me knowing the inner workings of systemd, just as a slight hunch:

I have been working with different windows systems for a long time, both personally and for helping other people.


My take on windows is that they build up this very bulky system, with the services and the registry (which is an horrible crows nest to me)
They make it do everything per default - just in case some person needs this and that. (they even have a service running per default to "track links to ntfs-files over the network so that they don't get obsolete". as an example)

When setting up windows for myself, what i need to do is remove, configure, fix, mend, and take away all these things i actually do not need personally.
Compared to arch when i just, choose and configure the parts i need from the start.

To me, this is the big difference which has made me use Linux, and in the extent, Arch for my daily, 95% use of my computer.

And to me, starting with little, fetching the vital functions, takes much less time than working, cleaning and tidying up from a cluttered enviroment.

Point of this little comparison, some things (perhaps systemd?) feels just like that, trying to work in too much - as a default smile


. Main: Intel Core i5 6600k @ 4.4 Ghz, 16 GB DDR4 XMP, Gefore GTX 970 (Gainward Phantom) - Arch Linux 64-Bit
. Server: Intel Core i5 2500k @ 3.9 Ghz, 8 GB DDR2-XMP RAM @ 1600 Mhz, Geforce GTX 570 (Gainward Phantom) - Arch Linux 64-Bit
. Body: Estrogen @ 90%, Testestorone @ 10% (Not scientific just out-of-my-guesstimate-brain)

Offline

#617 2011-05-18 17:31:44

litemotiv
Forum Fellow
Registered: 2008-08-01
Posts: 5,026

Re: systemd: Yet Another Init Replacement

PReP wrote:

   The point is that boot time is very fast already, and that i stopped giving though to it these last year, 1-5 secs here and there
   before using the system smile

That's a philosophical problem, when is 'good' good enough?

And as sidneyk said, you really need to look under the hood of Arch's current init system to see what it really does, and which scripts are invoked to accomplish what you see as a user. In general though, the Simplicity in Arch is not focused on end users per sé, but rather on system elegance.


ᶘ ᵒᴥᵒᶅ

Offline

#618 2011-05-18 17:35:44

sidneyk
Member
From: Bonner Springs, KS. USA
Registered: 2011-04-22
Posts: 129

Re: systemd: Yet Another Init Replacement

Yesterday I was playing around and experimenting in Virtual Box on my Windows 7 install. I set up Arch x86_64 with the base and base-devel just like when I installed it for real. I then installed systemd and the arch-units pkg before installing xorg or Gnome or anything else beyond whatever got pulled in with systemd and the arch-units and I don't remember it pulling that much, if any extra in. That vm booted in 2 seconds and since it was only starting in an equivalent mode to run level 3, then systemd was only managing what needed to be managed for that scenario, nothing more. It was very robust and easy to forget that it was a vm. Agreed, when you add complexity with graphical environments and sound and desktops and hotplugging of devices, etc, etc. then things start piling up pretty quick. MS Windows is a very good example of that. I think systemd is much more flexible than MS Windows, even in a graphical environment. Yes, systemd supposedly defaults to what would be run level 5 (booting into x) but it is very simple to change that from the start. :

systemctl enable multi-user.target.

I get what you are saying about controlling what's going on and how much of it. That's what I believe sytemd brings to the table, it gives much better control over all the background things that are going on which we didn't have before. There's no more starting multiple instances of things anymore and forking here and there. The processes are tracked better and controlled so they can't escape and become difficult to track down when they misbehave. Again, if you're into that kind of stuff, the technical background and reasoning makes a lot of sense.

Last edited by sidneyk (2011-05-18 17:44:38)

Offline

#619 2011-05-18 21:03:51

PReP
Member
From: Sweden
Registered: 2010-06-13
Posts: 359
Website

Re: systemd: Yet Another Init Replacement

I do understand a bit of what systemd is supposed to do, and i appreciate all the info and response. smile

1.

I read up a bit more on the authors blog, and one of the first things in the explanation was also: "Unfortunately, the traditional SysV init system was not particularly fast."

This is were i am most confunded, since i don't see where the system is slow today.
To re-iterate a bit then, by making some sort of scenario:

Say it takes me 10-12 seconds to boot up my system today,
In the world of sensibility, what would this, not often occuring, boot give me if it was say 3-8 seconds?
My point is just that the "boot faster faster faster"-part is not real world tangible; perhaps for a system that needs to boot x times every hour or so, i don't know, or someone really impatient.

That is just the speed-part, and just because that is the most i hear of when people seem (even the authour of systemd in parts) to respond as to why we need it.

2

Another quotation:

"Most current systems that try to parallelize boot-up still synchronize the start-up of the various daemons involved: since Avahi needs D-Bus, D-Bus is started first, and only when D-Bus signals that it is ready, Avahi is started too. Similar for other services: livirtd and X11 need HAL (well, I am considering the Fedora 13 services here, ignore that HAL is obsolete)"

I must confess that it might just be me, but i have seen little need for Avahi, I was glad to skip HAL a while back, I didn't fancy udisk since i find having my external drives set in fstab works fine, having a simple alias to "mount / umount this that", which can be executed from a button on the graphical side, or just in the terminal as i usually do.
I have also been wondering about dbus.

To me, most of these things, i only see as dependencies for various programs i use, though i don't now about my own need for them.
I just did a little check on dbus while reading up on things:

~ -> sudo pacman -R dbus

:: avahi: requires dbus
:: qt: requires dbus
:: xfconf: requires dbus

    ~ -> sudo pacman -R avahi
   
     :: libcups: requires avahi   

      sudo pacman -R libcups  # (well i don't use a printer, but i certainly wouldn't say that is something the world shares with me, i'm not silly smile)

      :: gtk2: requires libcups
      :: gtk3: requires libcups

   ------- Here it was ^ --------

gtk.,

which obviously is needed by a lot of things, and i won't go into one of the classical and tirering "gtk or qt or deps" debate, i'll just say that this feels a bit annoying.
i certainly don't need the gtk programs i use to configure my network, and i do not need to print with them either since i don't have a printer
But still, somehow, these things end up "needed" as dependencies.

3. Conclusions, again, but revised (perhaps smile)

Other than 'speed', the idea with systemd seems to be starting and stopping of servi.. i mean daemons... on demand?

I just feel that, this is what is already happening,
though i don't have big needs on daemons for starters,
this is my daemons line: DAEMONS=(!hwclock syslog-ng network !netfs crond sshd httpd alsa !dbus)

Some are inactivated but have been kept in case, don't have nfs shares to mount anymore, and dbus i am still trying to figure out personally. (the why, that is, and for me)
And i don't see them running and being a heavy strain or encumbering my system to date neither.

If i need a daemon, i would just do: /etc/rc.d/xxxx start - which frankly don't take up much of my time at all.
Or use the new rc script, though i haven't gotten used to that yet, even if it is less typing and i sort of like it.


I am mostly just afraid of things coming needlessly less simple, though perhaps in the future, or when i have learnt more, systemd would be simpler?

PReP is a friendly sceptic, and thinks a lot, that is all smile


. Main: Intel Core i5 6600k @ 4.4 Ghz, 16 GB DDR4 XMP, Gefore GTX 970 (Gainward Phantom) - Arch Linux 64-Bit
. Server: Intel Core i5 2500k @ 3.9 Ghz, 8 GB DDR2-XMP RAM @ 1600 Mhz, Geforce GTX 570 (Gainward Phantom) - Arch Linux 64-Bit
. Body: Estrogen @ 90%, Testestorone @ 10% (Not scientific just out-of-my-guesstimate-brain)

Offline

#620 2011-05-18 21:18:30

Glaucous
Member
Registered: 2010-11-06
Posts: 41

Re: systemd: Yet Another Init Replacement

litemotiv and falconindy; I finally fixed the automount problem which we talked about on page 23, 24. The fix was actually very simple (and makes sense). I mounted all my partitions using 'defaults,comment=systemd.automount', however, 'defaults' implies 'auto', which meant that the partition is always mounted at boot, so all I needed to do was to add 'noauto'.  Now they're not mounted at boot, and mounted automatically when accessed.

A thought though, how does fsck work with autofs?

Last edited by Glaucous (2011-05-18 21:20:36)

Offline

#621 2011-05-18 21:38:25

litemotiv
Forum Fellow
Registered: 2008-08-01
Posts: 5,026

Re: systemd: Yet Another Init Replacement

Glaucous wrote:

litemotiv and falconindy; I finally fixed the automount problem which we talked about on page 23, 24. The fix was actually very simple (and makes sense). I mounted all my partitions using 'defaults,comment=systemd.automount', however, 'defaults' implies 'auto', which meant that the partition is always mounted at boot, so all I needed to do was to add 'noauto'.  Now they're not mounted at boot, and mounted automatically when accessed.

Ah that's good, thanks for the heads-up. smile

@PRep, you're straying a bit offtopic. systemd is just a new init system, faster and more feature rich, while still trying to be elegant and easily maintainable. My grandmother is still puzzled why we even need pc's in the first place.


ᶘ ᵒᴥᵒᶅ

Offline

#622 2011-05-18 21:55:22

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 7,358

Re: systemd: Yet Another Init Replacement

Also, on the matter of boot times, its great you have 10-12 seconds, but this laptop used to take 1 minutes 50 seconds on Gnome (now 1 minute 15 seconds on Awesome), so that DOES make quite a bit of difference when that's improved. Of course, I just use hibernate, but that's besides the point smile.

Both speeds are sans systemd, I've gone back to sysvinit for now (more familiar).


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

#623 2011-05-18 22:43:50

hauzer
Member
From: Belgrade, Serbia
Registered: 2010-11-17
Posts: 279
Website

Re: systemd: Yet Another Init Replacement

Is systemd still unusable with a separate /usr (/var?) partition?


Vanity of vanities, saith the Preacher, vanity of vanities; all is vanity.
What profit hath a man of all his labour which he taketh under the sun?
All the rivers run into the sea; yet the sea is not full; unto the place from whence the rivers come, thither they return again.
For in much wisdom is much grief: and he that increaseth knowledge increaseth sorrow.

Offline

#624 2011-05-18 22:44:54

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

Separate /var is fine. It will never support separate /usr.

Offline

#625 2011-05-18 23:01:45

hauzer
Member
From: Belgrade, Serbia
Registered: 2010-11-17
Posts: 279
Website

Re: systemd: Yet Another Init Replacement

I see.


Vanity of vanities, saith the Preacher, vanity of vanities; all is vanity.
What profit hath a man of all his labour which he taketh under the sun?
All the rivers run into the sea; yet the sea is not full; unto the place from whence the rivers come, thither they return again.
For in much wisdom is much grief: and he that increaseth knowledge increaseth sorrow.

Offline

Board footer

Powered by FluxBB