Error daemon not started

Troubleshooting

Then restart the daemon
# /usr/lib/errdemon

2) The error daemon fails to start due to a corrupt error log file.
In such a case you will need to force the error daemon to create a new errlog file, by stopping the daemon, removing the corrupt log, and restarting the daemon.

To stop logging run the below command
# /usr/lib/errstop
To get rid of that log.
# mv /var/adm/ras/errlog /var/adm/ras/errlog.back
To restart the daemon, thus creating a new error log
# /usr/lib/errdemon

3) When starting the error daemon it gives an error that the daemon already running while it is not.

a) If this issue happens on a Global LPAR then the only solution would be to reboot the server.

b) If this issue occurs in a WPAR you will need to rename the errlog file then stop and start the WPAR from the Global LPAR.

Источник

permission denied | Error response from daemon: Cannot start container #18967

Description of problem:
I can’t start any containers with the command docker run [. ], even really simple one like:
# docker run busybox

Produce the following output:
permission denied Error response from daemon: Cannot start container beb4524b4f8a372d5eacdf6111d17053df0099d51f0824677fd137a97d277965: [8] System error: permission denied

uname -a :
Linux J3XYZ 4.2.5-1-ARCH #1 SMP PREEMPT Tue Oct 27 08:13:28 CET 2015 x86_64 GNU/Linux

Environment details (AWS, VirtualBox, physical, etc.):
Lenovo X250

How reproducible:
docker run xyz

Steps to Reproduce:

1. sudo yaourt docker (->community/docker)
2. systemctl start docker
3. sudo docker run busybox

Expected Results:
A running container, obviously 🙂

Additional info:
Arch, btrfs, luks filesystem

The text was updated successfully, but these errors were encountered:

The same here. Only the underlying hardware is different. I also run Arch Linux, BTRFS on USB-HDDs.

Maybe this helps. I started docker daemon manually.

Here’s the output.

Besides that I tried docker version 1.8.2, 1.8.3 — the output is similar for those versions. Even switching to linux 3.19.3, linux 4.1.3, and linux 4.3.3 did not make a difference. I tried docker version 1.8.3 with each kernel version. The error stays the same. Not sure what causes this error. I even deleted /var/lib/docker along with all subvolumes created earlier. Is there any other debug option?

After switching the storage driver to -s devicemapper the container started. So using -s devicemapper seems to be a working workaround.

How can @Brandl and I help to find the underlying problem?

Sorry @thaJeztah to involve you directly, but that error was driving me crazy and your support was quite helpful/you were friendly the last time I got in touch with you. Now I have a workaround using the devicemapper storage driver, but that does not really look like a solution for people using docker in production. Can you help us getting in touch with somebody who has the time/knowledge to dig deeper?

I think @vbatts runs on btrfs, perhaps he has some suggestions here

@maxmeyer for the sake of information, can you paste the output from running https://github.com/docker/docker/blob/master/contrib/check-config.sh ?
I’m not precisely sure where this EPERM or ‘invalid argument’ is bubbling up from

I believe I am seeing the same issue.
Arch linux. btrfs all the way down.

It seems we are all running arch linux on btrfs with 4.x kernels.
Can anyone confirm the absence or presence of this issue on any of those variables in isolation?
ie kernel 4.x, btrfs filesystems, or arch linux?

I just ran with

and it seems to be working. Thanks @maxmeyer . That’s good enough for me right now.
I am still interested in helping or at least learning more about this issue however.

Same configuration, same issue and same solution here. If you need more information, just ask.

I’m getting the same issue on Fedora 23. I’m kernel 4.x but not arch or btrfs

The command
docker daemon -D -s devicemapper
solves the issue but I see it more as a temporary workaround than a fix

@14rcole your regular graph driver is also btrfs? Or device mapper? I don’t see where the «workaround» is in your command; if you’re running device mapper, than -s devicemapper is the right option to start the daemon with?

