OK. The spin loop/lock seems to work much better than the start
triggers.
I still find however that mountall is trying to mount nfs filesystems
before rpc.statd is started. Do we consider this an nfs-utils bug or an
upstart/mountall bug?
--
mountall for /var races with rpc.statd
https://bugs.l
As an alternative hack/solution to this race (until it's resolved more
elegantly within upstart), could we not simply spin in the statd.conf
script waiting for /var/lib/nfs to be available?
This would be most interesting to do because, in fact, I believe that
/var/lib/nfs not being available when
I should add, that even with the suggested patch from comment #8 in
place, it didn't stop rpc.statd from being started before /var was
mounted, so it was not even helping in that manner.
--
mountall for /var races with rpc.statd
https://bugs.launchpad.net/bugs/525154
You received this bug notific
I think the suggested fix in comment #8 is absolutely evil. The
intentions are well-placed but the results of using that work-around are
evil and I believe lead to the sort of issues reported in bug #543506.
I still have to go to a few more machines and "undo" that change to be
completely sure. I
#13 doesn't work for me. The only viable workaround I know of is listing
the NFS mounts as noauto and adding them to /etc/rc.local individually
--
mountall for /var races with rpc.statd
https://bugs.launchpad.net/bugs/525154
You received this bug notification because you are a member of Ubuntu
Bu
This proposed workaround will cause a hang whenever portmap is restarted
on a package upgrade.
--
mountall for /var races with rpc.statd
https://bugs.launchpad.net/bugs/525154
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bu
Yes, that change works for me
start on ((started portmap and local-filesystems) or mounting TYPE=nfs)
--
mountall for /var races with rpc.statd
https://bugs.launchpad.net/bugs/525154
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
-
Anyone willing to try out this work around? `/etc/init/mountall` emits
local-filesystems so if you change line 6 of statd.conf to the
following things look to come up normally. This is probably a better
more sane solution then what I posted earlier.
start on ((started portmap and local-filesyst
On May 4, 2010, at 4:14 PM, Nathan Grennan wrote:
> I am the sysadmin for a company that uses Ubuntu for desktops, and uses
> nfs heavily. I upgraded to Lucid from Karmic, and everything has been
> fine. A co-worker upgraded, and ran into this bug. He tried the mounted
> MOUNTPOINT=/var workaround
I am the sysadmin for a company that uses Ubuntu for desktops, and uses
nfs heavily. I upgraded to Lucid from Karmic, and everything has been
fine. A co-worker upgraded, and ran into this bug. He tried the mounted
MOUNTPOINT=/var workaround. It actually seemed to make the problem
worse. The first t
On 04/30/2010 05:21 AM, Steve Langasek wrote:
> For users with a separate /var partition, yes. For users without, it causes
> statd to consistently fail to start at boot.
>
Oh yeah. That patch is a total kludge/hack we put in place so we could
quickly deploy Lucid. Will look forward to the act
On Thu, Apr 29, 2010 at 09:25:53PM -, ody wrote:
> Changing line 6 to the following fixes the problem.
> --- statd.conf 2010-04-29 14:22:27.567158573 -0700
> +++ /etc/init/statd.conf2010-04-29 14:18:56.057316910 -0700
> @@ -3,7 +3,7 @@
> description"NSM status monitor"
> author
Changing line 6 to the following fixes the problem.
--- statd.conf 2010-04-29 14:22:27.567158573 -0700
+++ /etc/init/statd.conf2010-04-29 14:18:56.057316910 -0700
@@ -3,7 +3,7 @@
description"NSM status monitor"
author "Steve Langasek "
-start on (started portmap or mounting
This is rather an unacceptable race condition. This will once again
cause me an enormous amount of pain in upgrading my nearly 200 Ubuntu
servers and desktops that all mount a substantial amount of stuff over
NFS, including user home directories.
--
mountall for /var races with rpc.statd
https://
Per bug 555661 is there a change in upstart .conf file dependencies that
you would like me to test/try?
You said in bug 555661 comment 12:
> > So for lucid, I'm still inclined to update the statd job to 'start on
> > local-filesystems'. Possibly 'start on (local-filesystems and mounting
> > TYPE=n
> I'm not sure exactly what "local-filesystems" signal is signalling but
> assuming it really does mean "local" (i.e. directly attached block
> devices) is there any reason the boolean operator in the condition for
> starting statd is not "and" rather than "or"?
Because due to a bug in upstart, t
On Thu, 2010-02-25 at 13:35 +, Steve Langasek wrote:
> statd is "start on (started portmap or mount TYPE=nfs)"
> portmap is "start on (local-filesystems and net-device-up IFACE=lo)"
I'm not terribly conversant on the state language of upstart yet, but
does the above say that statd will be sta
statd is "start on (started portmap or mount TYPE=nfs)"
portmap is "start on (local-filesystems and net-device-up IFACE=lo)"
and the statd job tries to start portmap if it's not already running.
So the only possible race conditions I see here are if
- mount TYPE=nfs is emitted before all the loc
On Wed, 2010-02-24 at 15:06 +, Scott James Remnant wrote:
> The whole /var thing is not really a very well thought out part of the
> FHS
OK. What does that mean in terms of this bug though?
--
mountall for /var races with rpc.statd
https://bugs.launchpad.net/bugs/525154
You received this b
The whole /var thing is not really a very well thought out part of the
FHS
** Package changed: upstart (Ubuntu) => nfs-utils (Ubuntu)
--
mountall for /var races with rpc.statd
https://bugs.launchpad.net/bugs/525154
You received this bug notification because you are a member of Ubuntu
Bugs, whic
101 - 120 of 120 matches
Mail list logo
