systemd: Yet Another Init Replacement

falconindy · 2011-06-03 19:03:34

hda-codec: no NID mapping control independent hp:0:0

Not systemd-related. Seems harmless and you confirm that everything works. Not sure why you're pointing this out.

You seem to misunderstand of how module loading works. In short, you don't need to do anything. Modules will still be detected and loaded by udev on boot. If you have a need for specific other modules that udev does not load on boot (such as those you might put in the MODULES array in /etc/rc.conf), then you want to add those in config files in /etc/module-load.d.

In the future, please use code tags, not quote tags when posting output.

cuihao · 2011-06-05 01:35:40

My systemd does not work now. getty cannot start:
2011-06-05T09:01:49+08:00 localhost systemd[1]: Job dev-tty6.device/start timed out.

Before this, I try making systemd work while using aufs usr and it works.
Yesterday, I gave up and moved usr back. Then systemd doesn't work any more.

/sbin/init works well.

falconindy · 2011-06-05 01:44:20

You cannot have /usr on a separate filesystem. This is very clear on the wiki and has been mentioned several times in this thread.

Last edited by falconindy (2011-06-05 02:11:03)

cuihao · 2011-06-05 03:31:13

falconindy wrote:

You cannot have /usr on a separate filesystem. This is very clear on the wiki and has been mentioned several times in this thread.

I mean:
When I use /usr on a separate filesystem, systemd worked (I copy the dbus libraries to /lib).
But when I use original /usr on root filesystem , it failed.

sonay · 2011-06-05 06:40:23

falconindy wrote:

hda-codec: no NID mapping control independent hp:0:0
Not systemd-related. Seems harmless and you confirm that everything works. Not sure why you're pointing this out.
You seem to misunderstand of how module loading works. In short, you don't need to do anything. Modules will still be detected and loaded by udev on boot. If you have a need for specific other modules that udev does not load on boot (such as those you might put in the MODULES array in /etc/rc.conf), then you want to add those in config files in /etc/module-load.d.
In the future, please use code tags, not quote tags when posting output.

I pointed that out because with sysV, I didn't had that message. And I am wondering why this is coming out during boot.

For the modules, if I don't add those files, udev does not detect my keyboard and my touchpad. I didn't know where else to ask, because all these problems started to occur, just after moving to systemd. I hope this makes sense for you.

