# delay when starting portmap

## pcassidy

I've got a portmap/NFS issue on boot I can't quite figure out. Everything starts up as normal until NFS statd is started then the machine hangs for a minute before continuing. The log gives the following, where you can see the

delay.

```

Feb 23 20:11:45 [input.agent] ... no modules for INPUT product

Feb 23 20:11:49 [rpc.statd] Version 1.0.6 Starting

Feb 23 20:12:48 [portmap] user rpc not found, reverting to user bin

Feb 23 20:12:48 [rpc.statd] recv_rply: [192.168.1.1] service 100024 not registered

Feb 23 20:12:48 [kernel] svc: unknown version (3)

```

I've never edited /etc/rpc or /etc/services, so these should be the defaults.

Anybody know of a reason for this delay?

Thanks,

Paul.Last edited by pcassidy on Tue Feb 24, 2004 11:00 pm; edited 1 time in total

----------

## adaptr

It looks like you may have mixed different version clients and servers.

The last line says "kernel: unknown version (3)", meaning the kernel nfsd driver is probably v4 only, and the export is done with v3.

Try rebuilding the kernel with both v3 and v4 support, or make sure both kernel and userspace programs are the same version.

----------

## pcassidy

Thanks for the quick response.

Sure enough didn't have nfsv3 in the kernel. Added it, but it doesn't solve the problem. It does get rid of:

```
svc: unknown version (3)
```

I'm not pretty sure portmap is the problem

```
/etc/init.d/portmap restart

 * Saving portmap table...                                                [ ok ] 

* Stopping NFS mountd...                                                 [ ok ] 

* Stopping NFS daemon...                                                 [ ok ] 

* Stopping ypbind...

 * Stopping portmap...                                                    [ ok 

 Starting portmap...                                                    [ ok ] 

* Reloading portmap table...                                             [ ok ] 

* Exporting NFS directories...                                           [ ok ] 

* Starting NFS daemon...                                                 [ ok ] 

* Starting NFS mountd...                                                 [ ok ] 

* Starting ypbind...

```

with a one minute gap after printing reloading portmap table.

the log gives

```

Feb 23 22:54:38 [rpc.mountd] Caught signal 15, un-registering and exiting.

Feb 23 22:54:38 [kernel] nfsd: last server has exited

Feb 23 22:55:39 [portmap] user rpc not found, reverting to user bin

```

I'm going to try re-emerging portmap now and see if there's any joy to be had.

----------

## pcassidy

no joy re-emerging portmap. This happens both on 2.4.22 and 2.6.3. 

The 2.4.22 is the genkernel, so I don't think it's a kernel problem anymore. Must be to do with

my portmap setup.

I don't have an /etc/hosts.allow or an /etc/hosts.deny, would this cause a problem with portmap/NFS starting?

----------

## pcassidy

Anybody good with portmap out there?

----------

## joycea

Not 100% sure if the hosts.allow and .deny would cause a problem, but why not add them in to ensure this is not the case.

/etc/hosts.allow

```
ALL: 127.0.0.1 : ALLOW
```

/etc/hosts.deny

```
portmap:ALL

lockd:ALL

mountd:ALL

rquotad:ALL

statd:ALL
```

Also, is there any delay in starting portmap when using the 

```
portmap -dv
```

 command directly?

----------

## pcassidy

Thanks for the response,

I tried your suggestions.

```
portmap -dv 
```

both with and without the hosts.allow and hosts.deny

still get a 1 minute delay before it starts up. During that time the machine more or less hangs. after the minute is up I get the following either in the logs or on the screen if I use portmap -dv

```

Feb 24 22:56:32 [portmap] user rpc not found, reverting to user bin

```

Any other ideas?

----------

## joycea

This seems really unusual.  Is there any network traffic taking place during this?  Does your hostname resolve properly?  Is your /etc/hosts file complete?

Short of a network timeout somewhere I would say you might be best to compile it with symbols and then run it in a debugger.  I can't think of anything other than the network that might be causing such a delay.  At least by debugging you can determine exactly where everything is stalling.

----------

## pcassidy

Thanks joycea. I'll have a look at that when I get home.

I might just look through the source code for portmap to find out where it produces

the reverting to user bin output.

I'm now not 100% sure it isn't a kernel issue. 2.4.22 now boots without a delay when I use the

initrd. I had turned off the initrd on boot trying to solve another issue.

Might be something missing from my 2.6.3 kernel, can't see what though.

I have all the usual networking options enabled, but I'll have a closer look later.

----------

## joycea

Any resolution?

----------

## pcassidy

No, spent the weekend doing a emerge -e world. Also I was using ACCEPT_KEYWORDS="~x86", I went back to the stable portage tree. Still have the delay on

portmap startup. 

I did find one problem though, the server didn't have nfs statd running, this explains the 

```
Feb 23 20:12:48 [rpc.statd] recv_rply: [192.168.1.1] service 100024 not registered
```

message in the log. The portmap startup delay problem only affects the client machine.

This leaves me looking at one message,

