[DONE] Autofs starts too late

[mla]

This is a minor irritant, but an irritant nontheless (family keeps complaining ).

After a machine is booted and a KDE user login is apparently complete, attempts to access automounted file systems fail with "no such file or directory". The reason being that the automount process doesn't actually pop up until 10 to 20 seconds after the completed login.

This may not be an autofs problem as such. When I try using fstab nfs-mounting instead, the result is that the boot take about 30 to 40 seconds longer -- again resulting in "user complaints"

I poked round the net, and indeed there are similar reports to be found, but they are all to do with dependencies on services such as kerberos or NIS, which are no used on our home network.

Seeing as systemd's autofs.service file specifies a dependency on ypbind.service, I tried installing ypbind, but the result is again a slow boot.

Any ideas anybody?

[mla]

BTW, I should have added... Console login does not become available until autfs is actually running, so arguably the problem is that the desktop login completes too soon.

[doktor5000]

Well, this is basically the result of speeding up boot to the desktop. Everything is started as early as possible, so network is often fully started only after desktop login.
You probably want the boot to wait until network is up. Have a look at viewtopic.php?p=40883#p40883

Related question: What you you mount via autofs? /home?

[mla]

Having done more experimenting (i.e. a tedious number of reboots later ), it looks to me like it's not a network startup issue -- not directly, anyway. By the time the desktop is ready, network is already available. I can ssh to my file server immediately, so it's unclear why autofs isn't starting immediately.

Another point I should have noted, partitions I automount are mounted om the server from btrfs sub-volumes. But I saw the problem before switching to btrfs as well.

Yes it's /home and other stuff. Which reminds me, I ought to see whether anoht old problem has gone away. Currently I use local home directories which have symbolic links for e.g. Documents pointing to the stuff mounted from the file server. Reason being, I tried (under Mageia 2) to use remote home dirs as such with bizarre effects -- e.g. all desktop icons were shown using the Firefox icon.

[doktor5000]

Did you enable network-up service?
Can you please post your auto.master and the config that you link to from there?

Also, in the first post you mentioned that after logging in to KDE, access to other automounted FS fails.
When your /home is on an automounted FS, how can you login?

[mla]

Yes, network-up is enabled. But as I said, the network is fully up by the time one logs in.

The two non-comment lines of auto.master are:

+auto.master
/athlon auto.athlon

And auto.athlon reads:

btrfs -rw athlon:/btrfs

Not sure what you mean by "the config that you link to from there". Do you mean server-side exports file?

