From: Steve on
Hi,

I am using a script where I use a lot of mount points
( mount xx.zz.cc.vv:/sss/ /mnt/qqq )

Unfortunately, if the resource is not available, the system is waiting
for minimum 10 min ( maybe for ever :-) to get access to the 'drive'

Is there a way to tell the 'mount' NOT to spend more than 2 min on each
connection ? ( and to execute the next instruction )

Thanks

Steve
From: Johannes von Rotz on
Steve wrote:
> Hi,
>
> I am using a script where I use a lot of mount points
> ( mount xx.zz.cc.vv:/sss/ /mnt/qqq )
>
> Unfortunately, if the resource is not available, the system is waiting
> for minimum 10 min ( maybe for ever :-) to get access to the 'drive'
>
> Is there a way to tell the 'mount' NOT to spend more than 2 min on each
> connection ? ( and to execute the next instruction )
>
> Thanks
>
> Steve

Hey.

Maybe you can tweak it with the 'timeo' and 'retrans' options fo NFS.
`man nfs` for further explanations.

To stop retrying file operations indefinitely, use the 'soft' option.

I don't really know if these options have any affect on mounting, but i
guess mounting is a file operation like any other.

Another idea would be to use automount, which would open a connection
only, when needed. Also, you wouldn't need to maintain a huge script...
From: Moe Trin on
On 03 Nov 2009, in the Usenet newsgroup alt.os.linux.redhat, in article
<4af00718$0$2754$426a34cc(a)news.free.fr>, Steve wrote:

>I am using a script where I use a lot of mount points
>( mount xx.zz.cc.vv:/sss/ /mnt/qqq )

That looks like NFS - but you are not providing any details, so it's
a guess of what else is wrong.

>Unfortunately, if the resource is not available, the system is waiting
>for minimum 10 min ( maybe for ever :-) to get access to the 'drive'

man 5 nfs

under 'retry' - a foreground mount waits 2 minutes by default while
a background mount waits 10000 minutes (80 minutes less than 2 weeks).

>Is there a way to tell the 'mount' NOT to spend more than 2 min on
>each connection ? ( and to execute the next instruction )

If that is NFS, yes. Otherwise, more details needed.

Old guy
From: Moe Trin on
On 04 Nov 2009, in the Usenet newsgroup alt.os.linux.redhat, in article
<4af1328d$0$31173$426a74cc(a)news.free.fr>, Steve wrote:

>Moe Trin wrote:

>> What is causing the non-availability? Is the file server down, or
>> not accessible by existing networking? You may want to put a test
>> to see if the server is reachable before you try to mount from it.

>I wrote a small script file, which try to access some servers. I
>know that some of them, are not switched on all day long.
>So, the idea is to start the script and connect to all servers
>available...

Normally, I'd consider testing to see if the server is up before
attempting to connect. Assuming the servers are configured to
respond to a ping (definitely not always the case), perhaps

ping -qc2 server_a
if [ $? = "0" ] ; then
connect_to_server_a
else
server_a_not_there
fi
ping -qc2 server_b

and so on. If the server is configured to not respond to pings
(ICMP Echo), then use something like hping2 or hping3
(http://www.hping.org/ - but it doesn't seem to have been updated
since 2005) to see if a UDP port is reachable.

Old guy
From: Steve on
On Wed, 04 Nov 2009 13:30:38 -0600, Moe Trin wrote:

> On 04 Nov 2009, in the Usenet newsgroup alt.os.linux.redhat, in article
> <4af1328d$0$31173$426a74cc(a)news.free.fr>, Steve wrote:
>
>>Moe Trin wrote:
>
>>> What is causing the non-availability? Is the file server down, or not
>>> accessible by existing networking? You may want to put a test to see
>>> if the server is reachable before you try to mount from it.
>
>>I wrote a small script file, which try to access some servers. I know
>>that some of them, are not switched on all day long. So, the idea is to
>>start the script and connect to all servers available...
>
> Normally, I'd consider testing to see if the server is up before
> attempting to connect. Assuming the servers are configured to respond to
> a ping (definitely not always the case), perhaps
>
> ping -qc2 server_a
> if [ $? = "0" ] ; then
> connect_to_server_a
> else
> server_a_not_there
> fi
> ping -qc2 server_b
>
> and so on. If the server is configured to not respond to pings (ICMP
> Echo), then use something like hping2 or hping3 (http://www.hping.org/ -
> but it doesn't seem to have been updated since 2005) to see if a UDP
> port is reachable.
>
> Old guy

Thank you. I will try it

thanks again for your help