By the way, since hardware clock is deprecated (I don't remember where I read), how do you keep your time correct? Mine is 3 hours back, since last night.

(Sorry for my English, I am not native.)

bharani · 2011-06-05 09:54:52

I have a problem with systemd now
Using systemctl i can start/stop/status sensors.service but if run enable/ disbale then it says that the service is not found

┤03:16 PM|$├1─> sudo systemctl  start  sensors.service

┤03:20 PM|$├─> sudo systemctl  status  sensors.service
sensors.service - SYSV: sensors is used for monitoring motherboard sensor values.
      Loaded: loaded (/etc/rc.d/sensors)
      Active: active (running) since Sun, 05 Jun 2011 15:16:42 +0530; 4min 12s ago
     Process: 2216 ExecStop=/etc/rc.d/sensors stop (code=exited, status=0/SUCCESS)
     Process: 2270 ExecStart=/etc/rc.d/sensors start (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/sensors.service

┤03:20 PM|$├─> sudo systemctl  enable  sensors.service
Couldn't find sensors.service.

Please help me.
Thanks.

falconindy · 2011-06-05 12:21:05

bharani wrote:

I have a problem with systemd now
Using systemctl i can start/stop/status sensors.service but if run enable/ disbale then it says that the service is not found

┤03:16 PM|$├1─> sudo systemctl  start  sensors.service

┤03:20 PM|$├─> sudo systemctl  status  sensors.service
sensors.service - SYSV: sensors is used for monitoring motherboard sensor values.
      Loaded: loaded (/etc/rc.d/sensors)
      Active: active (running) since Sun, 05 Jun 2011 15:16:42 +0530; 4min 12s ago
     Process: 2216 ExecStop=/etc/rc.d/sensors stop (code=exited, status=0/SUCCESS)
     Process: 2270 ExecStart=/etc/rc.d/sensors start (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/sensors.service

┤03:20 PM|$├─> sudo systemctl  enable  sensors.service
Couldn't find sensors.service.

Please help me.
Thanks.

1) You can't enable the service if it doesn't exist in the form of a .service file. systemd will scrape /etc/rc.d for scripts and allow you to start/stop daemons via systemctl.
2) The sensors "daemon" does nothing but load/unload modules. I suggest figuring out what modules you need and instead just loading those modules at boot.

falconindy · 2011-06-05 12:24:38

sonay wrote:

falconindy wrote:
hda-codec: no NID mapping control independent hp:0:0
Not systemd-related. Seems harmless and you confirm that everything works. Not sure why you're pointing this out.
You seem to misunderstand of how module loading works. In short, you don't need to do anything. Modules will still be detected and loaded by udev on boot. If you have a need for specific other modules that udev does not load on boot (such as those you might put in the MODULES array in /etc/rc.conf), then you want to add those in config files in /etc/module-load.d.
In the future, please use code tags, not quote tags when posting output.
I pointed that out because with sysV, I didn't had that message. And I am wondering why this is coming out during boot.

I have no idea what it means. I'm still doubtful that it's systemd related. Scour dmesg for this while booting off /sbin/init. Either way, google is your friend.

sonay wrote:

For the modules, if I don't add those files, udev does not detect my keyboard and my touchpad. I didn't know where else to ask, because all these problems started to occur, just after moving to systemd. I hope this makes sense for you.

Then like I said, create conf files in /etc/modules-load.d so those modules are loaded on boot.

sonay wrote:

By the way, since hardware clock is deprecated (I don't remember where I read), how do you keep your time correct? Mine is 3 hours back, since last night.
(Sorry for my English, I am not native.)

Hardware Clock is not deprecated. Running it in localtime is discouraged, but still supported. UTC Is preferred. Sounds like your time zone isn't being honored. hwclock --systz --utc.

falconindy · 2011-06-05 12:25:53

cuihao wrote:

falconindy wrote:
You cannot have /usr on a separate filesystem. This is very clear on the wiki and has been mentioned several times in this thread.
I mean:
When I use /usr on a separate filesystem, systemd worked (I copy the dbus libraries to /lib).
But when I use original /usr on root filesystem , it failed.

I don't know what you broke, but if it worked before and now it doesn't, you broke something. There's way too many people drinking the squashed /usr koolaid. It's complete crap.

kritter · 2011-06-05 13:00:07

Hey guys. Am I the only one who does not like to enter every passphrase for ever LUKS device on my system? Seems like the scripts mentioned by the article can not parse /etc/crypttab. Anyone who's written some fix for this or who has a clue how to write a new service file?

This is the only issue I found testing systemd some minutes ago, seems good to me.

falconindy · 2011-06-05 13:15:48

systemd follows the debian /etc/crypttab format. The third field is the path to a keyfile, not a password itself. It's not broken, just different from how Arch does it. IMO, the Arch format allowing plaintext passwords to be stored in /etc/crypttab is what's broken.

bharani · 2011-06-05 14:26:01

falconindy wrote:

1) You can't enable the service if it doesn't exist in the form of a .service file. systemd will scrape /etc/rc.d for scripts and allow you to start/stop daemons via systemctl.
2) The sensors "daemon" does nothing but load/unload modules. I suggest figuring out what modules you need and instead just loading those modules at boot.

Thanks falconindy. I have found and added the module to /etc/modules-load.d.

pogeymanz · 2011-06-05 21:12:21

falconindy wrote:

There's way too many people drinking the squashed /usr koolaid. It's complete crap.

I know this is completely off topic, but can you elaborate or point me towards something to back that up? In principle the squashed /usr thing makes sense since our hard drives are big bottle-necks for performance, so reading less data off of them seems like a good idea. Why wouldn't that be true?

falconindy · 2011-06-05 21:32:33

Putting aside the fact that more and more distros will not support /usr on a separate partition, you're compressing mostly binaries -- they don't compress well. It also opens up multiple points of failure:

