FreeBSD 10 & default_vsz_limit causing reboots?

[Remko Lodder]

Hi,

> Op 15 september 2015 om 14:52 schreef Rick Romero <rick at havokmon.com>:
> 
> 
> Ok,
> 
> So this is really more of an observation than anything else. 
> 
> I had a FreeBSD 10.1 server that was running great. Some SSL issue came up,
> or I upgrade Dovecot in ports - something occurred and the machine started
> rebooting randomly.  It would run for 2 weeks, then reboot.  It might run
> for 5 days and then reboot. So I started doing more FreeBSD upgrades,
> thinking it was a kernel issue. The reboots only increased. 
> 
> This weekend I started thinking I might actually be having hardware
> issues.  But, since I don't have easy physical access to the box and it's
> REALLY under loaded, I figured what the hell and upraded to 10.2 on
> Sunday.  I think it rebooted 4 times after that on Sunday, and then
> another 2 times Monday morning. 
> 
> Its worth noting that while I have crash dumps enabled, they don't seem to
> be occurring.  So hardware is still a possibility.

Jumping in at some point here, as FreeBSD dev I run most of my servers on
FreeBSD. All my mailservers are running FreeBSD.
My customer backend servers run Dovecot on FreeBSD. we have a few hundred
mailboxes (not that many). I upgrade all my packages
and system whenever there are updates and I figured out whether they are OK or
not. That means that I most likely do more upgrades
then you do at the moment.

I never ever had the symptoms you describe nor did I need to tweak settings.

Given this is a "FreeBSD"box crashing I thought I should reply. I think you need
to contact the FreeBSD devs (other then me) to ask what is going on.
Perhaps you can do a backtrace on the dump to see what was going on. If you
installed panicmail (a tool by Colin Percival) it will automatically create
an informative email which describes the issue more or less ..

Please poke me offline when I can help you more with that.

Cheers
Remko(@FreeBSD.org)

> 
> After the 2nd Monday morning reboot, I started to wonder if there was some
> sort of process issue.  Besides the OS upgrades - I had been monitoring
> the Dovecot logs for when the process limits are reached, and increasing
> them.  It's a 'big' box, and load is typically between .30 and .50. CPUs
> aren't overtaxed, and most of the memory is dedicated to ZFS.  The reboots
> are so short, I've only received one 'down' alert due to them. So it's a
> conerning issue, but not really impacting production.
> 
> On a whim I changed my default_vsz_limit (as I had been increasing every
> other limit but that) from 384M to 512M.  The system hasn't rebooted in
> 24hours.
> 
> Now that could be a coincidence, but I thought I'd at least put it out
> there.
> 
> If you see anything weird in my dovecot config, let me know - My config was
> originally vpopmail, but over time I've migrated to SQL-only.
> 
> root at romulus:/usr/local/etc/dovecot # dovecot -n
> # 2.2.18: /usr/local/etc/dovecot/dovecot.conf
> # OS: FreeBSD 10.2-RELEASE amd64
> auth_master_user_separator = *
> auth_mechanisms = plain login
> auth_username_translation = %@
> auth_verbose = yes
> default_login_user = dovecot
> default_vsz_limit = 512 M
> disable_plaintext_auth = no
> first_valid_gid = 89
> first_valid_uid = 89
> last_valid_gid = 89
> last_valid_uid = 89
> log_path = /dev/stderr
> login_greeting = Ready.
> login_trusted_networks = 172.16.100.0/24
> mail_fsync = never
> mail_plugins = " quota zlib stats"
> mail_privileged_group = mail
> namespace compat {
>   alias_for =
>   hidden = yes
>   inbox = no
>   list = no
>   location =
>   prefix = INBOX.
>   separator = .
> }
> namespace inbox {
>   inbox = yes
>   location =
>   prefix =
>   separator = .
> }
> passdb {
>   args = /usr/local/etc/dovecot/dovecot-master-sql.conf
>   driver = sql
>   master = yes
>   pass = yes
> }
> passdb {
>   args = /usr/local/etc/dovecot/dovecot-sql.conf
>   driver = sql
> }
> plugin {
>   quota = maildir
>   quota_rule = Trash:storage=+10%%
>   stats_refresh = 30 secs
>   stats_track_cmds = yes
> }
> protocols = imap pop3
> service anvil {
>   client_limit = 3175
> }
> service auth {
>   client_limit = 3684
>   unix_listener auth-master {
>     mode = 0600
>   }
> }
> service imap-login {
>   process_limit = 1536
>   process_min_avail = 25
>   service_count = 1
> }
> service imap-postlogin {
>   executable = script-login rawlog /usr/local/etc/dovecot/lastauth-imap.sh
>   user = vpopmail
> }
> service imap {
>   executable = /usr/local/libexec/dovecot/imap imap-postlogin
>   process_limit = 1536
> }
> service pop-postlogin {
>   executable = script-login /usr/local/etc/dovecot/lastauth-pop.sh
>   user = vpopmail
> }
> service pop3-login {
>   process_limit = 1536
>   process_min_avail = 15
>   service_count = 1
> }
> service pop3 {
>   executable = /usr/local/libexec/dovecot/pop3 pop-postlogin
> }
> service stats {
>   fifo_listener stats-mail {
>     mode = 0600
>     user = vpopmail
>   }
> }
> shutdown_clients = no
> ssl_cert = </etc/ssl/mail.pem
> ssl_key = </etc/ssl/mail.key
> ssl_key_password = na
> userdb {
>   driver = prefetch
> }
> verbose_proctitle = yes
> protocol imap {
>   imap_client_workarounds = delay-newmail tb-extra-mailbox-sep
>   mail_max_userip_connections = 100
>   mail_plugins = " quota zlib stats imap_zlib quota imap_quota"
> }
> protocol pop3 {
>   mail_max_userip_connections = 100
>   mail_plugins = quota
>   pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
>   pop3_uidl_format = %08Xu%08Xv
> }