[Dovecot] a few questions about my experience with alpha1

newer
[Dovecot] ssl + dovecot + debian...

older
[Dovecot] Problem with pop3 and...

Glenn Leavell

25 Aug 2005 25 Aug '05

5:54 a.m.

Hi all,

I've just switched from 0.99.10.6 to alpha1 on a Solaris 9 system, and I have a few questions:

I'm using "verbose_proctitle = yes" but I don't see the special username or IP address information in the output of ps. I've used:

ps -fu dovecot ps -ef | grep dovecot /usr/ucb/ps aux | grep dovecot

The process table simply shows the /usr/local/sbin/dovecot, dovecot-auth, and imap-login processes. Is there something else that I need to do, or is there a special way that I should use ps?

After sending dovecot a HUP signal, the logs will report something like:

Warning: SIGHUP received - reloading configuration

And everything seems to work fine. However, *sometimes* after sending a HUP signal, logging will stop indefinitely. Has anyone else noticed anything similar?

We use UW in production, and I'm new to any real use of namespaces. Almost all of our clients use the root "~/Mail/" to find their folders (in $HOME/Mail/) and their INBOXes are located in $HOME/.inbox. A few people actually find their folders with the direct path Mail/foldername. So, I'm trying to configure Dovecot to work with any of these roots / prefixes:

~/Mail/ Mail/ "" (empty/blank)

I'm using the namespace configuration below, and it seems to work with any of the above prefixes. However, the logging that I see makes me wonder if I'm doing it the best way. Note the attached log file. All of this output was generated with this single IMAP command:

A01 LOGIN bozo mypassword

Here's my configuration:

# Default namespace private { separator = / prefix = location = mbox:%h/Mail/:INBOX=%h/.inbox:INDEX=%h/Mail/ inbox = yes hidden = no }

# This is the standard ~/Mail/ namespace that our clients tend to use namespace private { separator = / prefix = ~/Mail/ location = mbox:%h/Mail/ hidden = yes }

# This namespace is for a few folks who might actually try to # directly access "Mail/foldername" -- as if they were accessing a real # filesystem path. namespace private { separator = / prefix = Mail/ location = mbox:%h/Mail/ hidden = yes }

So, is this the best way to configure the namespaces for what I'm trying to accomplish? And any pointers on how to interpret what Dovecot is working through with regard to the attached logs would be appreciated. Notice the "Sending log messages too fast, throttling.." message (again, generated from that single login command). What might be causing that?

By the way, is there any real difference between the use of %h/Mail and the possible use of ~/Mail in the location fields above?

Thanks very much!

-- Glenn Leavell glenn@usg.edu Office of Information and Instructional Technology Board of Regents of the University System of Georgia

Attachments:

dovecot.log (text/plain — 1.5 KB)

Show replies by date

Curtis Maloney

25 Aug 25 Aug

6 a.m.

Glenn Leavell wrote:

...

Hi all,

I've just switched from 0.99.10.6 to alpha1 on a Solaris 9 system, and I have a few questions:

I'm using "verbose_proctitle = yes" but I don't see the special username or IP address information in the output of ps. I've used:

ps -fu dovecot ps -ef | grep dovecot /usr/ucb/ps aux | grep dovecot

In most configurations, Dovecot will run the 'imap' program as the user, so you'll likely find (as I do) that you want to use:

ps -ef | grep imap

-- Curtis Maloney cmaloney@cardgate.net

Glenn Leavell

4:42 p.m.

On Thu, Aug 25, 2005 at 01:00:06PM +1000, Curtis Maloney wrote:

...

Glenn Leavell wrote:

...
Hi all,

I've just switched from 0.99.10.6 to alpha1 on a Solaris 9 system, and I have a few questions:

I'm using "verbose_proctitle = yes" but I don't see the special username or IP address information in the output of ps. I've used:

ps -fu dovecot ps -ef | grep dovecot /usr/ucb/ps aux | grep dovecot

In most configurations, Dovecot will run the 'imap' program as the user, so you'll likely find (as I do) that you want to use:

ps -ef | grep imap

