Re: [Dovecot] Mountpoints with auto mounter
On 16.9.2013, at 12.59, Steffen Kram s...@kram.io wrote: It would be great if there was a way to just disable the mount point tracking This should work: doveadm mount add '/*' ignore
[Dovecot] Mountpoints with auto mounter
Hi, I'm running dovecot on a OmniOS installation and I'm wondering what I can do about all those mount point warnings in my logfile. The problem occurs because of the running auto-mounter which manages my mail directories. Isn't it possible for dovecot just try to access the directories before logging an error message. Shall I remove the corresponding mount points from the list of tracked mount points with the doveadm mount-command? The documentation does say nothing about situation with an active auto mounter. Thanks for any suggestions. Cheers, Steffen signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Dovecot] Mountpoints with auto mounter
Am 16.09.2013 11:41, schrieb Steffen Kram: I'm running dovecot on a OmniOS installation and I'm wondering what I can do about all those mount point warnings in my logfile. The problem occurs because of the running auto-mounter which manages my mail directories. Isn't it possible for dovecot just try to access the directories before logging an error message. Shall I remove the corresponding mount points from the list of tracked mount points with the doveadm mount-command? The documentation does say nothing about situation with an active auto mounter. i generally do not understand why dovecot insists in warning about whatever mountpoints - what is the point that dovecot needs to care about anything ever mounted on a machine as long it is not referred in any configuration signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Mountpoints with auto mounter
i generally do not understand why dovecot insists in warning about whatever mountpoints - what is the point that dovecot needs to care about anything ever mounted on a machine as long it is not referred in any configuration I absolutely agree. In my opinion it is not the problem of dovecot if my mount points exists or not. If the only purpose is to track if a user already existed or if its a new user for whom directories and mailboxes have to be created. Or are there other use cases I just read http://wiki2.dovecot.org/Mountpoints. As pointed out in http://www.dovecot.org/list/dovecot/2012-January/063419.html there might be problems for dbox mailboxes, if the indexes are stored on a different mount. What's the point in doing that? It would be great if there was a way to just disable the mount point tracking if I don't store indexes on different mounts and don't use the dsync replication feature, even if it's just a compile time option. Cheers, Steffen signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Dovecot] Mountpoints with auto mounter
Am 16.09.2013 11:59, schrieb Steffen Kram: i generally do not understand why dovecot insists in warning about whatever mountpoints - what is the point that dovecot needs to care about anything ever mounted on a machine as long it is not referred in any configuration I absolutely agree. In my opinion it is not the problem of dovecot if my mount points exists or not. If the only purpose is to track if a user already existed or if its a new user for whom directories and mailboxes have to be created. Or are there other use cases I just read http://wiki2.dovecot.org/Mountpoints. As pointed out in http://www.dovecot.org/list/dovecot/2012-January/063419.html there might be problems for dbox mailboxes, if the indexes are stored on a different mount. What's the point in doing that? It would be great if there was a way to just disable the mount point tracking if I don't store indexes on different mounts and don't use the dsync replication feature, even if it's just a compile time option. and in case you are running dovecot only as a proxy it needs not to care about *any* mountpoint at all - consider the mess if every software out there would act this way. signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Mountpoints
On Mon, 30 Jan 2012, dovecot-requ...@dovecot.org wrote: So, I was thinking about adding doveadm commands to explicitly tell Dovecot about the mountpoints that it needs to care about. When no mountpoints are defined Dovecot would behave as it does now. Maybe I don't understand the subtlety of your question, but are you trying to disambiguate between a mounted filesytem and a failed mount that presents the underlying filesystem (which looks like an uninitilized index directory)? Couldn't you write some cookie file /mount/.../dovecot-data-root/.dovemount, whose existence will tell you whether the FS is mounted without trying to find the mount root. Oh, but then again if you have per-user mounts, that's going to get messy. Joseph Tam jtam.h...@gmail.com
Re: [Dovecot] Mountpoints
On 31.1.2012, at 2.03, Joseph Tam wrote: On Mon, 30 Jan 2012, dovecot-requ...@dovecot.org wrote: So, I was thinking about adding doveadm commands to explicitly tell Dovecot about the mountpoints that it needs to care about. When no mountpoints are defined Dovecot would behave as it does now. Maybe I don't understand the subtlety of your question, but are you trying to disambiguate between a mounted filesytem and a failed mount that presents the underlying filesystem (which looks like an uninitilized index directory)? Yes. A mounted filesystem where a directory doesn't exist vs. accidentally unmounted filesystem. Couldn't you write some cookie file /mount/.../dovecot-data-root/.dovemount, whose existence will tell you whether the FS is mounted without trying to find the mount root. This would require that existing installations create such a file or start failing after upgrade. Or that it's made optional and most people wouldn't use this functionality at all.. And I'm sure many people with a single filesystem wouldn't be all that happy creating /.dovemount or /home/.dovemount or such files.
[Dovecot] Mountpoints
I've been thinking about mountpoints recently. There have been a few problems related to them: - If dbox mails and indexes are in different filesystems, and index fs isn't mounted and mailbox is accessed - Dovecot rebuilds indexes from scratch, which changes UIDVALIDITY, which causes client to redownload mails. All mails will also show up as unread. Once index fs gets mounted again, the UIDVALIDITY changes again and client again redownloads mails. What should happen instead is that Dovecot simply refuses to rebuild indexes when the index fs isn't mounted. This isn't as critical for mbox/maildir, but probably a good idea to do there as well. - If dbox's alternative storage isn't mounted and a mail from there is tried to be accessed - Dovecot rebuilds indexes and sees that all mails in alt path are gone, so Dovecot also deletes them from indexes as well. Once alt fs is mounted again, the mails in there won't come back without manual index rebuild and then they have also lost flags and have updated UIDs causing clients to redownload them. So again what should happen is that Dovecot won't rebuild indexes while alt fs isn't mounted. - For dsync-based replication I need to keep a state of each mountpoint (online, offline, failover) to determine how to access user's mails. So in the first two cases the main problem is: How does Dovecot know where a mountpoint begins? If the mountpoint is actually mounted there is no problem, because there are functions to find it (e.g. from /etc/mtab). So how to find a mountpoint that should exist, but doesn't? In some OSes Dovecot could maybe read and parse /etc/fstab, but that doesn't exist in all OSes, and do all installations even have all of the filesystems listed there anyway? (They could be in some startup script.) So, I was thinking about adding doveadm commands to explicitly tell Dovecot about the mountpoints that it needs to care about. When no mountpoints are defined Dovecot would behave as it does now. doveadm mount add|remove path - add/remove mountpoint doveadm mount state [path [state]] - get/set state of mountpoint (used by replication) - if path isn't given list states of all mountpoints List of mountpoints is kept in /var/lib/dovecot/mounts. But because the dovecot directory is only accessible to root (and probably too much trouble to change that), there's another list in /var/run/dovecot/mounts. This one also contains the states of the mounts. When Dovecot starts up and can't find the mounts from rundir, it creates it from vardir's mounts. When mail processes notice that a directory is missing, it usually autocreates it. With mountpoints enabled, Dovecot first finds the root mountpoint for the directory. The mount root is stat()ed and its parent is stat()ed. If their device numbers equal, the filesystem is unmounted currently, and Dovecot fails instead of creating a new directory. Similar logic is used to avoid doing a dbox rebuild if its alt dir is currently in unmounted filesystem. The main problem I see with all this is how to make sysadmins remember to use these commands when they add/remove mountpoints?.. Perhaps the additions could be automatic at startup. Whenever Dovecot sees a new mountpoint, it's added. If an old mountpoint doesn't exist at startup a warning is logged about it. Of course many of the mountpoints aren't intended for mail storage. They could be hidden from the mount state list by setting their state to ignore. Dovecot could also skip some of the common known mountpoints, such as where type is proc/tmpfs/sysfs. Thoughts?
Re: [Dovecot] Mountpoints
On 30.1.2012, at 8.31, Timo Sirainen wrote: The main problem I see with all this is how to make sysadmins remember to use these commands when they add/remove mountpoints?.. Perhaps the additions could be automatic at startup. Whenever Dovecot sees a new mountpoint, it's added. If an old mountpoint doesn't exist at startup a warning is logged about it. Of course many of the mountpoints aren't intended for mail storage. They could be hidden from the mount state list by setting their state to ignore. Dovecot could also skip some of the common known mountpoints, such as where type is proc/tmpfs/sysfs. I wonder how automounts would work with this.. Probably rather randomly..
