/etc/postfix/virtual empty after adding new server

4 posts / 0 new
Topic locked
Last post
#1 Wed, 06/29/2016 - 08:00
infomex

/etc/postfix/virtual empty after adding new server

I lost internet connection while I was creating new virtual server. Last message I got was about creating mail accounts. After reconnecting I had only username and group created in /etc/passwd, and empty /etc/posfix/virtual.

Any idea how to recreate this file? When I look at accounts via interface all is ok, but if I try to verify servers I get
Mail for domain : The mail server is not configured to receive email for example.com
where example.com is any domain except last one added (one with crash)

Wed, 06/29/2016 - 09:47
andreychek

Howdy,

Hmm, that's definitely a problem! What you may need to do is disable the "Mail for Domain" feature for all your domains, and then re-enable it.

That will cause the entries in that file to all be rewritten.

If you have a lot of domains, you could also do it via the command line interface, which would be faster.

-Eric

Thu, 06/30/2016 - 03:14
infomex

Re-adding the feature made even bigger mess (virtuals got recreated, but aliases and redirects got messed up). Problem got resolved by
virtualmin restore-domain --source /backups/FULL-28_06_2016 --all-domains --feature mail
and 12 hours of happy phone calls from friendly and understanding people.
I often work via mobile, so my connection is not the most stable. It happened before to me but usually accounts were partially created or apache files got messed up, and fixing those was not a problem, but if there is no way to rollback changes after crashed connection, then it's console and tmux for me only....
Is there a way to ensure atomicity of operations that could crash whole server? Can any user disable my hosting server just by adding lots of aliases and pulling the plug while process is in progress?

Mon, 07/25/2016 - 07:34
infomex

Problem was with using quota on Centos 7 with xfs quota_report process. Due to using this machine as production server i just transfered user files to ext4 - that resolved problem for now.

After some testing - yes - any user could crash server if:

  • There was heavy iowait que (usually by stalled xfs quota report process) - lots of lines like that in ps sh -c (xfs_quota -xc 'report -g -b -i -n' /home 2>&1)
  • many changes resulting in service reload were done at once... than you have Jul 12 14:10:37 hpro kernel: ------------[ cut here ]------------
    Jul 12 14:10:37 hpro kernel: WARNING: at lib/list_debug.c:36 __list_add+0x8a/0xc0()
    Jul 12 14:10:37 hpro kernel: list_add double add: new=ffff8802fd89cb18, prev=ffff8802fd89cb18, next=ffff8800368fe670.
    Jul 12 14:10:37 hpro kernel: Modules linked in: ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat iptable_mangle iptable_security iptable_raw iptable_filter vmw_vsock_vmci_transport vsock coretemp crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd ppdev vmw_balloon pcspkr sg vmw_vmci parport_pc parport i2c_piix4 shpchp ip_tables xfs libcrc32c sr_mod sd_mod cdrom crc_t10dif crct10dif_generic ata_generic pata_acpi vmwgfx crct10dif_pclmul crct10dif_common crc32c_intel drm_kms_helper ttm ata_piix serio_raw drm libata mptspi
    Jul 12 14:10:37 hpro kernel: scsi_transport_spi vmxnet3 mptscsih i2c_core mptbase floppy dm_mirror dm_region_hash dm_log dm_mod nf_conntrack_ftp nf_conntrack
    Jul 12 14:10:37 hpro kernel: CPU: 0 PID: 10019 Comm: xfs_quota Tainted: G        W      ------------   3.10.0-327.22.2.el7.x86_64 #1
    Jul 12 14:10:37 hpro kernel: Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/14/2014
    Jul 12 14:10:37 hpro kernel: ffff880185af3d10 00000000674f9954 ffff880185af3cc8 ffffffff816360fc
    Jul 12 14:10:37 hpro kernel: ffff880185af3d00 ffffffff8107b200 ffff8802fd89cb18 ffff8800368fe670
    Jul 12 14:10:37 hpro kernel: ffff8802fd89cb18 00000000fffffffe ffffffffffffffff ffff880185af3d68
    Jul 12 14:10:37 hpro kernel: Call Trace:
    Jul 12 14:10:37 hpro kernel: [<ffffffff816360fc>] dump_stack+0x19/0x1b
    Jul 12 14:10:37 hpro kernel: [<ffffffff8107b200>] warn_slowpath_common+0x70/0xb0
    Jul 12 14:10:37 hpro kernel: [<ffffffff8107b29c>] warn_slowpath_fmt+0x5c/0x80
    Jul 12 14:10:37 hpro kernel: [<ffffffffa02a66c8>] ? xfs_qm_dqget+0x338/0x440 [xfs]
    Jul 12 14:10:37 hpro kernel: [<ffffffff8130cafa>] __list_add+0x8a/0xc0
    Jul 12 14:10:37 hpro kernel: [<ffffffffa02a68b4>] xfs_qm_dqput+0xe4/0x110 [xfs]
    Jul 12 14:10:37 hpro kernel: [<ffffffffa02a9b8d>] xfs_qm_scall_getquota+0x21d/0x3a0 [xfs]
    Jul 12 14:10:37 hpro kernel: [<ffffffffa02ad566>] xfs_fs_get_dqblk+0x66/0x80 [xfs]
    Jul 12 14:10:37 hpro kernel: [<ffffffff81246225>] quota_getxquota+0x95/0x120
    Jul 12 14:10:37 hpro kernel: [<ffffffff811fed6e>] ? mntput_no_expire+0x3e/0x120
    Jul 12 14:10:37 hpro kernel: [<ffffffff811fee74>] ? mntput+0x24/0x40
    Jul 12 14:10:37 hpro kernel: [<ffffffff811e8d6e>] ? path_put+0x1e/0x30
    Jul 12 14:10:37 hpro kernel: [<ffffffff81285e38>] ? security_capable+0x18/0x20
    Jul 12 14:10:37 hpro kernel: [<ffffffff8124698c>] SyS_quotactl+0x42c/0x790
    Jul 12 14:10:37 hpro kernel: [<ffffffff81646889>] system_call_fastpath+0x16/0x1b
    Jul 12 14:10:37 hpro kernel: ---[ end trace 43b93d432ef3c445 ]---     In syslog, and reboot... and no /etc after that reboot....

may be due to some VMware quirks, but ext4 resolved it all....

also... there is no problem with using xfs as long as quota is disabled. Any additional ideas are welcome... if i have some time i'll clone this sytem and try to really debug the issue....

Topic locked