```
Feb 23 22:55:39 [portmap] user rpc not found, reverting to user bin

```

Do you have an rpc user in your /etc/passwd? I wonder if that's causing the problem.

----------

## joycea

No, I don't have a user rpc.  I don't think Gentoo uses this profile for privilege separation.  It reverts to bin so I guess there is not much more gained in the pirvilege area.

Why don't you try running netwatch on both client and server and see what is happening during the delay in terms of network traffic?  It might give further insight into the problem.  I still believe that the problem lies somewhere within the network configuration.  What does your /etc/resolve.conf, /etc/hostname and /etc/domainname look like?

----------

## pcassidy

sorry for not getting back sooner, been outrageously busy the last couple of days   :Crying or Very sad: 

I'll have a try and see what netwatch produces. Also must try running portmap with debugging on and see where it's stalling.

In the meantime here's my net config. Obviously the domain is made up, but I don't think that should make a difference?

```
cat /etc/hostname

orion

```

```
 cat /etc/resolv.conf

domain pcassidy.ie

nameserver 194.46.8.2

nameserver 194.46.8.3

nameserver 194.46.8.2

```

```
 cat /etc/nisdomainname /etc/dnsdomainname

pcassidy.ie

pcassidy.ie

```

Don't have an /etc/domainname, I'll see if this causes the problem

```
cat /etc/hosts

192.168.1.2     orion.pcassidy.ie orion

127.0.0.1       localhost

192.168.1.1     ktulu.pcassidy.ie ktulu

```

[/code]

----------

## pcassidy

still no joy. Can't get a version of portmap with symbols because I can't

figure out where the patches are coming from. The out of the box version 

doesn't compile, but anyway...

tried tcpdump with almost every service stopped so there would be no

net traffic. on starting portmap there is no network traffic until the minute

delay is up.

I have a theory as to why though, my /etc/nsswitch.conf has

```

passwd:      files nis

shadow:      files nis

group:       nis files

```

ypbind depends on portmap, so is not running when portmap is started,

portmap is trying to look a user rpc, and tries to do an nis lookup when

the search of /etc/passwd fails.

I'm going to look at this a bit more now, maybe I need to change my

nsswitch. [/code]

----------

## pcassidy

SUCCESS  :Exclamation:   :Very Happy: 

just added an rpc user to /etc/passwd, no more delay. I tried a couple of

nsswitch changes, putting [NOTFOUND=return] in etc., got rid of the delay,

but then I couldn't see any other users either!

I think I might file a bug, as the portmap ebuild should probably add an

rpc user to /etc/passwd.

----------

## Gandy

pcassidy, you are my personal hero of the day, month, year(?)!  :Wink: 

I have had this delay now for weeks and even I tried everything (beside adding a user rpc  :Wink: ) - search in google and here, tried to discover the problem with ethereal and even strace - but no chance. So, finally I thought, I only could solve the problem by reinstalling gentoo but then I install gentoo on another PC and uuuh! the same bad thing. So I now thought to look for the problem at the server running Mandrake. But another computer running Conectiva shows me that here the problem doesn't appear. So I took a final look here and found...YOU! Thanks so many times and excuse my poor knowledge of the English language.  :Smile: 

----------

## himasaram

Hi everybody!

I have the exact same problem as pcassidy. I tried to add the user rpc to passwd, and assigned some random numbers to that user but nothing happened. Could you guys please just show me that specific line of you passwd-files?

Thanks!  :Smile: 

----------

## pcassidy

Here's the line from my /etc/passwd

```

rpc:x:111:111::/sbin/portmap:/bin/false

```

Hope it helps.

----------

## himasaram

Thank you! 

It did get rid of that specific error message for me, but did nothing for speeding up portmap at boot.

It seems our problems were a bit different in the end. My portmap is only this slow when booting the system. A '/etc/init.d/portmap restart' is executed very fast!

I'll try the other remedies you went through above to see if that helps!  :Smile: 

----------

## himasaram

Actually, vixie-cron and local is as slow as portmap at boot for me!

I may have to find a solution elsewhere...

----------

## Axelay

Yes, that FIXED IT

Thanks for the hard work in tracking down that problem.  We have 4 systems here, I have Gentoo running on all of them, I have a gateway, a fileserver, and two client machines (one for me and the other for my wife).

My PC is the only one that was having this problem.  I spent hours trying to see what difference there was between my wife's pc and my own, but I never checked the passwd file.

Who would think to do that?

Lol

rpc:x:111:111:added by portage for portmap:/dev/null:/bin/false

----------

## himasaram

Yes, my portmap and vixie-cron starts instantly on my machine again now. Some kind of delayed effect.  :Smile: 

NFS daemon takes forever tho, but that's another story.  :Wink: 

----------

## kadmos

I independently discovered the same problem after much frustration.

I just filed bug 76104 https://bugs.gentoo.org/show_bug.cgi?id=76104 to fix the bug so that others do not need to waste their time doing likewise.  

Please have the courtesy to do this yourself when you discover bugs in future!   :Wink: 

----------