I’m trying to use docker on CentOS 7 and get the same question. It seems I have to disable seLinux in host os. Can I do something else to let my docker work without disable my seLinux?

Getting the same issue with btrfs, Arch Linux, and kernel 4.6.2-1-ARCH.

EDIT: the workaround isn’t working for me, it’s giving the following error:

I’m having this same issue in Fedora 24 (RUN apt-get update -y — Permission denied). Following @14rcole’s suggestion to run the daemon with allows it to work for now:

Docker started working for me a few days ago again. Not sure what I did to fix it. I re-installed it a few times and wiped /var/lib/docker , and it appears to have resolved itself.

try close SELinux by:
setenforce 0

The same to me,i fixed it by the common:

ls -aZ /usr/bin/docker*

-rwxr-xr-x. root root system_u:object_r:docker_exec_t:s0 /usr/bin/docker
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/docker-current
-rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/docker-storage-setup

sudo chcon -t docker_exec_t /usr/bin/docker*

sudo systemctl restart docker

@aker’s chcon -t docker_exec_t /usr/bin/docker* fixed it for my VM which was cloned from another one. Maybe that’s why this type was gone.

I’m not using btrfs. It’s likely some people in this issue simply have SELinux problems. But disabling it is a very bad option, because you’ll loose it’s security enhancements.

Before that I also tried running the docker daemon from outside the docker systemd unit which made it work prior to the SELinux fix. Got this from the likely very related issue #17475 here. But since this wasn’t a permant fix, I’m very happy to have found @aker’s fix. May I ask where you got this from? Especially since you’re saying it’s common.

@aCandidMind How did you install docker?

The docker RPM’s include an selinux policy that does exactly what you have done with the chcon . This should not be an issue with the official packages.

I see all these problems seem related to packaging with arch, which is non-official. This is not something that can be fixed here.

Docker supplies a policy here: https://github.com/docker/docker/tree/master/contrib/selinux/docker-engine-selinux
This is packaged as docker-engine-selinux on our yum repos for each supported platform.

Specifically with changes in 1.11, it was required to set docker_exec_t on /usr/bin/dockerd which was a new binary introduced by splitting the docker client ( docker ) and the docker daemon ( dockerd ).

Going to go ahead and close as this is not an issue that we can deal with here, but feel free to discuss.
Thanks all! 👼

Sorry for responding so late @cpuguy83.

I installed docker on my CentOS VM via yum install docker-engine*-1.9.1* from yum.dockerproject.org. yum list installed docker* yields:

So the 1.11 split of binaries wasn’t the cause in my case.

As I said above, I guess some people in this issue here had problems with the systemd/SELinux co-operation with docker rather than Arch or btrfs problems (because they said they’re not using Arch) which makes this issue have two groups of setups. On the one hand Arch and/or btrfs and on the other hand systemd and/or SELinux not using Arch or btrfs (including me). See that @14rcole’s comment and @sevagh’s comment mention that they are using Fedora and not Arch. And you could read into their comments that running the daemon on their own without systemd resolved their problems. Same as the related issue #17475 I mentioned above. Another CentOS user pointing in the SELinux direction can be found in our current thread here. My cloned CentOS VM (cloned from an existing VirtualBox CentOS VM, maybe that caused my SELinux problem) is also not Arch.

Also note that I did the chcon only once and since then the issue is resolved for me. But I’m still interested why @aker referred to it as a common thing to do.

Just putting this here for completeness for the next user that runs into that error response.

@aCandidMind I really can’t speak for the 1.9 policies, it is very likely those policies failed to load and the rpm installation itself would not fail itself and only give a warning since the base packages, selinux-policy , have changed so much and centos is a rolling release.

Источник

TheCodeBuzz

Best Practices for Software Development

Resolved -The Docker daemon is not running

Docker error – the docker daemon is not running