Re home dirs... As I was trying to explain in the last para of my previous post, I use local directories with some symbolic links into the automounted fs -- because of the oddities observed under Mageia 2 when I tried to automount the home directories themselves. So logging into the local accounts is no problem. But e.g. invoking thunderbird (.thunderbird being a link to one's homedir on the server) initially results in "profile absent or inacessible". That remains the case until the automount process pops up, at which point an attempt to access automounted directories simply waits for the mount to complete. The wait is OK (though also surprisingly long -- from my Unix experience I would have expected it to be very quick). It's the initial access failure which is causing grumbles.

[mla]

Before you ask... No, commenting out +auto.master in auto.master makes no difference. I've just tried it, cursing myself to have missed something so obvious.

[doktor5000]

+auto.master
/athlon auto.athlon

And auto.athlon reads:

btrfs -rw athlon:/btrfs

Not sure what you mean by "the config that you link to from there". Do you mean server-side exports file?

No, auto.athlon in this case

Apart from that, when the system is booted normally, what happens when you do an

Code: Select all

ls -al /athlon


especially how long does it take?

And forgive my ignorance, but how can you directly export a BTRFS volume via network?

[mla]

Apart from that, when the system is booted normally, what happens
when you do an

Code: Select all

    ls -al /athlon


especially how long does it take?

Until the automount process pops up, it shows /athlon to be empty. Once automount is present, /athlon is shown to contain the single sub-directory btrfs. In both cases ls takes no time at all. It's the initial absence of /athlon/btrfs that's causing family grumbles.

BTW, I note that once automount is running, there's no longer any delay in actually mounting the remote volume. That delay was presumably eliminated once I took +auto.master out of auto.master.

how can you directly export a BTRFS volume via network?

You can't. I find it convenient to mount on the server the whole of the BTRFS volume as /btrfs (as well as mounting separately its various subvolumes, such as /home). It's /btrfs that is exported.

[doktor5000]

Now you got me confused.
So does the delay now still exist or not? Didn't get that clearly from your comments.

Also, if you exported the btrfs volume on the (remote) server, that means it's an NFS export?
Because you specified the type as btrfs in auto.athlon, which seems wrong.

Maybe it would be a good idea if you could describe your network setup between btfs server and one client a bit more in detail ...

[mla]

Sorry, I should have been clearer. My principal grizzle was (and is) that the desktop is ready before the automount daemon is started. Until it is started , any attempt to access stuff in /athlon/btrfs simply returns an error. That is still the case.

I also mentioned in passing that once automount was present, it was rather slow to mount the remote partition -- during which time any attempts to access stuff on it waited until mount actually took place. This wait is now gone, I guess because automount no longer faffs about with trying to talk to ypbind.

The surprising thing is that systemd's autofs.service is in multi-user.target.wants, so you wuold have thought desktop would be delayed until automount is up and running. But I am not up to disentangling systemd's complexities at this stage.

Re the btrfs mount... No file system type is specified so it defaults to NFS. The 1st token in "btrfs -rw athlon:/btrfs" specifies the mount point /btrfs (within /athlon, from auto.master) and the third token says where to get it (from file system /btrfs on athlon). A non-NFS fs type would have to be specified explicitly as a part of options (the second token).

I.e. the actual mount is /athlon/btrfs rather than /athlon -- auto.athlon an indirect map, not a direct one.

[wintpe]

your not also effected by this are you.

this can add a perceived time delay to autofs , as the nfs mounts take quite a time to overcome this issue.

I had this from mga 3 on, and gave same symptom you describe

viewtopic.php?f=8&t=6980&p=44936#p44936

regards peter

[mla]

There's nothing perceived to the autofs delay. I had tried the GSS fix before grumbling here and it made no difference to the fact that desktop login is completed before the automount daemon is present. I actually ran a little script grepping though output of ps, while another script repeatedly attempted to access automounted file system. Accesses were failing with "no such file or directory" while automount was absent from the list of processes. The moment it popped up, the "no such file or directory" errors stopped. Then there was the second delay, now cured, caused by me forgetting to comment out +auto.master in auto.master.

The plain and simple fact is that the desktop is made available long before automount is up and running. Up to 30 seconds as a guess, counting in the time it takes one to log in.

[doktor5000]

Just a wild guess, maybe you want to add fstab entries instead and mark them as autofs entries via option x-systemd.automount and also as remote filesystem via _netdev option? Or add those to your automounter map?

To influence autofs startup you should have a look at /usr/lib/systemd/system/autofs.service

[mla]

Hehe... Those are new tricks for this old dog. Have tried taking auto.athlon out of auto.master and putting this into fstab:

Code: Select all

athlon:/btrfs /athlon/btrfs nfs soft,x-systemd.automount,noauto,_netdev 0 0


The result was curious. After accepting my login the system just sat there for ages over a minute, just spinning the little circle of dots -- only after that it actually started on the login screen itself (with the five bubbles gradually rising out of the cauldron). By the time I actually got in, the mount was there, of course.

So I thought maybe I need to disable autofs. The result is a sort-of improvement. The pause after login is accepted and before login actually starts is now between 25 and 30 seconds -- which just happens to be the amount of time by which automount's appearance was delayed in the old setup. Again, by the time I get in, the mount is there. But there is no autommount daemon, so how did it get mounted (there's noauto on the fstab line!). Maybe it's just an NFS mount after all. I suppose I should try having automount enabled but not started.

