ubuntu 12.04 boot with nis(ypbind) autofs (nfs) not working.

[kenjo]

I upgraded a working 11.10 to 12.04 and now I no longer can login to the machine.

Problem has been for several weeks now so it's obviously not a transient problem.

What is happening is that I get no graphics login. lightdm starts I think but fails to present a login screen.

changing the boot so that I boot into text mode instead reveals the following problems.

Its takes a long time to get a login prompt and when it shows up it's possible to enter root user and password but then the login hangs for a few minutes before a bash prompt show up.

after that its possible to see that autofs has not started so its impossible to login as a normal user.

starting autofs with "start autofs" do not works unless I also restart ypbind at the same time as autofs waits for ypbind and do not understand that is is already started.

after boot ypbind and autofs is restarted I can start lightdm and login to the system.

Problem is this is a 5 minutes procedure for every boot. and no suspend do not work so that is not a workaround.

Upstart is completely impossible to understand so I'm not sure what the problem really is.

[kenjo (ken-kenjo)]

Main problem for delays is actually the network.

I added eth0 in /etc/network/interfaces and now there is no delay at boot.

autofs is still not started and I have to do
start autofs
and in another terminal
restart ypbind
to make autofs actually start.
then I can
start lightdm

then I can login.

It think I should not have to do the change to interfaces fiile and Network-Manager should handle it no ??

[James Page (james-page)]

I think this a bug 962001 might be the same issue.

The latest update to autofs uses a new upstart feature called wait-for-state to coordinate between ypbind and autofs - I think its targetting the wrong state causing autofs not to start.

[James Page (james-page)]

Confirmed - I think that the wait-for-start in the autofs configuration is not required - this is already handled by the start-ypbind configuration which waits for ypbind to get to running start before autofs will startup - and will correctly detect if its already running.

[James Page (james-page)]

