On 24.09.2012 14:43, Marc Lehmann wrote: [-symlink option apparently added by previous maintainer]
>> Aha. I didn't know that. This is actually rather bad, maybe we should >> add a compatibility option too, -- because right now, when I specify >> -nosymlink, it is passed to mount.nfs, and the result is, well, wrong >> ofcourse. I'll dig into that. > > Well, that would be great, but I don't think that has a great future. It > tends to fall through the cracks, and is extra work, and makes debian > differ from the standard distro without good hope of getting the behaviour > in. I mean, I don't want to break users' boxes like in your case because some option is no longer recognized. Accepting it and doing nothing (or printing a warning) is not a big deal really. >> Oh well. But heck, we can't do that for wheezy at least :) > > I switched to amd for most of my boxes. For the ones where I can't, I > switched to this (no kidding) to start automount: > > /usr/bin/perl -i -pe 's%/tmp/aut%\x01/\x03/\x05/\x07\x00%g' > /usr/lib/x86_64-linux-gnu/autofs/mount_bind.so Wow. > that breaks the test for bind mounts so it thinks bind mounts do not work. > That works fine for me as I haven't found any use for bind mounts yet, but > have lots of problems (as reported, but not being able to unmount local > filesystem without ALSO taking care of automount is annoying as wlel :). Well, it was meant as an optimisation. Maybe these can also be addressed somehow. Note that nfs-mounts wont let you to umount local filesystems too. But okay. > (I did consider going back to automount using this hack, because amd does > not have working multi-maps (but my config fortunately doesn't rely on > those yet), and with this hack, it works for me). >> Now, having said all that, maybe it is a stupid idea to ask you for some >> testing/comments on the new package I created, preliminary version of >> stuff I want to upload, located at http://www.corpit.ru/mjt/tmp/autofs/ ? > > Well, I have the obligation to test :) I'll install it later and see if I > can replicate the test (maybe give me a few days :). Actually you don't have any obligations here. The thing is: you reported a bug, and I see it is now fixed, at least here for me it works now without segfaulting. I was mostly asking you about any OTHER issue you may also have, since you appears to have a good love for autofs and its issues :) >> Thank you for your patience (or lack thereof)! :) > > Well, my guess is that many automount users don't have long-term patience > - they usually have to administrate a flock of boxes that just need to > work somehow :) I "fixed" it here by using static fstab entries at the end. Annoying, but autofs didn't fix an issue for me which I hoped it to fix. To me the problem was for two servers to be able to boot them in any order without one failing because another isn't booted up yet. One mounts nfs share from another, so automount fixes this mount issue (when it works ofcourse!), but these mounts are used by other software (it is Oracle database in our case), and it fails anyway without seeing the dirs. So.. no difference in the end result. > My primary motivation for reporting bugs is to make them known, either > for others to learn about their status when they hit the same issue, or > to get them fixed. > > If I sounded like demanding a fix, then that wasn't my intention, sorry > for that! No, you didn't sound like that, and you raised valid concerns about overall code quality and maintenance. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org