Thanks very much. That was it: I was looking only at the "dovecot," "dovecot-auth," and "imap-login" processes, so I was missing the "imap" processes with the extended proctitle information.

Thanks again, Glenn

-- Glenn Leavell glenn@usg.edu Office of Information and Instructional Technology Board of Regents of the University System of Georgia

Timo Sirainen

28 Aug 28 Aug

10:12 p.m.

On Wed, 2005-08-24 at 22:54 -0400, Glenn Leavell wrote:

...

After sending dovecot a HUP signal, the logs will report something like:

Warning: SIGHUP received - reloading configuration

And everything seems to work fine. However, *sometimes* after sending a HUP signal, logging will stop indefinitely. Has anyone else noticed anything similar?

Is it only logging that stops, or does everything else stop as well? How about sending SIGHUP again, does it fix the problem? Or if not, does SIGUSR1 fix it (SIGUSR1 only reopens log files)?

...

We use UW in production, and I'm new to any real use of namespaces. Almost all of our clients use the root "~/Mail/" to find their folders (in $HOME/Mail/) and their INBOXes are located in $HOME/.inbox. A few people actually find their folders with the direct path Mail/foldername. So, I'm trying to configure Dovecot to work with any of these roots / prefixes: ... namespace private { separator = / prefix = location = mbox:%h/Mail/:INBOX=%h/.inbox:INDEX=%h/Mail/ inbox = yes hidden = no }

The INDEX=%h/Mail/ shouldn't be needed because the default directory is the same as the directory you gave after mbox:, ie. same one.

...

# This is the standard ~/Mail/ namespace that our clients tend to use namespace private { separator = / prefix = ~/Mail/ location = mbox:%h/Mail/ hidden = yes }

Shouldn't you also add :INBOX=%h/.inbox here?

...

namespace private { separator = / prefix = Mail/ location = mbox:%h/Mail/ hidden = yes }

And here?

...

So, is this the best way to configure the namespaces for what I'm trying to accomplish? And any pointers on how to interpret what Dovecot is working through with regard to the attached logs would be appreciated. Notice the "Sending log messages too fast, throttling.." message (again, generated from that single login command). What might be causing that?

If it's finding everything correctly, then only problem you have is that you have set mail_debug=yes. The throttling message comes because imap process is sending log messages too quickly and Dovecot thinks it could benefit from having to be stalled for a while in case it's trying to flood your logs full.

...

By the way, is there any real difference between the use of %h/Mail and the possible use of ~/Mail in the location fields above?

%h works in all cases, ~/ works only after "mbox:" or "maildir:" string, so %h is preferred until the location/default_mail_env setting itself is split to multiple settings (in Dovecot 2.0).

Glenn Leavell

29 Aug 29 Aug

10:02 p.m.

On Sun, Aug 28, 2005 at 10:12:09PM +0300, Timo Sirainen wrote:

...

On Wed, 2005-08-24 at 22:54 -0400, Glenn Leavell wrote:

...

After sending dovecot a HUP signal, the logs will report something like:

Warning: SIGHUP received - reloading configuration

And everything seems to work fine. However, *sometimes* after sending a HUP signal, logging will stop indefinitely. Has anyone else noticed anything similar?

Is it only logging that stops, or does everything else stop as well? How about sending SIGHUP again, does it fix the problem? Or if not, does SIGUSR1 fix it (SIGUSR1 only reopens log files)?

Thanks very much for the followup and for the help. It's only the logging that stops; the service continues to run just fine. Sending another SIGHUP or a SIGUSR1 does NOT kickstart the logging once it's stopped. I can reproduce the problem consistently right now.

...

...

We use UW in production, and I'm new to any real use of namespaces. Almost all of our clients use the root "~/Mail/" to find their folders (in $HOME/Mail/) and their INBOXes are located in $HOME/.inbox. A few people actually find their folders with the direct path Mail/foldername. So, I'm trying to configure Dovecot to work with any of these roots / prefixes: ... namespace private { separator = / prefix = location = mbox:%h/Mail/:INBOX=%h/.inbox:INDEX=%h/Mail/ inbox = yes hidden = no }