Yes, I did look at the autofs.service file. As already noted, it is in multi-user.target.wants (and the file itself notes the fact). It's dependencies are network.target and ypbind.service. I tried removing the latter, but that made no difference.

[doktor5000]

But there is no autommount daemon, so how did it get mounted (there's noauto on the fstab line!)

Automagically ™ :p
Sorry, no clue actually - that seems systemd's integrated automount implementation from what I understood.
Maybe have a look at http://www.freedesktop.org/software/sys ... mount.html or the other linked man pages

[mla]

Automagically ™ :p

Young man, I am on record using that term about 30 years ago. Prior art and all that, don't you know?

I'll probably revert to using autofs. Using systemd's automagic adds about 20 seconds overall to boot/login. These days it no longer feels like peanuts. (Now in the good *old* days... )

[mla]

Well, I can improve things a bit by shifting the autofs.service file from multi-user.target .wants to graphical.target.wants and by noting in the file itself that it is wanted by graphical.target rather than by multi-user.target. Reason being that graphical.target naturally enough depends on multi-user.target -- so I'd argue that the autofs.service file is in the wrong place.

Alas, this does not solve the problem. The result is that KDE login still completes before automount is ready, though the daemon now starts within a few seconds after I am logged in (3 to 5 seconds as opposed to 10+). Better, but still not ideal, because users can still get "no such file or directory" just after logging in.

[doktor5000]

Then best report that as a bug: https://wiki.mageia.org/en/How_to_report_a_bug_properly
Provide information on NFS server side and NFS client mount options, and the current state of /usr/lib/systemd/system/autofs.service and assign the bug to Colin Guthrie - he's our systemd maintainer, maybe he can shine some light on the inter-dependencies and possible workarounds or solutions.

Please also post back the link here and put me on CC for that bug, thanks.

[mla]

OK, will do. But I need to do some more testing first. (a) Both systemd and systemd-units packages have just been updated, so I need to see whether symptoms have changed in any way. (b) The fact that there are so few complaints on the subject suggests to me that the problem only occurs becuase I am *not* automounting whole home directories, but I need to check that too. (c) I should also check, I suppose, that the problem is not specific to KDE logins (it shouldn't be, but...)

[doktor5000]

(b) The fact that there are so few complaints on the subject

Well, my assumption is not that many people use such lowlevel automounts or even know about this possibility anymore nowadays. I kid you not.
And the others that use NFS mounts will usually put them in fstab and mount them on boot automatically.

But for checking with something else then KDE, that's probably your easiest bet.
Maybe related, I've recently filed a bug about delays in KDE related to network shares: https://bugs.kde.org/show_bug.cgi?id=328772

[mla]

Well, my assumption is not that many people use such lowlevel automounts or even know about this possibility anymore nowadays. I kid you not.

O tempora! O mores! Where's the next generation of kernel firtlers is going to come from?

But as it happens, it looks like your guess on that was better than mine. When mounting a whole home directory, one winds up in /, which KDE takes an exception to. Nor is the problem restricted to KDE logins. And the latest systemd changes made no difference (not that I expected them to).

Hope to get around to submitting it as a bug tomorrow.

As an aside, all this just deepens my lack of liking of systemd. The idea of systematising lists of dependencies in order to parallelise booting is fine, of course. But the fact that it has e.g. its own mount/automount magic offends my *nix sensibilities. Hey-ho!...

[mla]

OK, bug report submitted: https://bugs.mageia.org/show_bug.cgi?id=13284

But as for CCing you on the bug, if I have the ability to do so, it is sufficiently well hidden on that form.

[doktor5000]

But as for CCing you on the bug, if I have the ability to do so, it is sufficiently well hidden on that form.

In the upper right area, there's a section CC list - click on the edit button, and you can enter my nick there, mail adress will pop up shortly after (when you're logged in to bugzilla).

CC List: Add me to CC list
0 users (edit)

[mla]

OK. I must be going blind as well as deaf. But I see yuo've added yourself already anyway.