systemd: Yet Another Init Replacement

litemotiv · 2011-05-06 14:52:48

falconindy wrote:

systemd integrates heavily with autofs, why not just use that?

Hmm well i'm basically only using autofs to mount a bunch of remote sshfs shares, is there a more or less native way to do that with systemd?

falconindy · 2011-05-06 14:55:57

That's exactly the point! Add the mounts to your fstab and make sure they have the mount option 'comment=systemd.automount'

litemotiv · 2011-05-06 15:42:01

falconindy wrote:

That's exactly the point! Add the mounts to your fstab and make sure they have the mount option 'comment=systemd.automount'

Splendid! Another happy customer, next!

bwat47 · 2011-05-07 00:18:01

Is there any proper guides to setting up systemd on arch, like configuring and migrating all the settings from your rc.conf ect... to it properly? I am a bit of a n00b to arch and the wiki page for systemd just has me a bit confused. (and what's all this amount mounts!)

The only things I've changed in rc.conf is added acpi-cpufreq to modules, and added cpufreq, laptop-mode, networkmanager, dbus and gdm to daemons. I was able to set up arch and gnome 3 easily enough but for some reason this leaves me confused lol.

I just want to make sure I can install it and configure it to boot my current working gnome 3 desktop properly. Before I install it

Last edited by bwat47 (2011-05-07 00:24:27)

bwat47 · 2011-05-07 02:16:28

Ok I installed systemd and added it to grub and it seemed to work, but I don't know if its working correctly. For example if I run systemctl I get this:

[brandon@brandon-laptop ~]$ systemctl
Failed to issue method call: Launch helper exited with unknown return code 1

or [brandon@brandon-laptop ~]$ sudo systemctl
Failed to get D-Bus connection: Failed to connect to socket /org/freedesktop/systemd1/private: Connection refused
[brandon@brandon-laptop ~]$

it does this with all the systemctl commands

Last edited by bwat47 (2011-05-07 02:20:12)

falconindy · 2011-05-07 02:46:41

Then no, it's not working properly. You usually get those kinds of messages when you're not actually booting with systemd.

bwat47 · 2011-05-07 02:57:39

hmm I've installed initscripts-systemd and systemd-arch-units, and then added it to my grub kernel line like this:

kernel /boot/vmlinuz26 root=/dev/disk/by-uuid/106f9d02-32de-49ac-af29-9b8eae05e6d3 ro
initrd /boot/kernel26.img init=/bin/systemd

any idea what I could be doing wrong?

falconindy · 2011-05-07 03:06:39

Yes. You added the init parameter to the wrong line.

bwat47 · 2011-05-07 03:13:13

alright I fixed that, this time it definitely booted with systemd but gdm never opened, I just got a bunch of errors about trying to open gdm (not sure exactly what they said, is there a log with this info?) It just kept repeating the errors and I couldn't do anything like log in with cli, had to power off my machine.

Anything else I could be doing wrong? I tried systemctl enable gdm.service but that didn't have any effect.

Last edited by bwat47 (2011-05-07 03:22:10)

falconindy · 2011-05-07 03:48:27

There's an awful lot of documentation between the wiki and this thread and a real lack of useful information in your post.

Last edited by falconindy (2011-05-07 03:49:43)

bwat47 · 2011-05-07 04:20:02

Alright I got it to boot, it didn't like something in my fstab . Haven't seen a really noticeable decrease in boot time though, but I was already getting < 20 seconds. I am getting around 17-18 now. Pretty good for a 5400rpm drive.

Last edited by bwat47 (2011-05-07 04:41:51)

eDio · 2011-05-07 10:04:35

I just tried systemd and experienced the following problem:
on each boot clock is set to -2 hours. So, for example, I've booted 3 times, and now clock shows -6 hours from actual time.

EDIT:
Something much more weird happens:

# hwclock
Sat 07 May 2011 07:12:21 AM EEST  -0.196004 seconds

# date
Sat May  7 04:12:54 EEST 2011

I'm in GMT+2, Europe/Kiev (defined in rc.conf)
Here are my active targets:

./default.target.wants:
systemd-readahead-collect.service@  systemd-readahead-replay.service@

./getty.target.wants:
getty@tty1.service@  getty@tty2.service@  getty@tty3.service@  getty@tty4.service@  getty@tty5.service@  getty@tty6.service@

./graphical.target.wants:
console-kit-daemon.service@  kdm.service@

./local-fs.target.wants:

./multi-user.target.wants:
arch-daemons.target@  rc-local.service@  remote-fs.target@

./shutdown.target.wants:
arch-persistent-settings.service@

./sysinit.target.wants:
hwclock-load.service@

Please, help me solve this issue.

Also, I appreciate any remarks regarding my current targets. Is there anything that would be better to add or remove?

Thanks in advance

Last edited by eDio (2011-05-07 10:14:40)

loonyphoenix · 2011-05-07 10:35:57

@eDio:

Have you read this part of the wiki:

https://wiki.archlinux.org/index.php/Sy … caltime.3F

Maybe you're using localtime instead of UTC for your hwclock?

Last edited by loonyphoenix (2011-05-07 10:36:34)

eDio · 2011-05-07 10:54:01

I have HARDWARECLOCK="UTC" in my rc.conf. Should I set UTC somewhere else?

I've made hwclock -s and now I've messed with clocks absolutely:

[16:39 system]$ date
Sat May  7 16:42:03 EEST 2011

[16:42 system]$ date --universal 
Sat May  7 13:42:08 UTC 2011

[16:42 system]$ hwclock 
Sat 07 May 2011 04:42:16 PM EEST  -0.422267 seconds

date --universal accidentally gives me my actual local time.

loonyphoenix · 2011-05-07 11:00:31

I'm using the same timezone as you, and it looks like this:

$ date
Sat May  7 13:55:28 EEST 2011
$ date --universal
Sat May  7 10:55:32 UTC 2011
$ hwclock
Sat 07 May 2011 01:55:37 PM EEST  -0.523638 seconds

I'm thinking your hardware clock is in fact set to localtime, even though it says UTC in /etc/rc.conf

Maybe you should try

hwclock --systohc --utc

to set it to UTC?

eDio · 2011-05-07 11:11:54

loonyphoenix, I've made, what you suggest

$ sudo hwclock --systohc --utc
$ date
Sat May  7 14:02:35 EEST 2011
$ date --universal 
Sat May  7 11:02:39 UTC 2011
$ hwclock 
Sat 07 May 2011 02:02:44 PM EEST  -0.859771 seconds

but after reboot I have

$ date
Sat May  7 11:08:45 EEST 2011
$ date --universal 
Sat May  7 08:08:48 UTC 2011
$ hwclock 
Sat 07 May 2011 02:08:53 PM EEST  -0.249833 seconds

I really suspect hwclock-load.service. It was enabled by default, but is it really necessary?
This target causes hwclock --systz on every boot.

loonyphoenix · 2011-05-07 11:21:51

eDio: That's really strange, because I'm using hwclok-load.service too and everything's okay...

Okay, I've got another candidate for you. Maybe it's arch-persistent-settings.service, which sets timezone based on rc.conf on shut-down. Try disabling that service. But you'll have to manage your kernel modules manually then via /etc/modules-load.d/*.conf and /etc/modprobe.d/*.conf

eDio · 2011-05-07 11:33:02

As for arch-persistent-settings.service, the only thing it does with clock is checks if $TIMEZONE variable is set and correspond locale file is present, and then copies that file to /etc/localtime

# update timezone if: The timezone is set in rc.conf and the corresponding
# zoneinfo file exists
if [[ -n $TIMEZONE && -f /usr/share/zoneinfo/$TIMEZONE ]]; then
        /bin/cp --remove-destination "/usr/share/zoneinfo/$TIMEZONE" /etc/localtime
fi

I'm going to create my own arch-persistent-settings-with-blackjack-and-whores.service, which will not create localtime file. Will update post after reboot.

btw, thanks for your help

eDio · 2011-05-07 12:12:12

I've created arch-persistent-settings-wo-clock.service where removed copying of timezone file to /etc, removed /etc/localtime and rebooted.
Finally my clock displays correct time, BUT

$ hwclock 
Sat 07 May 2011 03:07:08 PM UTC  -0.844404 seconds
$ date
Sat May  7 15:07:11 UTC 2011
$ date --universal 
Sat May  7 15:07:19 UTC 2011

I can't avoid feeling, that something is absolutely wrong in my current setup. My timezone is set to UTC in KDE settings also.
Is it normal, that my timezone is UTC and date, date --universal and hwclock show identical time?

Thanks

EDIT: sorry for subsequent post

Last edited by eDio (2011-05-07 12:14:34)

loonyphoenix · 2011-05-07 12:24:06

Maybe you have some weird BIOS timezone support? Or some automatic network synchronization via NTP or something that corrects your hardware clock to localtime each reboot?

falconindy · 2011-05-07 14:09:17

You should nuke the timezone var from rc.conf, particularly given that you're using KDE. hwclock-load is not wrong.here.

eDio · 2011-05-07 15:23:18

Removed, but this had no effect. The only thing, that does have, is /etc/localtime file.
If this file is present, clock will be adjusted on every reboot, if not - both system and hardware clock will use UTC and show the same time.

Also, what is strange, is that hwclock is adjusted on reboots too. But I have no hwclock-save target enabled and I don't use ntpd/chrony/whatever. Arch is the only OS...
Seems, like something changes hwclock on init or shutdown.

present /etc/localtime

hwclock 
Sat 07 May 2011 02:08:53 PM EEST  -0.249833 seconds

no /etc/localtime

hwclock 
Sat 07 May 2011 03:07:08 PM UTC  -0.844404 seconds

Any ideas?

Last edited by eDio (2011-05-07 15:26:26)

eDio · 2011-05-07 15:33:12

hmmm... May someone tell if he has /etc/adjtime file present?

I've got an idea....

If you specify neither --utc nor --localtime , the default is whichever was specified the last time hwclock was used to set the clock (i.e. hwclock was successfully run with the --set, --systohc, or --adjust options), as recorded in the adjtime file. If the adjtime file doesn't exist, the default is local time.

loonyphoenix · 2011-05-07 15:46:47

I have this in /etc/adjtime:

$ cat /etc/adjtime 
0.000319 1297855687 0.000000
1297855687
LOCAL

Which makes me go O_o

eDio · 2011-05-07 15:56:38

I've doublechecked me assumption:
specifying --utc option in all targets explicitly solves problem

currently I have:

[18:55 ~]$ hwclock 
Sat 07 May 2011 06:55:24 PM EEST  -0.187890 seconds
[18:55 ~]$ date
Sat May  7 18:55:26 EEST 2011
[18:55 ~]$ date --universal 
Sat May  7 15:55:30 UTC 2011

which, I believe is the correct behaviour.

I've created bug upstream. If this not a bug, we'll get explanation from developers at least.

Thank you all for help!

Arch Linux

#526 2011-05-06 14:52:48

Re: systemd: Yet Another Init Replacement

#527 2011-05-06 14:55:57

Re: systemd: Yet Another Init Replacement

#528 2011-05-06 15:42:01

Re: systemd: Yet Another Init Replacement

#529 2011-05-07 00:18:01

Re: systemd: Yet Another Init Replacement

#530 2011-05-07 02:16:28

Re: systemd: Yet Another Init Replacement

#531 2011-05-07 02:46:41

Re: systemd: Yet Another Init Replacement

#532 2011-05-07 02:57:39

Re: systemd: Yet Another Init Replacement

#533 2011-05-07 03:06:39

Re: systemd: Yet Another Init Replacement

#534 2011-05-07 03:13:13

Re: systemd: Yet Another Init Replacement

#535 2011-05-07 03:48:27

Re: systemd: Yet Another Init Replacement

#536 2011-05-07 04:20:02

Re: systemd: Yet Another Init Replacement

#537 2011-05-07 10:04:35

Re: systemd: Yet Another Init Replacement

#538 2011-05-07 10:35:57

Re: systemd: Yet Another Init Replacement

#539 2011-05-07 10:54:01

Re: systemd: Yet Another Init Replacement

#540 2011-05-07 11:00:31

Re: systemd: Yet Another Init Replacement

#541 2011-05-07 11:11:54

Re: systemd: Yet Another Init Replacement

#542 2011-05-07 11:21:51

Re: systemd: Yet Another Init Replacement

#543 2011-05-07 11:33:02

Re: systemd: Yet Another Init Replacement

#544 2011-05-07 12:12:12

Re: systemd: Yet Another Init Replacement

#545 2011-05-07 12:24:06

Re: systemd: Yet Another Init Replacement

#546 2011-05-07 14:09:17

Re: systemd: Yet Another Init Replacement

#547 2011-05-07 15:23:18

Re: systemd: Yet Another Init Replacement

#548 2011-05-07 15:33:12

Re: systemd: Yet Another Init Replacement

#549 2011-05-07 15:46:47

Re: systemd: Yet Another Init Replacement

#550 2011-05-07 15:56:38

Re: systemd: Yet Another Init Replacement

Board footer