Today in this article, we will see resolution steps for errors like the docker daemon is not running .

Issue Description

Docker daemon fails to start up on Windows or stops for some reason and when you try to run any commands:

error during connect: Get http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.30/info: open //./pipe/docker_engine: The system cannot find the file specified. In the default daemon configuration on Windows,
the docker client must be run elevated to connect. This error may also indicate that the docker daemon is not running.

if you see any of the below errors while running,

Today we will cover the below resolution as a possible fix to the issue,

Resolution 1: Restart Docker service

This error meant the docker daemon is unreachable. Docker daemon fails to start up on Windows or stops for some reason and especially when you try to run any commands.

To fix such types of issues restarting the service will resolve the error. If not please check the resolution steps 2 as explained below.

From Start ->Search ->Please type in below,

This will open the Services Windows GUI. Please restart the Docker Desktop Service” by right click ->restart option. Please make sure the services are in the “Running” state.

Other options for Restart -Docker services

Alternatively one can use the below command to stop and restart the service from any CLI.

The service name can be retrieved from the service GUI.

Please check and validate if the docker is working fine. If not please use a few other options as mentioned below.

Resolution 2: DockerCli.exe -SwitchDaemon configuration

It could be possible that your Docker CLI is not properly configured for Windows or Linux.

Please use the below commands to point the Docker CLI to either Linux containers or Windows containers.

From Power Shell:

Please check and validate if the docker is working fine. If not please use a few other options as mentioned below.

Resolution 3 – Restart the docker service using GUI

Using Docker Desktop GUI from Settings -> Reset – Restart Docker Desktop.

Once started successfully you shall see a green running icon as below,

Please check and validate if the docker is working fine. If not please use a few other options as mentioned below.

Resolution 4 – Firewall settings

Please check your security software if it is blocking the docker to create a network interface. You should also check firewall software to not block any installation or configuration.

Resolution 5 – Restart

RESTART machine – Universal solution and if it doesn’t work out please raise a help ticket with Docker.

That’s all! Happy coding!

Does this help you fix your issue?

Do you have any better solutions or suggestions? Please sound off your comments below.

References:

Please bookmark this page and share it with your friends. Please Subscribe to the blog to get a notification on freshly published best practices and guidelines for software design and development.

Источник

Дистрибутив ALT Linux. Версия клиента yandex-disk-indicator 1.9.6. Версия yandex-disk 0.1.5.948.

yandex-disk-indicator -l10
2017-02-16 15:42:47,238 INFO     yandex-disk-indicator v.1.9.6
2017-02-16 15:42:47,239 DEBUG    Logging level: 10
2017-02-16 15:42:47,243 DEBUG    Config value read as: theme = False
2017-02-16 15:42:47,243 DEBUG    Config value read as: fmextensions = True
2017-02-16 15:42:47,244 DEBUG    Config value read as: autostart = True
2017-02-16 15:42:47,244 DEBUG    Config value read as: daemons = ~/.config/yandex-disk/config.cfg
2017-02-16 15:42:47,244 DEBUG    Config value read as: notifications = True
2017-02-16 15:42:47,244 INFO     Config read: /home/anton/.config/yd-tools/yandex-disk-indicator.conf
2017-02-16 15:42:47,427 DEBUG    Config value read as: proxy = False
2017-02-16 15:42:47,428 DEBUG    Config value read as: dir = /home/anton/Yandex.Disk
2017-02-16 15:42:47,428 DEBUG    Config value read as: auth = /home/anton/.config/yandex-disk/passwd
2017-02-16 15:42:47,428 DEBUG    Config value read as: stoponexitfromindicator = True
2017-02-16 15:42:47,429 DEBUG    Config value read as: startonstartofindicator = True
2017-02-16 15:42:47,429 INFO     Config read: /home/anton/.config/yandex-disk/config.cfg
2017-02-16 15:42:49,219 INFO     Start success, message: Запуск демона...Готово

