Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1083100

Summary: vdsm depends on rsyslog
Product: Red Hat Enterprise Virtualization Manager Reporter: Anand Nande <anande>
Component: vdsmAssignee: Yaniv Bronhaim <ybronhei>
Status: CLOSED ERRATA QA Contact: Pavel Stehlik <pstehlik>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0.0CC: aberezin, anande, bazulay, danken, gklein, iheim, jentrena, lpeer, mschulze, oourfali, pdwyer, s.kieske, ybronhei, yeylon
Target Milestone: ---   
Target Release: 3.5.0   
Hardware: All   
OS: Linux   
Whiteboard: infra
Fixed In Version: vt1.3, 4.16.0-1.el6_5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-11 21:10:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1142923, 1156165    

Description Anand Nande 2014-04-01 13:29:05 UTC
Description of problem:

While performing a vdsm update manually on RHEL-Host,
rsyslog is the dependency any thing apart from this like "syslog-ng" 
cannot be used. 

# yum deplist vdsm > /tmp/dep

# grep rsyslog /tmp/dep
dependency: rsyslog
   provider: rsyslog.x86_64 4.6.2-2.el6
   provider: rsyslog.x86_64 4.6.2-3.el6
   provider: rsyslog.x86_64 4.6.2-3.el6_1.1
   provider: rsyslog.x86_64 4.6.2-3.el6_1.2
   provider: rsyslog.x86_64 4.6.2-3.el6_1.4
   provider: rsyslog.x86_64 4.6.2-12.el6
   provider: rsyslog.x86_64 5.8.10-2.el6
   provider: rsyslog.x86_64 5.8.10-6.el6
   provider: rsyslog.x86_64 5.8.10-7.el6_4
   provider: rsyslog.x86_64 5.8.10-8.el6

Version-Release number of selected component (if applicable): RHEV-3.3

How reproducible: always

Steps to Reproduce:
1. Put RHEL Hosts into maintenance mode and perform an update on it manually.
2. When syslog-ng is being used, rsyslog acts as an obstacle while updating vdsm.

Actual results: vdsm does not update.

Expected results: vdsm should not depend on rsyslog package to update.

Comment 1 Anand Nande 2014-04-01 13:30:05 UTC
# rpm -qR vdsm | grep syslog

Comment 3 Dan Kenigsberg 2014-04-09 09:57:37 UTC
See and bug 928861 on why we need syslog running.

If we want to support syslog-ng, we can have a more complex "soft" dependency, where vdsm checks on startup whether one of the two is available.

Anand, could you explain why syslog-ng is required?
What happens if you --force rpm limitations away? Does Vdsm works and logs properly?

Comment 4 Sven Kieske 2014-04-10 11:44:20 UTC
As requested on the users ML, here is my response why a hard dependency
should not be necessary:

a usecase for a different syslog is utilize existing log infrastructure which doesn't use
rsyslog, perhaps?
e.g. syslog-ng
furthermore: vdsms logging is configured via /etc/vdsm/logger.conf
and uses the python module logging:

this module is pretty cool, it allows you to redirect
your logging basically to wherever you like, including syslog services
or files, whatever.

so why restrict this builtin feature by adding a hard dependency
to a specific logging service?

I know it's done because it's built on red hat linux where rsyslog
is the default, and I don't want to say rsyslog is bad, it's just
not used by everybody.

As I understand there is work be done to port vdsm and engine
to different distros like debian/ubuntu and gentoo.

If you really want to port your software, keep it portable.
This means in the first place don't introduce dependencies
which aren't absolutely necessary.

This one isn't really necessary.
I can report to you that e.g. syslog-ng handles vdsm logs
well. ;)


We circumvented this dependency afaik by keeping rsyslog installed
but disabled the start of the service.
But my colleague could provide more details on the exact steps that where taken.

Comment 5 Sven Kieske 2014-04-10 11:51:21 UTC
I inspected
which is, according to you, the reason for the dependency.

But it is not, quoting from this BZ:
syslog listens on /dev/log socket and logger tries to open it, if syslog runs with corrupted configuration this socket won't be created. I propose a patch that check this file before starting vdsm process.

It's correct that "syslog" listens on this device, but
syslog doesn't need to be rsyslog.

So you could just check for /dev/log and not for a specific
syslog implementation.

You _can_ configure logger.conf to not use syslog (a.k.a. /dev/log)
at all, thus avoiding this complete dependency.

For the sake of portability this dep should get removed or softened.


Comment 7 Dan Kenigsberg 2014-04-10 14:14:00 UTC
I am not suggesting to use `rpm --force` on a production environment. I'm only soliciting for help in testing whether syslog-ng can somehow transparently replace syslogd, when it comes to Vdsm.

Comment 9 Yaniv Bronhaim 2014-04-13 10:41:51 UTC
Dan, we do check for /dev/log during start (, instead of having the requirement in the spec, we can specify in syslog_available output that user must install rsyslog\other alternative, to allow vdsm syslog reports before starting vdsmd up. is it acceptable and enough?

Comment 10 Dan Kenigsberg 2014-04-16 10:01:18 UTC
Sounds good to me.

Comment 11 Petr Be┼łas 2014-07-29 15:00:20 UTC
Verified in vdsm-4.16.1-0.gita4d9abf.el6.x86_64

Comment 12 Sven Kieske 2014-09-18 08:05:12 UTC
As this is a very minor change, is there any change to backport it to 3.4.z?

Comment 13 Dan Kenigsberg 2014-09-18 09:09:15 UTC
I don't mind backporting
Sven, please clone this bug to 3.4.4.

Comment 14 Sven Kieske 2014-09-18 09:26:02 UTC
Clone created at:

thanks for your effort Dan! It's much appreciated!

Comment 16 errata-xmlrpc 2015-02-11 21:10:36 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.