systemd: Yet Another Init Replacement

Leffe · 2011-05-08 08:09:03

I had the same problem, I think the cause was that /var/lib/hwclock/adjtime was not accessible when the hwclock program looked for it.

I added --utc to hwclock-load.service to work around it.

Agamemnon · 2011-05-08 08:27:54

falconindy wrote:

arch-daemons.target. Sadly, it's going to be a little longer than I wanted until that unit disappears. That said, the intended usage of that target was never meant to be more than:
1) Install systemd, initscripts-systemd, systemd-arch-units (arch-daemons.target is enabled)
2) reboot
3) copy /run/systemd/generator/arch-daemons.target.wants/*.service to /etc/systemd/system for anything where a native unit file doesn't exist
4) kill -1 1 (refreshes systemd's unit database)
5) systemctl enable *.service (for the services you copied over in step 3)
6) disable arch-daemons.target
7) ????
8) profit.
I'd encourage you to go one step further and try to write unit files for anything missing from our current collection in systemd-arch-units. You could even go one step further and submit it upstream so we don't have to maintain it ourselves.

Thanks for your help! I have done what you said and now I profit

awayand · 2011-05-08 12:57:23

Will systemd replace init anytime soon as in getting installed from a standard arch installation? Would I have to cast a vote somewhere for that? Sorry for the newbie question, I really like this thing, looks very promising.

Last edited by awayand (2011-05-08 12:59:21)

Diaz · 2011-05-08 14:33:08

awayand wrote:

Will systemd replace init anytime soon as in getting installed from a standard arch installation? Would I have to cast a vote somewhere for that? Sorry for the newbie question, I really like this thing, looks very promising.

I think that was already talked about in this thread. Anyway, go see the mailing list, there was info there.

Glaucous · 2011-05-08 14:38:44

Read in this thread about autofs and systemd, which seemed easy enough to setup. But be that as it may, I still seem to have failed.
- Installed autofs
- Added comment=systemd.automount to the partitions that need it in /etc/fstab.
When I check mount at startup, all the partitions are mounted, even though they're not accessed (I'm at least sure about one of them).

Anything that I've forgotten?

falconindy · 2011-05-08 16:21:03

Yes, the contents of your fstab, if you wanted help debugging it. Keep in mind that any access will cause the partition to be mounted.

Glaucous · 2011-05-08 16:46:56

I understand that, trying to think of what could possibly access my backup drive at startup (could be anything I guess, but nothing I've explicitly configured).

/etc/fstab
http://codepad.org/3I21bY2U

/media/windows, /media/winprogs, /media/sgreen, /media/sbackup; should for use not be accessed every startup. Then again, some programs might scan it for some reason.

falconindy · 2011-05-08 16:50:26

Two things:
1) how are you determining that these are mounted at boot?
2) Is /etc/mtab a symlink to /proc/self/mounts ?

Glaucous · 2011-05-08 17:07:20

1) It depends on how you define "at boot", I check 'mount' and 'df -h' when I've booted and logged in. The problem with this is obviously that a program could have accessed them at that time, which means I can't really say if autofs is working or not.
2) No it's not.
What would be the best way to check if it's working?

falconindy · 2011-05-08 17:19:01

systemd doesn't support /etc/mtab not being a symlink. That's likely the source of your problem.

And I'll parrot what I told litemotiv -- since you're using FUSE, you need util-linux compiled with --enable-libmount-mount. See the aur for util-linux-git, or hit up ABS.

late edit: I've updated the systemd wiki page to stress the importance of this symlink being in place.

Last edited by falconindy (2011-05-08 17:52:59)

Glaucous · 2011-05-08 17:24:38

I see, thank you.

litemotiv · 2011-05-09 09:24:44

Dave, is it possible that with an unclean shutdown, the timezone settings are lost because arch-persistent-settings cannot be run? Would it make sense in that scenario to run it earlier instead?

falconindy · 2011-05-09 12:35:15

Funny you should mention that. Over the weekend, I actually removed initscripts-systemd from all my boxen. Assuming that your computer never changes timezones, and as far as i can tell, updating your /etc/localtime file is only necessary for 2 reasons:

1) core/tzdata update (more specifically, there was an update for your TZ)
2) your computer actually physically changed TZ

Beyond that, and with regard to time, it's fine if arch-persistent never runs at all. Tom and myself have actually been moving to get rid of setting the timezone not only here, but in the arch initscripts as well. If you're using a DE such as KDE or Gnome, you've got a graphical applet to control the timezone. If this setting isn't in sync with what rc.conf says, that will cause issues.

Having fought with syslog-ng for too long (and therefore making gratuitous usage of sysrq), I can assure you that there's nothing related to the hwclock that would be poisonous, should it not run on an unclean shutdown. The hwclock-save.service merely calls 'hwclock --systohc'. Without significant hwclock drift, missing this call once in a while isn't the end of the world.

litemotiv · 2011-05-09 13:31:50

Hmm that's strange, since my computer switches back to GMT occasionally for some reason. In two instances this happened after an unclean shutdown, but i might have concluded the relationship a bit too fast. I'm not using a DE or anything at least.

falconindy · 2011-05-09 13:45:57

Seems more likely that this would be occurring on bootup, rather than shutdown. Have you enabled hwclock-load.service? This is what calls hwclock --systz to properly set your timezone.

laurentis · 2011-05-09 15:49:26

First I want to thank falconindy for his great work on this package. The wiki and this thread were really helpful to make this work on my system.

I just want to share the problems I had while settings this up to make it work independently of rc.conf.

- As mentioned earlier in this thread, wicd.service is wanted by network.target which is not activated if you don't use remote-fs.target. So I had to modify wicd.service to be 'wanted' by multi-user.target.

- Simply copying the auto-generated *.service files in /etc/systemd/sytem and systemctl enable <service> didn't work for me. In order to have these services enabled at boot, I had to add an [Install] section in these files.

- For some reason I had to add the 'noauto' option in fstab in addition to 'comment=systemd.automount'. Otherwise the filesystems listed in fstab are fsck and mounted at boot time. (Yes, mtab is a symlink!) I did observe that with the 'noauto' flag, the filesystems are mounted only on first access. I'm not sure if it's a correct approach but it does work.

- The only thing left was the update of the timezone file. After a little research I found that the reason /etc/localtime was a file rather than a symlink was to allow /usr to be mounted on its own partition. Since this is not my case, I simply changed it to a symlink and removed the initscripts-systemd package.

litemotiv · 2011-05-09 16:04:03

falconindy wrote:

Seems more likely that this would be occurring on bootup, rather than shutdown. Have you enabled hwclock-load.service? This is what calls hwclock --systz to properly set your timezone.

Yes apparently so:

% systemctl |grep hwclock
74:hwclock-load.service      loaded active exited        Apply System Clock UTC Offset

eDio · 2011-05-09 22:12:25

Hi, all.
Recently I've created a bugreport upstream, regarding --utc option for hwclock in all services that invoke hwclock, and got the following explanation:

We support localtime in RTC just fine, in fact the whole hwclock-load.service
exists only to support localtime, since the kernel can do UTC for you anyway
and implicitly. If the archlinux wiki claims otherwise, then it is simply wrong
and should be corrected.
Basically, I recommend embedded folks and those not needing windows compat to
simple remove the hwclock-load.service and leave the kernel do its job. And
even if you need windows compat you are probably better of setting the RTC to
UTC and teaching windows by some registry key to deal with it.
localtime is fucked up, but we do have to support it, and we do just fine, if
you configure this in /etc/adjtime.

https://bugs.freedesktop.org/show_bug.cgi?id=36937

So I believe, wiki should be corrected.
I could do this, but modification will impact several sections from the wiki page... And as I'm not native speaker, I just fear to perform such massive modification (but will do if needed).

gothicknight · 2011-05-10 10:14:48

Hi eDio,

IMO the wiki is correct. It does not state that it isn't possible but rather that the default is to be handled as UTC. Although this may be better explained as a community/packager decision and not the lack of such feature.

falconindy · 2011-05-10 14:49:19

In the 'not supported' section, the wiki states:

HARDWARECLOCK (use 'hwclock --systohc --utc' to set your hardware clock to utc, localtime is not supported, see FAQ)

This is wrong.

Glaucous · 2011-05-10 20:41:59

Regarding automount/autofs (as we talked about a few posts up); I installed linux-utils-git (which indeed compiles with libmount enabled) - but still the partitions are mounted at startup.
Please note that I'm not saying that it's not working (I can't confirm this), but is there something I could try to see what application accesses them?

falconindy · 2011-05-10 20:56:09

I would suggest booting with the 'verbose' option or systemd.loglevel=verbose and seeing if anything relevant passes through the logs.

Glaucous · 2011-05-10 21:30:53

I can see in the log that at least the ntfs-3g drives (windows) are mounted during boot.
And those are the two drives I can almost assure that no other program "should" be reading from.

litemotiv · 2011-05-10 21:46:55

Glaucous wrote:

I can see in the log that at least the ntfs-3g drives (windows) are mounted during boot.
And those are the two drives I can almost assure that no other program "should" be reading from.

Are they listed as systemd-1 mounts? If so, then they're not really mounted but just listed as automount.

Glaucous · 2011-05-10 21:48:36

systemd-1 mounts? Not quite sure what this means, and how can I check it?

Arch Linux

#551 2011-05-08 08:09:03

Re: systemd: Yet Another Init Replacement

#552 2011-05-08 08:27:54

Re: systemd: Yet Another Init Replacement

#553 2011-05-08 12:57:23

Re: systemd: Yet Another Init Replacement

#554 2011-05-08 14:33:08

Re: systemd: Yet Another Init Replacement

#555 2011-05-08 14:38:44

Re: systemd: Yet Another Init Replacement

#556 2011-05-08 16:21:03

Re: systemd: Yet Another Init Replacement

#557 2011-05-08 16:46:56

Re: systemd: Yet Another Init Replacement

#558 2011-05-08 16:50:26

Re: systemd: Yet Another Init Replacement

#559 2011-05-08 17:07:20

Re: systemd: Yet Another Init Replacement

#560 2011-05-08 17:19:01

Re: systemd: Yet Another Init Replacement

#561 2011-05-08 17:24:38

Re: systemd: Yet Another Init Replacement

#562 2011-05-09 09:24:44

Re: systemd: Yet Another Init Replacement

#563 2011-05-09 12:35:15

Re: systemd: Yet Another Init Replacement

#564 2011-05-09 13:31:50

Re: systemd: Yet Another Init Replacement

#565 2011-05-09 13:45:57

Re: systemd: Yet Another Init Replacement

#566 2011-05-09 15:49:26

Re: systemd: Yet Another Init Replacement

#567 2011-05-09 16:04:03

Re: systemd: Yet Another Init Replacement

#568 2011-05-09 22:12:25

Re: systemd: Yet Another Init Replacement

#569 2011-05-10 10:14:48

Re: systemd: Yet Another Init Replacement

#570 2011-05-10 14:49:19

Re: systemd: Yet Another Init Replacement

#571 2011-05-10 20:41:59

Re: systemd: Yet Another Init Replacement

#572 2011-05-10 20:56:09

Re: systemd: Yet Another Init Replacement

#573 2011-05-10 21:30:53

Re: systemd: Yet Another Init Replacement

#574 2011-05-10 21:46:55

Re: systemd: Yet Another Init Replacement

#575 2011-05-10 21:48:36

Re: systemd: Yet Another Init Replacement

Board footer