* Previous message: Behaviour of mounting event
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, 2010-08-31 at 13:34 +0100, Scott James Remnant wrote:
> On Fri, 2010-08-27 at 23:30 +1000, Andrew Edmunds wrote:
>
> > Suppose I have a job B which includes the foll
I just noticed that the underlying upstart issue mentioned in #8 is
already described by https://bugs.launchpad.net/upstart/+bug/530779. I
won't mark this as a duplicate though - the workaround described here
may be useful until the upstart bug is fixed.
--
Race condition in statd.conf
https://b
This is actually a (mis)feature of mountall, rather than upstart.
Mountall waits only for NFS mounts of /usr and /var, or their
subdirectories, to succeed before issuing the "filesystem" event. The
filesystem event is what triggers gdm to start.
To wait for any other NFS filesystem you have to ad
Tested on Maverick alpha 3 and confirmed that this bug is still present.
Debdiff for Maverick attached.
** Patch added: "nfs-utils_1.2.2-1ubuntu2.debdiff"
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/610863/+attachment/1497666/+files/nfs-utils_1.2.2-1ubuntu2.debdiff
--
Race condi
apport information
** Tags added: apport-collected
** Description changed:
Binary package hint: mountall
Binary package hint: mountall
mountall version: 2.15
On my Lucid system with latest updates, NFS filesystems sometimes fail to
mount successfully at boot. After a boot where th
** Description changed:
- Binary package hint: mountall
+ Binary package hint: nfs-common
+ nfs-common version: 1:1.2.0-4ubuntu4
- On my Lucid system with latest updates, NFS filesystems sometimes fail to
mount successfully at boot. After a boot where the NFS mounts fail, the
mountall proce
apport information
** Tags added: apport-collected
** Description changed:
Binary package hint: mountall
On my Lucid system with latest updates, NFS filesystems sometimes fail to
mount successfully at boot. After a boot where the NFS mounts fail, the
mountall process is still running w
The above patch forces another retry of NFS mounts after statd is
running. This is in no way a proper fix for the upstart issues
described in #3 but it does (at last) allow my system to mount its
filesystems reliably on boot.
--
mountall races with statd startup
https://bugs.launchpad.net/bugs/6
** Patch added: "Patch for mountall-net.conf"
http://launchpadlibrarian.net/53104530/mountall-net.conf.patch
--
mountall races with statd startup
https://bugs.launchpad.net/bugs/613825
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
statd's start condition is:
start on (started portmap or mounting TYPE=nfs)
A "mounting TYPE=nfs" event while statd is stopped will cause statd to
be started and mountall will block untill statd is running. However if
statd is triggered by portmap and then a "mounting TYPE=nfs" event
occurs whil
** Attachment added: "/var/log/syslog boot messages, debug output - NFS mounts
failed"
http://launchpadlibrarian.net/53099028/syslog.2010-08-05-20-33.failed
--
mountall races with statd startup
https://bugs.launchpad.net/bugs/613825
You received this bug notification because you are a member
** Attachment added: "/var/log/boot.log, debug output - NFS mounts failed"
http://launchpadlibrarian.net/53099000/boot.log.2010-08-05-20-33.failed
--
mountall races with statd startup
https://bugs.launchpad.net/bugs/613825
You received this bug notification because you are a member of Ubuntu
Public bug reported:
Binary package hint: mountall
Binary package hint: mountall
mountall version: 2.15
On my Lucid system with latest updates, NFS filesystems sometimes fail to mount
successfully at boot. After a boot where the NFS mounts fail, the mountall
process is still running when I log
The above patch adds a post-start script that loops until the statd
parent process has exited. This is the best workaround that I can think
of. It doesn't seem possible to just wait() for the process with the
current implementation of upstart's "expect fork" feature.
Suggestion for a better appr
** Package changed: mountall (Ubuntu) => nfs-utils (Ubuntu)
** Summary changed:
- mountall races with statd startup
+ Race condition in statd.conf
** Patch added: "Patch for nfs-common.statd.upstart"
http://launchpadlibrarian.net/53096369/statd_post-start.patch
--
Race condition in statd.c
In the above output there are 5 examples where upstart has marked statd
as running but the parent process still exists, which implies that statd
is not ready to service client requests.
--
mountall races with statd startup
https://bugs.launchpad.net/bugs/610863
You received this bug notification
** Attachment added: "Proof that statd startup has a race condition"
http://launchpadlibrarian.net/52772465/statd_race.out
--
mountall races with statd startup
https://bugs.launchpad.net/bugs/610863
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribe
I scanned quickly through the source of relevant packages. The
following lines caught my eye (upstart-0.6.5/init/job_process.c around
line 1394):
nih_info (_("%s %s process (%d) became new process (%d)"),
job_name (job), process_name (process),
job->pid
Theory A:
A "mounting TYPE=nfs" event while statd is stopped will cause statd to be
started and mountall will block untill statd is running. However a "mounting
TYPE=nfs" event while statd is in (say) pre-start or spawned state is ignored
and does not block mountall. Therefore it is not guaran
** Attachment added: "/var/log/syslog boot messages, verbose logging - NFS
mounts failed"
http://launchpadlibrarian.net/52637429/syslog.2010-07-28-21-59
--
mountall races with statd startup
https://bugs.launchpad.net/bugs/610863
You received this bug notification because you are a member of
** Attachment added: "/var/log/boot.log with verbose logging - NFS mounts
failed"
http://launchpadlibrarian.net/52637356/boot.log.2010-07-28-21-59.failed
--
mountall races with statd startup
https://bugs.launchpad.net/bugs/610863
You received this bug notification because you are a member of
I did the following to get more verbose logging:
--- etc/default/grub.20100728 2010-07-28 18:15:41.536842847 +1000
+++ etc/default/grub2010-07-28 21:57:45.144891535 +1000
@@ -6,7 +6,7 @@
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || ech
** Attachment added: "/var/log/syslog boot messages, default log level, NFS
mounts failed"
http://launchpadlibrarian.net/52637083/syslog.2010-07-28-21-52
--
mountall races with statd startup
https://bugs.launchpad.net/bugs/610863
You received this bug notification because you are a member of
** Attachment added: "/var/log/boot.log with default log level - NFS mounts
failed"
http://launchpadlibrarian.net/52636934/boot.log.2010-07-28-21-52.failed
--
mountall races with statd startup
https://bugs.launchpad.net/bugs/610863
You received this bug notification because you are a member
** Attachment added: "/etc/fstab"
http://launchpadlibrarian.net/52636789/fstab
--
mountall races with statd startup
https://bugs.launchpad.net/bugs/610863
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
u
Public bug reported:
Binary package hint: mountall
On my Lucid system with latest updates, NFS filesystems sometimes fail to mount
successfully at boot. After a boot where the NFS mounts fail, the mountall
process is still running when I log in. Running "kill -USR1 $(pidof mountall)"
will th
26 matches
Mail list logo
