<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Cloudlinux on Daniel Pomfret</title>
    <link>https://pomfret.uk/tags/cloudlinux/</link>
    <description>Recent content in Cloudlinux on Daniel Pomfret</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <copyright>© Daniel Pomfret</copyright>
    <lastBuildDate>Wed, 11 Apr 2018 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://pomfret.uk/tags/cloudlinux/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>CloudLinux LVE Manager displays no statistics (lveinfo)</title>
      <link>https://pomfret.uk/posts/cloudlinux-lve-manager-displays-no-statistics-lveinfo/</link>
      <pubDate>Wed, 11 Apr 2018 00:00:00 +0000</pubDate>
      <guid>https://pomfret.uk/posts/cloudlinux-lve-manager-displays-no-statistics-lveinfo/</guid>
      <description>&lt;p&gt;Another little fix for a issue I came across this week relating to CloudLinux&amp;rsquo;s LVEstats2&lt;/p&gt;&#xA;&lt;p&gt;I had a server running 100% CPU, and doing an huge amount of read/write I/O - causing issues with the SAN shelf. After looking at &lt;strong&gt;top&lt;/strong&gt;, I noticed the LVE process (which collects usage data on users) was consuming most of the CPU, and having a lot of read/write to the disk.&lt;/p&gt;&#xA;&lt;p&gt;After some investigation, and looking at the lve sqlite database (/var/lve/lvestats2.db) it was apparent that LVE wasn&amp;rsquo;t updating the database correctly, and we can assume the database was corrupted. So I could then assume that users were not being restricted, and being able to abuse all the resources available - enhancing the issue further.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