The INDEX=%h/Mail/ shouldn't be needed because the default directory is the same as the directory you gave after mbox:, ie. same one.

Does this default also apply to the location of the index files for INBOX? INBOX is %h/.inbox, and I was attempting to consolidate all of the indexes in %h/Mail/.imap/

I read this in the docs:

Index files are by default stored under the same directory as mails. With maildir they are stored in the actual maildirs, with mbox they are stored under .imap/ directory. You can change these by adding :INDEX=location to location string.

And I took that to mean that index files for %h/.inbox would get stored in %h by default. I was thinking that having the index files for INBOX in the same place as the other index files might be nice in terms of organization, but there really may not be a good reason to force that.

...

...
# This is the standard ~/Mail/ namespace that our clients tend to use namespace private { separator = / prefix = ~/Mail/ location = mbox:%h/Mail/ hidden = yes }

Shouldn't you also add :INBOX=%h/.inbox here?

That seems reasonable. I think I was thrown off by this in the config file:

#There can be only one INBOX, and this setting defines which namespace #has it. inbox = yes

I took this to mean that it would be a good idea to have "inbox=yes" and a location for an INBOX path only in the default namespace, and that Dovecot would then find and include the INBOX when appropriate. But given your suggestion above, I obviously don't understand. What does the single "inbox=yes" setting do separate from the explicit listing of an INBOX path in multiple namespaces?

By the way, using the configuration above, where INBOX is only included in the default namespace, the command 'LIST "~/Mail/" *' DOES include INBOX among the list of returned folders:

* LIST (\Unmarked) "/" "INBOX"

Thanks again, Glenn

-- Glenn Leavell glenn@usg.edu Office of Information and Instructional Technology Board of Regents of the University System of Georgia

Timo Sirainen

24 Sep 24 Sep

4:33 p.m.

On Mon, 2005-08-29 at 15:02 -0400, Glenn Leavell wrote:

...

...
Is it only logging that stops, or does everything else stop as well? How about sending SIGHUP again, does it fix the problem? Or if not, does SIGUSR1 fix it (SIGUSR1 only reopens log files)?

Thanks very much for the followup and for the help. It's only the logging that stops; the service continues to run just fine. Sending another SIGHUP or a SIGUSR1 does NOT kickstart the logging once it's stopped. I can reproduce the problem consistently right now.

Where are you logging to? Syslog or some file? Could you try if changing it to other one makes it work again? Also when this happens, could you run "truss -p " and see if it's still doing write() calls to log?

...

...
...

We use UW in production, and I'm new to any real use of namespaces. Almost all of our clients use the root "~/Mail/" to find their folders (in $HOME/Mail/) and their INBOXes are located in $HOME/.inbox. A few people actually find their folders with the direct path Mail/foldername. So, I'm trying to configure Dovecot to work with any of these roots / prefixes: ... namespace private { separator = / prefix = location = mbox:%h/Mail/:INBOX=%h/.inbox:INDEX=%h/Mail/ inbox = yes hidden = no }

The INDEX=%h/Mail/ shouldn't be needed because the default directory is the same as the directory you gave after mbox:, ie. same one.

Does this default also apply to the location of the index files for INBOX? INBOX is %h/.inbox, and I was attempting to consolidate all of the indexes in %h/Mail/.imap/

Yes. The index directories are always under one directory.

...

I read this in the docs:

Index files are by default stored under the same directory as mails. With maildir they are stored in the actual maildirs, with mbox they are stored under .imap/ directory. You can change these by adding :INDEX=location to location string.

And I took that to mean that index files for %h/.inbox would get stored in %h by default.

I guess I wasn't just thinking about that INBOX special case when writing that.. :)

...

...
...
# This is the standard ~/Mail/ namespace that our clients tend to use namespace private { separator = / prefix = ~/Mail/ location = mbox:%h/Mail/ hidden = yes }

Shouldn't you also add :INBOX=%h/.inbox here?

That seems reasonable. I think I was thrown off by this in the config file:

#There can be only one INBOX, and this setting defines which namespace #has it. inbox = yes