2017-02-16 15:42:49,266 INFO     Change event: {init}
2017-02-16 15:42:49,276 DEBUG    Sub-menu 'Last synchronized' has been updated
2017-02-16 15:42:49,277 INFO     Status: none -> paused
2017-02-16 15:42:49,598 DEBUG    Event raised byTimer 
2017-02-16 15:42:49,599 INFO     Change event: {stat}
2017-02-16 15:42:49,600 INFO     Status: paused -> none
2017-02-16 15:42:49,600 DEBUG    Message: Яндекс.Диск  | Сервис Яндекс.Диск остановлен

Получается не может получить статус? Статус считываться должен из ~/Yandex.Disk/.sync/status ?

cat ~/Yandex.Disk/.sync/status
24203

При этом:

yandex-disk status
Статус ядра синхронизации: ожидание команды
Путь к папке Яндекс.Диска: '/home/anton/Yandex.Disk'
	Всего: 10 GB
	Занято: 2.71 GB
	Свободно: 7.29 GB
	Максимальный размер файла: 10 GB
	Размер корзины: 0 B

Последние синхронизированные пути:
	файл: 'Запись экрана 2016-12-18 19:41:38.mp4'
	файл: 'Включаем управление яркостью.mp4'
	файл: 'Screencast_23.03.2015_08:41:30.webm'
	файл: 'Screencast_23.03.2015_08:34:16.webm'
	файл: 'Загрузки/Builder-icex/regular-builder-icex-20151002-x86_64.iso'
	файл: 'Загрузки/Builder-icex/regular-builder-icex-qtcreator-20151005-x86_64.iso'
	файл: 'Загрузки/EPIC_FLAG.rar'
	файл: 'trikStudio/trikStudio-p7-64.tar.gz'
	файл: 'Загрузки/FLProg_1_10_Linux64.tar.gz'
	файл: 'Загрузки/Nokia N900 RX-51 Gr.RUS_sw-20.2010.36.2.exe'

00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 0b)
	Subsystem: Samsung Electronics Co Ltd Haswell-ULT DRAM Controller [144d:c737]
	Flags: bus master, fast devsel, latency 0
	Capabilities: <access denied>
	Kernel driver in use: hsw_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 0b) (prog-if 00 [VGA controller])
	DeviceName:  Onboard IGD
	Subsystem: Samsung Electronics Co Ltd Haswell-ULT Integrated Graphics Controller [144d:c737]
	Flags: bus master, fast devsel, latency 0, IRQ 48
	Memory at f7400000 (64-bit, non-prefetchable) [size=4M]
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at f000 [size=64]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: i915
	Kernel modules: i915

00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio Controller [8086:0a0c] (rev 0b)
	Subsystem: Samsung Electronics Co Ltd Haswell-ULT HD Audio Controller [144d:c737]
	Flags: bus master, fast devsel, latency 0, IRQ 47
	Memory at f7904000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

00:16.0 Communication controller [0780]: Intel Corporation 8 Series HECI #0 [8086:9c3a] (rev 04)
	Subsystem: Samsung Electronics Co Ltd 8 Series HECI [144d:c737]
	Flags: bus master, fast devsel, latency 0, IRQ 45
	Memory at f790d000 (64-bit, non-prefetchable) [size=32]
	Capabilities: <access denied>
	Kernel driver in use: mei_me
	Kernel modules: mei_me

