XenServer's VM density testing uncovered a regression when moving from
sysvinit to systemd where the file descriptor limit dropped from 4096 to
1024. (XenServer had previously inserted a ulimit statement into its
initscripts.)
One solution is to use LimitNOFILE=4096 in xenconsoled.service to match the
lost ulimit, but that is only a stopgap solution.
As Xenconsoled genuinely needs a large number of file descriptors if a large
number of domains are running, attempt to increase the limit.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Grant references for the xenstore and xenconsole shared pages exist, but
currently only xenstore uses these references. Change the xenconsole
daemon to prefer using the grant reference over map_foreign_range when
mapping the shared console ring.
This allows xenconsoled to be run in a domain other than dom0 if set up
correctly - for libxl, the xenstore path /tool/xenconsoled/domid
specifies the domain containing xenconsoled.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
LOG_WARNING (or precisely LOG_DEBUG if -v) would be logged.
xenconsoled only actually logs using LOG_ERR and LOG_DEBUG so for the
most part we would have been logging absolutely nothing up until now.
Linux provides a LOG_UPTO macro but I'm not sure how portable that is
so I have opencoded the list of levels.
Do I get some sort of prize for fixing a bug introduced in 2005?
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
than discard characters in the console daemon buffers.
New option: -o, --overflow-data=discard|keep
This option changes the behaviour when dealing with data that overflow
the max capacity of the buffer. If overflow-data is set to discard
(the default), the current behaviour is used: we discard some data in
the middle of the buffer.
If overflow-data is set to keep, we stop listening to the ring until
we free some space in the buffer. This can cause the ring to fill up
and the guest kernel internal buffer to fill up as well. When this
happens the guest kernel stops reading characters from the console
device so the application generating data hangs. When xenconsoled
resumes reading from the ring, the guest kernel will be able to resume
reading from the console device as well. At that point the guest
application will be allowed to continue.
The risk of making this behaviour the default is that existing kernel
drivers may assume they can rely on timely ring updates by the console
daemon and thus themselves block on the ring being emptied.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
* The --log command line argument takes one of 4 values
- none - no logging (the default)
- hv - log all hypervisor messages
- guest - log all guest messages
- both - log all guest & hypervisor messages
* The --log-dir command line argument takes a path to specify where
to store logfiles. If omitted it defaults to /var/log/xen/console
* The hypervisor logfile is $LOGDIR/hypervisor.log
* The guest logfile is $LOGDIR/guest-[NAME].log
* If receiving a SIGHUP it will close & re-open all log files to
enable logrotate to do its magic
* Fixes the permissions of /var/run/xenconsoled.pid
* Adds a --pid-file command line argument to override the default
location of pid file (this is not really related to logging, but
since I was in that code...)
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Andrew Cooper
Daniel De Graaf
Stefano Stabellini
Keir Fraser
kfraser@localhost.localdomain
kaf24@firebug.cl.cam.ac.uk
vh249@arcadians.cl.cam.ac.uk
cl349@firebug.cl.cam.ac.uk