I took this to mean that it would be a good idea to have "inbox=yes" and a location for an INBOX path only in the default namespace, and that Dovecot would then find and include the INBOX when appropriate. But given your suggestion above, I obviously don't understand. What does the single "inbox=yes" setting do separate from the explicit listing of an INBOX path in multiple namespaces?

No, you understood correctly. The first namespace that has inbox=yes will be used for "INBOX" mailbox. So I guess the other :INBOX settings aren't really useful.. :)

...

By the way, using the configuration above, where INBOX is only included in the default namespace, the command 'LIST "~/Mail/" *' DOES include INBOX among the list of returned folders:

LIST (\Unmarked) "/" "INBOX"

Yes. It lists INBOX even if you didn't define a namespace for it but just did eg. "LIST somemailbox/ *". That's how IMAP's LIST command works (it has pretty weird rules).

Glenn Leavell

28 Sep 28 Sep

8:47 p.m.

On Sat, Sep 24, 2005 at 04:33:51PM +0300, Timo Sirainen wrote:

...

On Mon, 2005-08-29 at 15:02 -0400, Glenn Leavell wrote:

...
...
Is it only logging that stops, or does everything else stop as well? How about sending SIGHUP again, does it fix the problem? Or if not, does SIGUSR1 fix it (SIGUSR1 only reopens log files)?

Thanks very much for the followup and for the help. It's only the logging that stops; the service continues to run just fine. Sending another SIGHUP or a SIGUSR1 does NOT kickstart the logging once it's stopped. I can reproduce the problem consistently right now.

Where are you logging to? Syslog or some file? Could you try if changing it to other one makes it work again? Also when this happens, could you run "truss -p " and see if it's still doing write() calls to log?

I've been logging to a file. The problem doesn't appear to be present when logging through syslog.

I ran truss, and dovecot *is* continuing to do write() calls to the log file, but I never see any output after sending a HUP signal after the resulting "Warning: SIGHUP received - reloading configuration" entry.

By the way, I've upgraded to Alpha3, and it behaves the same way.

Thanks!

Glenn

-- Glenn Leavell glenn@usg.edu Office of Information and Instructional Technology Board of Regents of the University System of Georgia

Timo Sirainen

16 Oct 16 Oct

1:36 p.m.

On Wed, 2005-09-28 at 13:47 -0400, Glenn Leavell wrote:

...

...
Where are you logging to? Syslog or some file? Could you try if changing it to other one makes it work again? Also when this happens, could you run "truss -p " and see if it's still doing write() calls to log?

I've been logging to a file. The problem doesn't appear to be present when logging through syslog.

Did you have info_log_path set? Looks like if log_path is set but info_log_path isn't, it breaks. Although with me it crashes instead of stopping writing.

Glenn Leavell

4:08 p.m.

On Sun, Oct 16, 2005 at 01:36:46PM +0300, Timo Sirainen wrote:

...

On Wed, 2005-09-28 at 13:47 -0400, Glenn Leavell wrote:

...
...
Where are you logging to? Syslog or some file? Could you try if changing it to other one makes it work again? Also when this happens, could you run "truss -p " and see if it's still doing write() calls to log?

I've been logging to a file. The problem doesn't appear to be present when logging through syslog.

Did you have info_log_path set? Looks like if log_path is set but info_log_path isn't, it breaks. Although with me it crashes instead of stopping writing.

No, I had not set info_log_path, and that was it. After setting it, logging continues to work as expected after a HUP. Thanks!

Glenn

-- Glenn Leavell glenn@usg.edu Office of Information and Instructional Technology Board of Regents of the University System of Georgia

Timo Sirainen

7:29 p.m.

On Sun, 2005-10-16 at 09:08 -0400, Glenn Leavell wrote:

...

...
Did you have info_log_path set? Looks like if log_path is set but info_log_path isn't, it breaks. Although with me it crashes instead of stopping writing.

No, I had not set info_log_path, and that was it. After setting it, logging continues to work as expected after a HUP. Thanks!

Well, it's fixed anyway in next release. :)

6978

Age (days ago)

7030

Last active (days ago)

List overview

9 comments

3 participants

participants (3)

Curtis Maloney
Glenn Leavell
Timo Sirainen