00:1b.0 Audio device [0403]: Intel Corporation 8 Series HD Audio Controller [8086:9c20] (rev 04)
	Subsystem: Samsung Electronics Co Ltd 8 Series HD Audio Controller [144d:c737]
	Flags: bus master, fast devsel, latency 0, IRQ 49
	Memory at f7900000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 1 [8086:9c10] (rev e4) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 40
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 00002000-00002fff [size=4K]
	Memory behind bridge: cf200000-cf3fffff [size=2M]
	Prefetchable memory behind bridge: 00000000cf400000-00000000cf5fffff [size=2M]
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 3 [8086:9c14] (rev e4) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 41
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: None
	Memory behind bridge: f7800000-f78fffff [size=1M]
	Prefetchable memory behind bridge: None
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1c.3 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 4 [8086:9c16] (rev e4) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 42
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: 0000e000-0000efff [size=4K]
	Memory behind bridge: None
	Prefetchable memory behind bridge: 00000000f2100000-00000000f21fffff [size=1M]
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1c.4 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 5 [8086:9c18] (rev e4) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 43
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: 0000d000-0000dfff [size=4K]
	Memory behind bridge: f6000000-f70fffff [size=17M]
	Prefetchable memory behind bridge: 00000000e0000000-00000000f1ffffff [size=288M]
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1d.0 USB controller [0c03]: Intel Corporation 8 Series USB EHCI #1 [8086:9c26] (rev 04) (prog-if 20 [EHCI])
	Subsystem: Samsung Electronics Co Ltd 8 Series USB EHCI [144d:c737]
	Flags: bus master, medium devsel, latency 0, IRQ 23
	Memory at f790b000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>
	Kernel driver in use: ehci-pci
	Kernel modules: ehci_pci

00:1f.0 ISA bridge [0601]: Intel Corporation 8 Series LPC Controller [8086:9c45] (rev 04)
	Subsystem: Samsung Electronics Co Ltd 8 Series LPC Controller [144d:c737]
	Flags: bus master, medium devsel, latency 0
	Capabilities: <access denied>
	Kernel driver in use: lpc_ich
	Kernel modules: lpc_ich

00:1f.2 SATA controller [0106]: Intel Corporation 8 Series SATA Controller 1 [AHCI mode] [8086:9c03] (rev 04) (prog-if 01 [AHCI 1.0])
	Subsystem: Samsung Electronics Co Ltd 8 Series SATA Controller 1 [AHCI mode] [144d:c737]
	Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 44
	I/O ports at f0b0 [size=8]
	I/O ports at f0a0 [size=4]
	I/O ports at f090 [size=8]
	I/O ports at f080 [size=4]
	I/O ports at f060 [size=32]
	Memory at f790a000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <access denied>
	Kernel driver in use: ahci
	Kernel modules: ahci

00:1f.3 SMBus [0c05]: Intel Corporation 8 Series SMBus Controller [8086:9c22] (rev 04)
	Subsystem: Samsung Electronics Co Ltd 8 Series SMBus Controller [144d:c737]
	Flags: medium devsel, IRQ 18
	Memory at f7909000 (64-bit, non-prefetchable) [size=256]
	I/O ports at f040 [size=32]
	Kernel driver in use: i801_smbus
	Kernel modules: i2c_i801