- what if it doesn't mount and you don't notice? Chances are, your old /usr is still there and full of old junk. Worse, what if the squashed FS becomes corrupted? There's no fsck for squashfs.
- how often do you recompress? You can't feasibly do this from outside runlevel 1, and its also impossible to do cleanly under systemd. If your system changes a lot (hi, rolling release), you lose a lot of the benefit, and recompressing is a pain in the neck.
- the aufs2 maintainer is getting slower and slower to update for each kernel release. He does not yet know when 2.6.39 support will be available. This is a really crappy reason to hold back a kernel update.
- how much I/O are you really saving? with ~500 packages installed, my /usr is 2GB. The commonly used binaries are pretty much immediately cached in memory and then it doesn't matter how compressed they are.

I did this long ago. It was not, imo, worth the hassle.

sonay · 2011-06-05 22:19:30

falconindy wrote:

sonay wrote:
falconindy wrote:
hda-codec: no NID mapping control independent hp:0:0
Not systemd-related. Seems harmless and you confirm that everything works. Not sure why you're pointing this out.
You seem to misunderstand of how module loading works. In short, you don't need to do anything. Modules will still be detected and loaded by udev on boot. If you have a need for specific other modules that udev does not load on boot (such as those you might put in the MODULES array in /etc/rc.conf), then you want to add those in config files in /etc/module-load.d.
In the future, please use code tags, not quote tags when posting output.
I pointed that out because with sysV, I didn't had that message. And I am wondering why this is coming out during boot.
I have no idea what it means. I'm still doubtful that it's systemd related. Scour dmesg for this while booting off /sbin/init. Either way, google is your friend.
sonay wrote:
For the modules, if I don't add those files, udev does not detect my keyboard and my touchpad. I didn't know where else to ask, because all these problems started to occur, just after moving to systemd. I hope this makes sense for you.
Then like I said, create conf files in /etc/modules-load.d so those modules are loaded on boot.
sonay wrote:
By the way, since hardware clock is deprecated (I don't remember where I read), how do you keep your time correct? Mine is 3 hours back, since last night.
(Sorry for my English, I am not native.)
Hardware Clock is not deprecated. Running it in localtime is discouraged, but still supported. UTC Is preferred. Sounds like your time zone isn't being honored. hwclock --systz --utc.

Thanks for the help and your great effort to bring systemd to us, everything is OK now.

bwat47 · 2011-06-06 13:50:57

I have a question. I am using kernel26-ck with the bfs scheduler. The wiki pages for systemd says it uses cgroups, but bfs does not implement these. Does this mean systemd does not work with this kernel?

falconindy · 2011-06-06 13:53:39

One way to find out

spoiler alert: it works.

bwat47 · 2011-06-06 13:57:35

Alright thanks. One more question. I am using inittab to start gnome. The wiki says systemd does not use inittab at all. Do I have to switch to xinitrc to start gnome if I use systemd?

falconindy · 2011-06-06 17:10:22

Please read the fine wiki page on systemd.

eworm · 2011-06-10 08:55:00

falconindy wrote:

The wiki already mentions this. If anything, the wiki should merely refer people to the man page to let them figure out what options make sense for their setup. I personally prefer the default behavior, as the man page also mentions:
Note that setting kill-user=1 or even kill-session=1 will break tools like screen(1)

I have a little 'workaround' for this problem... I have scripts that create a new cgroup "name=systemd:/tmux/${USER}" and then launches tmux within this cgroup. Works perfectly so far, even with kill-user=1 or kill-session=1. Get the packages here:

http://arch.lugor.de/eworm/x86_64/libcg … pkg.tar.xz (or from AUR)
http://arch.lugor.de/eworm/x86_64/tmux- … pkg.tar.xz

Viper_Scull · 2011-06-10 11:02:49

With the latest updates when i restart or shut down the machine the system freezes for about a minute and then it continues.

I've booted without the quiet parameter to see which service was causing this behavior. The last line i could read before the freeze is "Stopped Permit User Sessions". Then after a minute o minute and a half it goes on but i dont have enough time to read the first line.

What comes after Stopped Permit User Sessions? Or at least is there a way pressing some key to make it go line by line to be able to read it?

Last edited by Viper_Scull (2011-06-10 11:47:54)

adrianx · 2011-06-10 13:03:40

@Viper_Scull

The same thing happened to me. In my case, there were broken links in /etc/systemd/system/...

One of them was networkmanager.service. I deleted the broken links and for NetworkManager, did a "systemctl enable NetworkManager.service".

I had to do the same for cups.

Last edited by adrianx (2011-06-10 13:05:48)

Arm-the-Homeless · 2011-06-10 15:40:51

Haven't yet switched to this so I have a few questions...
First off, is it pretty much just a drop-in replacement? As in I don't need to configure tons of stuff?

James_Eder · 2011-06-10 16:10:25

Arm-the-Homeless wrote:

Haven't yet switched to this so I have a few questions...
First off, is it pretty much just a drop-in replacement? As in I don't need to configure tons of stuff?

https://wiki.archlinux.org/index.php/Systemd

How much you configure is up to you, but to get the most out of systemd there is a fair amount of configuring you can do. The Wiki page is a great place to start and there's a lot of great documentation linked to at the bottom of the article.

As the Wiki article points out, you can install systemd side by side with Arch's default init system and you can switch between them at boot with the appropriate grub configuration. So, there's not a lot of risk in just trying it out, but do help yourself to the fine documentation.

jnguyen · 2011-06-11 12:49:13

Many thanks falconindy for your quality systemd packages.

Using systemd and it's own readahead implementation (which couldn't be simpler to setup), the time from entering my LUKS key to having firefox open has been halved from 20 seconds to 10 seconds, and that's on a regular HDD (not SSD)

