Tag Archive: linux

I have always regarded forums as a way for 1 persons experience to save the struggle for another. When I started this blog, I set out to offer my own experiences and fixes to help others that may experience the same. So I hope this reaches someone out there and is useful for them.

Last week my IT team spent several hours attempting to resolve an issue where 1 of our MX servers would return 0 new messages when, clearly there were over 60,000 new email between /home/vmail/%mailbox%/MailDir/cur and new. Now, we have a complex mail setup that pulls email from dovecot mailbox and inserts the email into a database for the the application. There are several layers involved, so troubleshooting a system like that can take several hours, going through each layer to determine if the program that picks up the mail was faulty or the dovecot server itself.

Below are the steps i took to troubleshoot the issue.

  • Log into the MX server and run [ # tail -f /var/log/dovecot.log]
  • open email client or start email client program to fetch new mail
  • watch dovecot logs to determine if another program is picking up the mail prior to our mail program is able to fetch the new mail.
  • Rule out another process picking up the mail.
  • watch /home/vmail/%mailbox%/MailDir/new for new incoming mail.
  • once mail is in new queue, run mail client to fetch new mail.
  • At this point i noticed mail being moved from “new” to “cur” while the mail client still reported no new mail to pick up
  • Next I looked at the mail client to see when the last new message was picked up. I made not of the date stamp on the last mail message that was picked up.
  • I then went back to the dovecot MX server and ran [ # ls-l /home/vmail/%mailbox%/MailDir/ ]
  • this returns a few directories and a few key files that are the focus of this blog post. Dovecot.index, dovecot.index.cache, and dovecot.index.log. These files are what dovecot uses to make loading of mail in the mailbox faster. They are an index of the transactions on that particular mailbox. What i noticed was that the dovecot.index file, had the same timestamp as the timestamp of the last successful email that was received by the client. Even though new mail was obviously coming in, the dovecot index was not updating.
  • I then, renamed all three files to dovecot.index.old, dovecot.index.cache.old, and dovecot.index.log.old.
  • I proceeded to restart the dovecot service by running [ # services dovecot restart]
  • Verified that dovecot.index, dovecot.index.cache, and dovecot.index.log were rebuilt after the service restarted
  • then I restarted my mail client and fetched new mail.
  • BAM! 60,000 new messages now are seen and fetched.

I hope this finds usefulness to anyone out there having the same issue. Feel free to leave your comments or questions anytime!. Good Luck!.

 Hello all it has been a while since I posted anything. It is sometimes hard for me to come up with subjects to talk about, but alas! i have found some information that may be useful. In my quest for new gadgets and electronics, i have recently purchased a Raspberry PI. One thing that i purchased along with it was an Edimax Wireless adapter. Now connecting to a network using WIFI in linux is not as simple as a wired connection. Once plugging in the adapter, you should ensure that your drivers are up to date for your wireless card. This can affect how you are able to connect to your wireless network.

      Now not everyone keeps there home network wide open without security. If you do, please reconsider changing your router settings to use WEP / TKIP for securing your network. Once you are setup with your router with the security strength you desire. open a terminal session to your Linux server and type 

     $ iwlist wlan0 scan

This will scan for wireless networks using your wirless card. If you are unsure of the name of your wireless card you can type:

     $ ifconfig

This should output a list of your adapters including wired connections, and output their current connection state. Once you have received your available wireless networks you can now connect to your wireless network using the SSID that you get from iwlist output and the PSK or pre-shared key that you get from your wireless network router. If you are using a Debian flavor of Linux, you can edit your /etc/network/interfaces file and add the following settings​

​   auto wlan0

  iface wlan0 inet dhcp

  wpa-ssid “NAME OF YOUR WIFI”

  wpa-psk “YOUR PSK”​​

  #wpa-proto WPA — optional setting if needed your can uncomment this

  #wpa-pairwise TKIP — optional setting if needed your can uncomment this

  #wpa-group TKIP — optional setting if needed your can uncomment this

  #wpa-key-mgmt WPA-PSK — optional setting if needed your can uncomment this

The commented lines can be used to set the protocol for which your linux box will connect to your wireless network. In short this would be the settings of the type of encryption used to connect to your wireless network. I have found though that the first 4 lines are the basic essentials needed to connect to your wireless network, and work the majority of the time.

I hope this post helps you with setting up your wireless card. If you have questions or comments, feel free to let me know. Also feel free to check out my new blog at 


So approx. 1 week ago i get questions as to why a clients upload is getting cut off when they are uploading a file to our FTP server. Being that it was only 1 client out of the hundred or so we have using our FTP server, I figured there was something wrong on their end or with the routing. I tried to login myself, uploaded files, moved around, did a little dance, voila everything works fine without issue. Well not so fast, customers continue to have issues and I can’t seem to make sense of it. A couple days after that I get another request to look into why a very frustrated customer is uploading a PDF that is being corrupted. Ok so now something has got to be going on. I check the FTP server, uploads work fine without corruption. I check the server that actually host the clients files, no errors reported. Finally my hair recedes another inch and I continue to look.

So to give a 10,000 foot view of the layout, we have 1 Linux VSFTP server which might I add, rocks!.  Attached via CIFS mount is a windows file server that just does what it’s name is, it serves up files. So I being that this is not my first day at the rodeo (” I have done this before”), I have been fairly confident about this setup. The VSFTP server provides the data link essentially to the file server and all is well. Well after looking and looking some more, I began to run a command in Linux some of you might know as Tail.  In running  ” tail -f /var/log/syslog” I started to see errors pop

And as you can see the CIFS VFS: Write2 ret -13, and I think oh! of course this is as clear as mud!.

All joking aside , I looked for several hours to find some kind of solution for this. Nothing shows online, but 1 thing I did determine was that my Linux release even though it was up to date, it was 2 versions behind. With CIFS errors coming from the Kernel, I decided that ultimately the Kernel will need to be recompiled at the very least to fix the issue with VFS. Or I can just update the entire OS to the latest release and be done with this.

On average every 15 minutes our FTP server is being connected to. Not extremely busy but, also does not give me a window large enough to do a full update. So I decided that I would go with an alternate idea that would minimize downtime to about 10 minutes. Drawbacks? I would be spending the next week building 2 Linux servers with VSFTPD and selecting the best Linux OS to support it. I thought, “This can’t be that hard”.  Sorely mistaken I dove into the task and was suddenly met with problems from the new and improved VSFTPD.

One of the newer features I believe that comes with version 2.5.3 and up is the chroot_users does not allow the root folder to be written to.  This I knew was a problem because of how we have our FTP set up, we need to allow users to write to their root. Knowing that the users root is technically not on the FTP server, I can see no harm in allowing this.

Well none the less the issue remains,  however with the new 3.0 version, you can set a config called allow_writeable_chroot. This will solve the issue for you. Only thing you need to do is to compile the 3.o version yourself till all the Linux versions inherit it. After all said and done, moving to Centos with a self compiled VSFTPD version fixed our problem.

One issue I ran into on one of my Ubuntu servers was that each time i put my nameserver into the /etc/resolv.conf it was being reset back to a blank page after a reboot. Well there is tons of information out there about if your using DHCP then you need to go into the dhcp config files and setup the nameserver in there. One problem, I was not using the DHCP. Most of us running Linux on a server use the static IP option so this nullifies the instruction sets Iwas finding on the net.

So here I thought I would pass along this quick little summary. The best way for you to get around this is to hard code you nameserver’s into your interface file for your ethernet card like below. For Ubuntu you can find this by going to /etc/network/interfaces and edit this file with nano or VIM or whichever you like.

As you can see on the last line using dns-nameservers with an ip is the same as using nameservers in your resolv.conf file. You can also add multiple ip’s by separating them with a space. If you have any questions or comments, feel free to drop me a line.

%d bloggers like this: