1. 14 3月, 2020 1 次提交
  2. 20 2月, 2020 1 次提交
  3. 17 1月, 2020 1 次提交
  4. 20 12月, 2019 1 次提交
  5. 10 12月, 2019 1 次提交
  6. 15 11月, 2019 1 次提交
  7. 14 11月, 2019 3 次提交
  8. 12 11月, 2019 1 次提交
  9. 25 10月, 2019 1 次提交
  10. 16 10月, 2019 1 次提交
  11. 15 10月, 2019 1 次提交
  12. 27 8月, 2019 1 次提交
  13. 10 4月, 2019 2 次提交
  14. 07 8月, 2018 1 次提交
  15. 04 7月, 2018 1 次提交
    • B
      util:Fix with process number and pid file do not match · d6cfa0cd
      Bobo Du 提交于
      the libvirtd pid file is not match the os process pid number
      which is smaller than before.
      
      this would be exist if the libvirtd process coredump or the os
      process was killed which the next pid number is smaller.
      
      you can be also edit the pid file to write the longer number than
      before,then restart the libvirtd service.
      Signed-off-by: NBobo Du <dubo163@126.com>
      d6cfa0cd
  16. 10 6月, 2015 1 次提交
  17. 15 4月, 2015 1 次提交
  18. 04 11月, 2014 1 次提交
  19. 03 11月, 2014 1 次提交
  20. 15 9月, 2014 3 次提交
  21. 25 3月, 2014 1 次提交
  22. 18 3月, 2014 2 次提交
  23. 02 5月, 2013 1 次提交
    • M
      virutil: Move string related functions to virstring.c · 7c9a2d88
      Michal Privoznik 提交于
      The source code base needs to be adapted as well. Some files
      include virutil.h just for the string related functions (here,
      the include is substituted to match the new file), some include
      virutil.h without any need (here, the include is removed), and
      some require both.
      7c9a2d88
  24. 21 12月, 2012 4 次提交
  25. 01 11月, 2012 1 次提交
  26. 31 10月, 2012 1 次提交
    • L
      util: do a better job of matching up pids with their binaries · 7bafe009
      Laine Stump 提交于
      This patch resolves: https://bugzilla.redhat.com/show_bug.cgi?id=871201
      
      If libvirt is restarted after updating the dnsmasq or radvd packages,
      a subsequent "virsh net-destroy" will fail to kill the dnsmasq/radvd
      process.
      
      The problem is that when libvirtd restarts, it re-reads the dnsmasq
      and radvd pidfiles, then does a sanity check on each pid it finds,
      including checking that the symbolic link in /proc/$pid/exe actually
      points to the same file as the path used by libvirt to execute the
      binary in the first place. If this fails, libvirt assumes that the
      process is no longer alive.
      
      But if the original binary has been replaced, the link in /proc is set
      to "$binarypath (deleted)" (it literally has the string " (deleted)"
      appended to the link text stored in the filesystem), so even if a new
      binary exists in the same location, attempts to resolve the link will
      fail.
      
      In the end, not only is the old dnsmasq/radvd not terminated when the
      network is stopped, but a new dnsmasq can't be started when the
      network is later restarted (because the original process is still
      listening on the ports that the new process wants).
      
      The solution is, when the initial "use stat to check for identical
      inodes" check for identity between /proc/$pid/exe and $binpath fails,
      to check /proc/$pid/exe for a link ending with " (deleted)" and if so,
      truncate that part of the link and compare what's left with the
      original binarypath.
      
      A twist to this problem is that on systems with "merged" /sbin and
      /usr/sbin (i.e. /sbin is really just a symlink to /usr/sbin; Fedora
      17+ is an example of this), libvirt may have started the process using
      one path, but /proc/$pid/exe lists a different path (indeed, on F17
      this is the case - libvirtd uses /sbin/dnsmasq, but /proc/$pid/exe
      shows "/usr/sbin/dnsmasq"). The further bit of code to resolve this is
      to call virFileResolveAllLinks() on both the original binarypath and
      on the truncated link we read from /proc/$pid/exe, and compare the
      results.
      
      The resulting code still succeeds in all the same cases it did before,
      but also succeeds if the binary was deleted or replaced after it was
      started.
      7bafe009
  27. 12 10月, 2012 1 次提交
  28. 21 9月, 2012 1 次提交
  29. 23 7月, 2012 1 次提交
    • O
      Desert the FSF address in copyright · f9ce7dad
      Osier Yang 提交于
      Per the FSF address could be changed from time to time, and GNU
      recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html)
      
        You should have received a copy of the GNU General Public License
        along with Foobar.  If not, see <http://www.gnu.org/licenses/>.
      
      This patch removes the explicit FSF address, and uses above instead
      (of course, with inserting 'Lesser' before 'General').
      
      Except a bunch of files for security driver, all others are changed
      automatically, the copyright for securify files are not complete,
      that's why to do it manually:
      
        src/security/security_selinux.h
        src/security/security_driver.h
        src/security/security_selinux.c
        src/security/security_apparmor.h
        src/security/security_apparmor.c
        src/security/security_driver.c
      f9ce7dad
  30. 03 5月, 2012 2 次提交