From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v2] tools/xenconsoled: Increase file descriptor limit Date: Tue, 17 Feb 2015 17:31:19 +0000 Message-ID: <54E37AE7.7080409@citrix.com> References: <1424190084-9922-1-git-send-email-andrew.cooper3@citrix.com> <20150217162831.GH2159@zion.uk.xensource.com> <54E36E34.1000307@citrix.com> <20150217164811.GI2159@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150217164811.GI2159@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Ian Jackson , Ian Campbell , Xen-devel List-Id: xen-devel@lists.xenproject.org On 17/02/15 16:48, Wei Liu wrote: > On Tue, Feb 17, 2015 at 04:37:08PM +0000, Andrew Cooper wrote: > >> I am not sure what an admin could usefully do with a logged failure >> message here. Xenconsoled will most likely not function in an >> environment where it is not sufficiently privileged to make this limit >> adjustment (use of privcmd and /dev/ptmx). >> > Does xenconsoled requires CAP_SYS_RESOURCE to make use of privcmd and > /dev/ptmx? If not, there is a case that your setrlimit fails > while other parts can still be functional, right? A slim chance, yes if someone has specifically been playing with capabilities. I still don't see how an error message would be useful. Even if the call fails, the process still has the default number of file descriptors and can function fine up until that limit. If errors were meaningful in this case, the function wouldn't be void. ~Andrew