autofs5 (5.0.6-0ubuntu5) precise; urgency=low

  * d/autofs5.autofs.upstart: Drop wait-for-state from configuration as
    waiting for NIS to start is already handled in the NIS package by
    the start-ypbind upstart configuration which supports autofs
    (LP: #958704).

Marking 'Fixed Released'.

Please re-test once this revised package is available.

[kenjo (ken-kenjo)]

I do not understand this fix.

autofs needs to wait for ypbind to be able to get the auto.master map file out of nis.

So what is preventing autofs from starting before it can read out the auto.master file ?
is the runlevel waiting on ypbind ?? I simply don't understand how to get upstart to tell me the order of things.

how about changing line 13 to

        start wait-for-state WAITER=autofs WAIT_FOR=ypbind WAIT_STATE=running

[James Page (james-page)]

kenjo

autofs does not need to do this - its already done by the start-ypbind configuration.

the above does work (and is what start-ypbind does) - its just supplementary and not required.

[kenjo (ken-kenjo)]

On Thu, 2012-03-22 at 15:06 +0000, James Page wrote:
> kenjo
>
> autofs does not need to do this - its already done by the start-ypbind
> configuration.

ok then I said it before upstart is a complete mystery to me.

so when autofs is started start-ypbind is actually blocking autofs ??
and only when start-ypbind is started is autofs actually started??

if you say so but I do not understand the configuration that makes this
happen.

if I look into start-ypbind it gets started and then only waits for
ypbind to start. That is all. why is autofs not started while this wait
is happening ?

autofs now have no condition other than runlevel so I do not see why it
would wait on ypbind.

> the above does work (and is what start-ypbind does) - its just
> supplementary and not required.
>

[James Page (james-page)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 22/03/12 17:02, kenjo wrote:
> On Thu, 2012-03-22 at 15:06 +0000, James Page wrote:
>> kenjo
>>
>> autofs does not need to do this - its already done by the
>> start-ypbind configuration.
>
> ok then I said it before upstart is a complete mystery to me.
>
> so when autofs is started start-ypbind is actually blocking autofs
> ?? and only when start-ypbind is started is autofs actually
> started??
>
> if you say so but I do not understand the configuration that makes
> this happen.
>
> if I look into start-ypbind it gets started and then only waits
> for ypbind to start. That is all. why is autofs not started while
> this wait is happening ?

the start-ypbind configuration starts on .. starting autofs .. (among
others) so it exec's wait-for-state ypbind = running and blocks the
startup of autofs until that state is reached

> autofs now have no condition other than runlevel so I do not see
> why it would wait on ypbind.

Hope that helps you understand how this works.

- --
James Page
Ubuntu Core Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPbEJEAAoJEL/srsug59jDFAEQAIp2jEEEr3UfmOZYG/DB5TQc
8fZV+RIZXYVRAoEvaapB7vheENQh9sqf9RxEM/PrbeGTTWu6aYkZ3WQYW8YFj40y
ngTd+Ru7D1nU9Ec3Af2Ym9JN+iQrSMV0bNtq355rYCyZr1YbSMK+DnW4m3X9tKcL
3nAGkhj85UQGDk5m2vkL23ouTWhHhg1lPYbDPp+CNUFDmqEMBwmi42qgA3zL4XU+
OFxG6eHZC4W6Ljoc+lJaOoB0qgGTQ5k0+CVwY7YCfnrq4qABLiE3CXiT3jknxGmR
oUIURBo6URha+dB+W89TObqlldkMnA0m+2BlZ/od/rX6Is5fpEVz5Xg5JbcovfYi
n0FoLbaaq1hoS1oLHoxJciBYCN9FUQ1TPA6XB1Xd8ejMPT10LsaVF6/N24XXZcqB
4j6mzv3hfQvww+InytfWJjzlMeEpkvUVv7ny6BGecPY9KB+pIqR2t5bqAsknpbo5
hF7ttBfcQVApwhatl/MRxk0DTCKyVjEZZQMsHK1M4ediT85XnJHp5HPU99vkj3eF
6xZqhQ63MfwzDwL7RHioS8H7Kv5+EnEVMuJdNLFB2thLiLfsZQgTDvtK4MHJ1pXH
giqh9qTFfYs4urkt84Y+s8nMM1tFEftfU+gsVDty/xeIbr9TQ1k3fCl4z+wFYtpg
4uvmS8wb06geh5b68i+q
=zTIq
-----END PGP SIGNATURE-----

[dm (jan-rauberg)]

No, it doesn't work. I have to restart ypbind before login. The same bug arises some weeks before in 11.10 and was fixed after 2 weeks. The bug is very annoying. Please fix it soon. I'm using a rather up to date system (12.04 with latest patches).

[kenjo (ken-kenjo)]

On Thu, 2012-05-03 at 06:14 +0000, dm wrote:
> No, it doesn't work. I have to restart ypbind before login. The same
> bug arises some weeks before in 11.10 and was fixed after 2 weeks. The
> bug is very annoying. Please fix it soon. I'm using a rather up to date
> system (12.04 with latest patches).
>

you should open a new bug. as this one has been closed.

I can mention that it do now work for me as long as I do not use
NetworkManager for the ethernet device. I have to set up the network
with /etc/network/interfaces file.

[Steve Plummer (plummers72)]

I just wanted to comment that I find it troubling that this bug is closed and has low urgency. I am not a developer, just a user.
My company runs a small computer lab for our clients, it is used by 150+ users. It uses NIS for it's logins and NFS for the user's home directories. Any time that a user restarts or shuts down a computer, I have to log into the one local account and run a "sudo restart ypbind" (which I learned from this thread, thank you) and log out...as you can guess users restart or shutdown frequently, completely disabling the computer. Prior to upgrading to 12.04, this lab ran flawlessly and took almost none of my attention, now it takes up a solid hour of every work day.
Please reconsider this bug as a higher priority. How many schools, libraries, and companies like mine are being affected?

[gmenezes (guilherme-v-f-menezes)]

Fix does not work.

I have the latest version for autofs and ypbind and I have to manually restart autofs everytime after login.

autofs is not able to read configuration files from ypbind during boot.

[James Page (james-page)]

Please don't comment on bugs which have been closed.

I think bug 1007273 is probably the issue you are all seeing - please can you help out by providing good feedback on symptoms you are seeing with regards to this issue.

Once we have identified what the issue is we can then work on fixing it.