For anyone who has LUKS system encryption, this bug report may be relevant to you. /etc/rc.conf is parsed by mkinitcpio for KEYMAP, and I proposed a patch to make mkinitcpio parse /etc/vconsole.conf instead if it exists. I was puzzled for quite a while when my LUKS key wasn't accepted

Arch Linux

#701 2011-06-03 19:03:34

Re: systemd: Yet Another Init Replacement

#702 2011-06-05 01:35:40

Re: systemd: Yet Another Init Replacement

#703 2011-06-05 01:44:20

Re: systemd: Yet Another Init Replacement

#704 2011-06-05 03:31:13

Re: systemd: Yet Another Init Replacement

#705 2011-06-05 06:40:23

Re: systemd: Yet Another Init Replacement

#706 2011-06-05 09:54:52

Re: systemd: Yet Another Init Replacement

#707 2011-06-05 12:21:05

Re: systemd: Yet Another Init Replacement

#708 2011-06-05 12:24:38

Re: systemd: Yet Another Init Replacement

#709 2011-06-05 12:25:53

Re: systemd: Yet Another Init Replacement

#710 2011-06-05 13:00:07

Re: systemd: Yet Another Init Replacement

#711 2011-06-05 13:15:48

Re: systemd: Yet Another Init Replacement

#712 2011-06-05 14:26:01

Re: systemd: Yet Another Init Replacement

#713 2011-06-05 21:12:21

Re: systemd: Yet Another Init Replacement

#714 2011-06-05 21:32:33

Re: systemd: Yet Another Init Replacement

#715 2011-06-05 22:19:30

Re: systemd: Yet Another Init Replacement

#716 2011-06-06 13:50:57

Re: systemd: Yet Another Init Replacement

#717 2011-06-06 13:53:39

Re: systemd: Yet Another Init Replacement

#718 2011-06-06 13:57:35

Re: systemd: Yet Another Init Replacement

#719 2011-06-06 17:10:22

Re: systemd: Yet Another Init Replacement

#720 2011-06-10 08:55:00

Re: systemd: Yet Another Init Replacement

#721 2011-06-10 11:02:49

Re: systemd: Yet Another Init Replacement

#722 2011-06-10 13:03:40

Re: systemd: Yet Another Init Replacement

#723 2011-06-10 15:40:51

Re: systemd: Yet Another Init Replacement

#724 2011-06-10 16:10:25

Re: systemd: Yet Another Init Replacement

#725 2011-06-11 12:49:13

Re: systemd: Yet Another Init Replacement

Board footer