[Bug 613825] Re: mountall races with statd startup
Apparently the upstart behaviour described here is as designed. See discussion below from the upstart-devel mailing list. That being the case, I think the fix I have already posted may be the best one available. Scott James Remnant scott at netsplit.com Wed Sep 1 13:31:33 BST 2010 * 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 following stanza: > > > > start on (started A or mounting MOUNTPOINT=/m) > > Ah, sorry, for some reason I read "and" here - using "or" like this, the following would be an expected behaviour. > > It seems that the following sequence of events can occur: > > 1. "started A" event is emitted > > 2. Job B starts > > 3. "mounting MOUNTPOINT=/m" event is emitted > > 4. "mounting MOUNTPOINT=/m" event completes > > 5. mountall attempts to mount /m > > 6. Job B's main process is started > > 7. Job B is marked as "running" Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? -- Andrew Edmunds Andrew.Edmunds at yahoo.com.au Wed Sep 1 12:21:31 BST 2010 Scott, The job I'm interested in is Ubuntu's statd. The real start condition is: start on (started portmap or mounting TYPE=nfs) For an example where this seems to be misbehaving see boot.log and syslog attached to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/613825 Here is an edited version with line numbers added to show what I mean. [boot.log] 159 init: portmap state changed from post-start to running 167 init: statd goal changed from stop to start 179 init: statd state changed from starting to pre-start^M^M 180 init: statd pre-start process (686) 598 init: event_new: Pending mounting event 602 init: Handling mounting event^M^M 603 init: event_pending_handle_jobs: New instance statd^M^M 604 init: event_finished: Finished mounting event^M^M 605 mounting /multimedia^M 628 spawn: mount -t nfs -o _netdev diskbox.local:/share/multimedia /multimedia 642 spawn: mount /multimedia [742] 706 mount.nfs: rpc.statd is not running but is required for remote locking. 707 mount.nfs: Either use '-o nolock' to keep locks local, or start statd. [syslog] 906 Aug 5 20:33:55 tvbox rpc.statd[773]: Version 1.1.6 Starting 907 Aug 5 20:33:55 tvbox rpc.statd[773]: Flags: 995 Aug 5 20:33:55 tvbox init: statd state changed from post-start to running It seems pretty clear that the mounting events here do not block and wait for statd to reach the running state. statd is finally running at syslog line 995 but this is long after the last attempt by mountall to mount the NFS filesystem. -- Scott James Remnant scott at netsplit.com Tue Aug 31 13:34:09 BST 2010 On Fri, 2010-08-27 at 23:30 +1000, Andrew Edmunds wrote: > Suppose I have a job B which includes the following stanza: > > start on (started A or mounting MOUNTPOINT=/m) > > It seems that the following sequence of events can occur: > 1. "started A" event is emitted > 2. Job B starts > 3. "mounting MOUNTPOINT=/m" event is emitted > 4. "mounting MOUNTPOINT=/m" event completes > 5. mountall attempts to mount /m > 6. Job B's main process is started > 7. Job B is marked as "running" > This is wrong; the correct sequence should be 1, 2, 3, 6, 7, 4, 5 If you're seeing the above, there's a problem somewhere - could you attach your job configuration file? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? -- Andrew Edmunds Andrew.Edmunds at yahoo.com.au Fri Aug 27 14:30:46 BST 2010 Hi, Suppose I have a job B which includes the following stanza: start on (started A or mounting MOUNTPOINT=/m) It seems that the following sequence of events can occur: 1. "started A" event is emitted 2. Job B starts 3. "mounting MOUNTPOINT=/m" event is emitted 4. "mounting MOUNTPOINT=/m" event completes 5. mountall attempts to mount /m 6. Job B's main process is started 7. Job B is marked as "running" So the "start on" stanza fails to guarantee that job B is actually running before /m is mounted. mounting(7) says that mountall will "wait for all services started by this event to be running ... before proceeding with mounting the filesystem." The above behaviour is consistent with that, since job B was not triggered by the mounting event. However, the behaviour doesn't seem very useful. I would suggest that mountall needs to wait until all services that *would be* started by this event are running, even if
[Bug 610863] Re: Race condition in statd.conf
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://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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 606554] Re: upstart allows gdm to start before all nfs shares have mounted
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 add the option "bootwait" to the /etc/fstab entry. See paragraph about mountall in fstab(5). So in this case adding "bootwait" to the options for /home should fix the issue. The filesystem(7) man page says "The filesystem event is generated by the mountall(8) daemon after it has mounted all filesystems listed in fstab(5)" but this is a blatant lie. Personally I would prefer to see the behaviour altered to match what this man page says, but failing that the man page should be corrected. Either way there is definitely a bug here. I think the motivation for the current behaviour was to cater for people who have wireless networking that doesn't come up until the user logs in and yet still have NFS mounts listed in fstab. I believe those people should be using the "noauto" or "nobootwait" options on their NFS mounts, or leaving them out of fstab altogether. Failing to do so is just a user error in my opinion and mountall shouldn't be pandering to people who misconfigure their system in this way. -- upstart allows gdm to start before all nfs shares have mounted https://bugs.launchpad.net/bugs/606554 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: Race condition in statd.conf
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 condition in statd.conf 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 613825] Re: mountall races with statd startup
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 the NFS mounts fail, the mountall process is still running when I log in. Running "kill -USR1 $(pidof mountall)" will then mount the missing filesystems sucessfully. The symptoms are very similar to this bug back in Karmic: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/445181 This problem still occurs after applying the patch proposed in https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/610863/comments/11 + --- + Architecture: i386 + DistroRelease: Ubuntu 10.04 + InstallationMedia: Mythbuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100427.1) + NonfreeKernelModules: nvidia + Package: mountall 2.15 + PackageArchitecture: i386 + ProcEnviron: + LANG=en_AU.UTF-8 + SHELL=/bin/bash + ProcVersionSignature: Ubuntu 2.6.32-23.37-generic-pae 2.6.32.15+drm33.5 + Tags: lucid + Uname: Linux 2.6.32-23-generic-pae i686 + UserGroups: ** Attachment added: "Dependencies.txt" https://bugs.edge.launchpad.net/bugs/613825/+attachment/1495044/+files/Dependencies.txt ** 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 the NFS mounts fail, the mountall process is still running when I log in. Running "kill -USR1 $(pidof mountall)" will then mount the missing filesystems sucessfully. The symptoms are very similar to this bug back in Karmic: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/445181 This problem still occurs after applying the patch proposed in https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/610863/comments/11 - --- + --- Architecture: i386 DistroRelease: Ubuntu 10.04 InstallationMedia: Mythbuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100427.1) NonfreeKernelModules: nvidia Package: mountall 2.15 PackageArchitecture: i386 ProcEnviron: - LANG=en_AU.UTF-8 - SHELL=/bin/bash + LANG=en_AU.UTF-8 + SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.32-23.37-generic-pae 2.6.32.15+drm33.5 Tags: lucid Uname: Linux 2.6.32-23-generic-pae i686 UserGroups: -- 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. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: Race condition in statd.conf
** 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 process is still running when I log in. Running "kill -USR1 $(pidof mountall)" will then mount the missing filesystems sucessfully. The symptoms are very similar to this bug back in Karmic: + On my Lucid system with latest updates, NFS filesystems sometimes fail + to mount successfully at boot. + + Steps to reproduce: + 1. In /etc/fstab, add an entry of the form: + :nfs_netdev 0 0 + 2. Reboot a number of times + + Expected results: + The NFS filesystem should be mounted on every boot + + Actual results: + Occasionally the NFS mount fails and messages of the following form are logged in /var/log/boot.log: + mount.nfs: rpc.statd is not running but is required for remote locking. + mount.nfs: Either use '-o nolock' to keep locks local, or start statd. + mountall: mount [] terminated with status 32 + + After a boot where the NFS mounts fail, the mountall process is still running on login. Running: + kill -USR1 $(pidof mountall) + will then mount the missing filesystems sucessfully. + + It is also possible to observe the problem without rebooting as follows. + + Steps to reproduce: + Run the following shell loop, after setting $nfs_server, $share and $mntpt to suitable values + + i=0 + while (( i < 100 )) + do + stop statd + start statd + mount.nfs $nfs_server:$share $mntpt + umount $mntpt + (( i++ )) + done + + Expected results: + The NFS filesystem should be mounted on every iteration of the loop + + Actual results: + Occasionally the NFS mount fails and the following messages are output: + + mount.nfs: rpc.statd is not running but is required for remote locking. + mount.nfs: Either use '-o nolock' to keep locks local, or start statd. + mount.nfs: an incorrect mount option was specified + umount: not mounted + + The symptoms are very similar to this bug back in Karmic: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/445181 - mountall version: 2.15 - --- + --- Architecture: i386 DistroRelease: Ubuntu 10.04 InstallationMedia: Mythbuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100427.1) NonfreeKernelModules: nvidia Package: nfs-common 1:1.2.0-4ubuntu4 PackageArchitecture: i386 ProcEnviron: - SHELL=/bin/bash - LANG=en_AU.UTF-8 + SHELL=/bin/bash + LANG=en_AU.UTF-8 ProcVersionSignature: Ubuntu 2.6.32-23.37-generic-pae 2.6.32.15+drm33.5 Tags: lucid Uname: Linux 2.6.32-23-generic-pae i686 UserGroups: -- Race condition in statd.conf 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: Race condition in statd.conf
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 when I log in. Running "kill -USR1 $(pidof mountall)" will then mount the missing filesystems sucessfully. The symptoms are very similar to this bug back in Karmic: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/445181 mountall version: 2.15 + --- + Architecture: i386 + DistroRelease: Ubuntu 10.04 + InstallationMedia: Mythbuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100427.1) + NonfreeKernelModules: nvidia + Package: nfs-common 1:1.2.0-4ubuntu4 + PackageArchitecture: i386 + ProcEnviron: + SHELL=/bin/bash + LANG=en_AU.UTF-8 + ProcVersionSignature: Ubuntu 2.6.32-23.37-generic-pae 2.6.32.15+drm33.5 + Tags: lucid + Uname: Linux 2.6.32-23-generic-pae i686 + UserGroups: ** Attachment added: "Dependencies.txt" https://bugs.edge.launchpad.net/bugs/610863/+attachment/1493220/+files/Dependencies.txt -- Race condition in statd.conf 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 613825] Re: mountall races with statd startup
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/613825 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 613825] Re: mountall races with statd startup
** 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. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 613825] Re: mountall races with statd startup
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 while statd is in (say) pre-start or spawned state, the event is
ignored and does not block mountall. Therefore it is not guaranteed that
statd is in running state when mountall calls mount.nfs.
This seems to come down to the semantics of the "mounting" event. mounting(7)
says:
"mountall(8) will wait for all services started by this event to be running,
all tasks started by this event to have finished and all jobs stopped by this
event to be stopped before proceeding with mounting the filesystem."
Waiting for "all services started by this event" is not good enough to
guarantee that services the mount depends on will actually be running
after the event completes. What is required is to wait for all services
that *would be* started by this event to be running, even if they were
actually started by something else.
If I've understood the code right, the implementation of this is in
upstart-0.6.5/init/event.c, function event_pending_handle_jobs() :
nih_debug ("New instance %s", job_name (job));
/* Start the job with the environment we want */
if (job->goal != JOB_START) {
if (job->start_env)
nih_unref (job->start_env, job);
job->start_env = env;
nih_ref (job->start_env, job);
job_finished (job, FALSE);
event_operator_events (job->class->start_on,
job, &job->blocking);
job_change_goal (job, JOB_START);
}
where event_operator_events() does the actual blocking and it only gets
called in the case that the job's goal is changed to JOB_START.
Judging by their man pages, the "starting" and "stopping" events may
have similar issues.
--
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.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 613825] Re: mountall races with statd startup
** 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 of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 613825] Re: mountall races with statd startup
** 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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 613825] [NEW] mountall races with statd startup
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 in. Running "kill -USR1 $(pidof mountall)" will then mount the missing filesystems sucessfully. The symptoms are very similar to this bug back in Karmic: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/445181 This problem still occurs after applying the patch proposed in https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/610863/comments/11 ** Affects: mountall (Ubuntu) Importance: Undecided Status: New -- 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. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: Race condition in statd.conf
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 approach: The start script should be allowed to tell upstart the PID of the process that upstart should supervise. The information could be sent (for example) via a pipe, or the traditional /var/run/.pid file. Then the knowledge of how to correctly start a particular daemon could be entirely in the start script where it belongs, rather than part of it being coded into upstart. This would allow the "expect fork" and "expect daemon" features to go away. -- Race condition in statd.conf 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: mountall races with statd startup
** 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.conf 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: mountall races with statd startup
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 because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: mountall races with statd startup
** 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 subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: mountall races with statd startup
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[process], (pid_t)data);
/* We no longer care about this process, it's the child that we're
* interested in from now on, so detach it and allow it to go about
* its business unhindered.
*/
The comment here is revealing. statd takes care not to let its parent
process exit until the child is ready to service client requests. I
think the sysvinit startup scripts depended on this. If upstart
completely ignores the parent as soon as it has forked, this would
introduce a race as per theory B above.
--
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: mountall races with statd startup
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 guaranteed that statd is in running state when mountall calls mount.nfs. Theory B: statd is not really ready for business when upstart marks it as "runnning". It needs a post-start script that waits while it does initialization tasks such as registering with portmap. I have not so far dug into the source sufficiently to prove or rule out either of these. The log that I posted seems to support theory B but I have other examples that seem more consistent with theory A. -- 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: mountall races with statd startup
** 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 Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: mountall races with statd startup
** 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 Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: mountall races with statd startup
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 || echo Debian` -GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" +GRUB_CMDLINE_LINUX_DEFAULT="--verbose" GRUB_CMDLINE_LINUX="" # Uncomment to disable graphical terminal (grub-pc only) ... and ... --- etc/init/mountall.conf.20100728 2010-04-26 15:46:36.0 +1000 +++ etc/init/mountall.conf 2010-07-28 21:58:14.917391034 +1000 @@ -28,7 +28,7 @@ [ -f /forcefsck ] && force_fsck="--force-fsck" [ "$FSCKFIX" = "yes" ] && fsck_fix="--fsck-fix" -exec mountall --daemon $force_fsck $fsck_fix +exec mountall --daemon --verbose $force_fsck $fsck_fix end script post-stop script -- 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: mountall races with statd startup
** 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 Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: mountall races with statd startup
** 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 of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] Re: mountall races with statd startup
** 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 610863] [NEW] mountall races with statd startup
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 then mount the missing filesystems sucessfully. The symptoms are very similar to this bug back in Karmic: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/445181 mountall version: 2.15 ** Affects: mountall (Ubuntu) Importance: Undecided Status: New -- 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