02:00.0 Network controller [0280]: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter [168c:0036] (rev 01)
	Subsystem: Samsung Electronics Co Ltd QCA9565 / AR9565 Wireless Network Adapter [144d:411c]
	Flags: bus master, fast devsel, latency 0, IRQ 18
	Memory at f7800000 (64-bit, non-prefetchable) [size=512K]
	Expansion ROM at f7880000 [disabled] [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: ath9k
	Kernel modules: ath9k

03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL810xE PCI Express Fast Ethernet controller [10ec:8136] (rev 05)
	Subsystem: Samsung Electronics Co Ltd RTL810xE PCI Express Fast Ethernet controller [144d:c737]
	Flags: bus master, fast devsel, latency 0, IRQ 19
	I/O ports at e000 [size=256]
	Memory at f2104000 (64-bit, prefetchable) [size=4K]
	Memory at f2100000 (64-bit, prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: r8169
	Kernel modules: r8169

04:00.0 3D controller [0302]: NVIDIA Corporation GF117M [GeForce 610M/710M/810M/820M / GT 620M/625M/630M/720M] [10de:1140] (rev a1)
	Subsystem: Samsung Electronics Co Ltd GeForce 710M [144d:c737]
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Memory at f0000000 (64-bit, prefetchable) [size=32M]
	I/O ports at d000 [size=128]
	Expansion ROM at f7000000 [disabled] [size=512K]
	Capabilities: <access denied>
	Kernel modules: nouveau, nvidia_drm, nvidia

UNIT                            LOAD   ACTIVE SUB     DESCRIPTION                
init.scope                      loaded active running System and Service Manager 
session-1.scope                 loaded active running Session 1 of user eren     
accounts-daemon.service         loaded active running Accounts Service           
bumblebeed.service              loaded active running Bumblebee C Daemon         
dbus.service                    loaded active running D-Bus System Message Bus   
getty@tty1.service              loaded active running Getty on tty1              
lvm2-lvmetad.service            loaded active running LVM2 metadata daemon       
NetworkManager.service          loaded active running Network Manager            
polkit.service                  loaded active running Authorization Manager      
rtkit-daemon.service            loaded active running RealtimeKit Scheduling Policy Service
systemd-journald.service        loaded active running Journal Service            
systemd-logind.service          loaded active running Login Service              
systemd-udevd.service           loaded active running udev Kernel Device Manager 
udisks2.service                 loaded active running Disk Manager               
upower.service                  loaded active running Daemon for power management
user@1000.service               loaded active running User Manager for UID 1000  
wpa_supplicant.service          loaded active running WPA supplicant             
dbus.socket                     loaded active running D-Bus System Message Bus Socket
lvm2-lvmetad.socket             loaded active running LVM2 metadata daemon socket
systemd-journald-audit.socket   loaded active running Journal Audit Socket       
systemd-journald-dev-log.socket loaded active running Journal Socket (/dev/log)  
systemd-journald.socket         loaded active running Journal Socket             
systemd-udevd-control.socket    loaded active running udev Control Socket        
systemd-udevd-kernel.socket     loaded active running udev Kernel Socket         

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

24 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

The daemon cannot be started

Symptom

The libvirt daemon cannot be started:

# /etc/init.d/libvirtd start
* Caching service dependencies ...                                                                                             [ ok ]
* Starting libvirtd ...
/usr/sbin/libvirtd: error: Unable to initialize network sockets. Check /var/log/messages or run without --daemon for more info.
* start-stop-daemon: failed to start `/usr/sbin/libvirtd'                                                                      [ !! ]
* ERROR: libvirtd failed to start

However, there is nothing in the /var/log/messages. Therefore we need to change libvirt logging:

/etc/libvirt/libvirtd.conf:

# You need to uncomment this line
log_outputs="3:syslog:libvirtd"

After that, we try to startup libvirt once again. This time we can see the problem:
/var/log/messages:

Feb  6 17:22:09 bart libvirtd: 17576: info : libvirt version: 0.9.9
Feb  6 17:22:09 bart libvirtd: 17576: error : virNetTLSContextCheckCertFile:92: Cannot read CA certificate '/etc/pki/CA/cacert.pem': No such file or directory
Feb  6 17:22:09 bart /etc/init.d/libvirtd[17573]: start-stop-daemon: failed to start `/usr/sbin/libvirtd'
Feb  6 17:22:09 bart /etc/init.d/libvirtd[17565]: ERROR: libvirtd failed to start

Investigation

In libvirtd manpage, we can find that missing file is used as TLS authority
when libvirt is run in ‘Listen for TCP/IP connections’ mode. In other words, the —listen parameter is being passed.

Solution

1. Install CA certificate
2. Don’t use TLS but bare TCP instead. In /etc/libvirt/libvirtd.conf set listen_tls = 0 and listen_tcp = 1.
3. Don’t pass —listen. In /etc/sysconfig/libvirtd change LIBVIRTD_ARGS variable.