You are not logged in.

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

Leffe
Member
Registered: 2006-05-30
Posts: 47

Re: systemd: Yet Another Init Replacement

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.

Offline

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

Agamemnon
Member
From: France
Registered: 2011-05-05
Posts: 42

Re: systemd: Yet Another Init Replacement

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 wink


Pc: Intel core i7, 8Gb RAM, Archlinux 64bits, Gnome 3
Laptop 1: Intel Core2Duo, 4Gb RAM, Archlinux 64bits, Gnome 3
Laptop 2: Intel P4 HT, 512Mb RAM, Archlinux 32 bits, Gnome 3 too

Offline

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

awayand
Member
Registered: 2009-09-25
Posts: 398

Re: systemd: Yet Another Init Replacement

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)

Offline

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

Diaz
Member
From: Portugal
Registered: 2008-04-16
Posts: 366

Re: systemd: Yet Another Init Replacement

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.

Offline

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

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

Re: systemd: Yet Another Init Replacement

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?

Offline

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

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

Re: systemd: Yet Another Init Replacement

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.

Offline

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

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

Re: systemd: Yet Another Init Replacement

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.

Offline

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

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

Re: systemd: Yet Another Init Replacement

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

Offline

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

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

Re: systemd: Yet Another Init Replacement

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?

Offline

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

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

Re: systemd: Yet Another Init Replacement

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)

Offline

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

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

Re: systemd: Yet Another Init Replacement

I see, thank you.

Offline

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

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

Re: systemd: Yet Another Init Replacement

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?


ᶘ ᵒᴥᵒᶅ

Offline

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

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

Re: systemd: Yet Another Init Replacement

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.

Offline

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

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

Re: systemd: Yet Another Init Replacement

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.


ᶘ ᵒᴥᵒᶅ

Offline

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

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

Re: systemd: Yet Another Init Replacement

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.

Offline

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

laurentis
Member
From: Montréal
Registered: 2009-06-17
Posts: 17

Re: systemd: Yet Another Init Replacement

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.

Offline

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

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

Re: systemd: Yet Another Init Replacement

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

ᶘ ᵒᴥᵒᶅ

Offline

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

eDio
Member
From: Ukraine, Kyiv
Registered: 2008-12-02
Posts: 418

Re: systemd: Yet Another Init Replacement

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).

Offline

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

gothicknight
Member
From: Portugal
Registered: 2006-04-08
Posts: 219

Re: systemd: Yet Another Init Replacement

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.

Offline

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

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

Re: systemd: Yet Another Init Replacement

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.

Offline

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

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

Re: systemd: Yet Another Init Replacement

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?

Offline

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

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

Re: systemd: Yet Another Init Replacement

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

Offline

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

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

Re: systemd: Yet Another Init Replacement

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.

Offline

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

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

Re: systemd: Yet Another Init Replacement

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.


ᶘ ᵒᴥᵒᶅ

Offline

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

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

Re: systemd: Yet Another Init Replacement

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

Offline

Board footer

Powered by FluxBB