Dell - Internal Use - Confidential
Hi All:
I am trying to test Resource Control of system by setting MemoryLimit on my
Debian system. Unfortunately it won't work after my testing. Maybe I am not
configuring right. Please let me know how to fix this.
Here is info for your reference:
1)
On Thu, Feb 18, 2016 at 4:44 AM, Ben Woodard wrote:
> Is it intentional that systemd holds a reference to a socket it has just
> accepted even though it just handed the open socket over to a
> socket.activated service that it has just started.
yes.
>
> For example given
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/17/2016 10:29 PM, NeilBrown wrote:
> On Thu, Feb 18 2016, Shaohua Li wrote:
>
>> On Wed, Feb 17, 2016 at 05:25:00PM +0100, Sebastian
>> Parschauer wrote:
>>> When stopping an MD device, then its device node /dev/mdX
>>> may still exist
Is it intentional that systemd holds a reference to a socket it has just
accepted even though it just handed the open socket over to a socket.activated
service that it has just started.
For example given the following unit files:
/etc/systemd/system/test.socket:
[Unit]
Description=test service
On Wed, Feb 17, 2016 at 09:17:51AM -0800, Kok, Auke-jan H wrote:
> On Wed, Feb 17, 2016 at 9:03 AM, Jóhann B. Guðmundsson
> wrote:
> > On 02/17/2016 04:51 PM, Daniel Mack wrote:
> >> [I've put all people in Cc who have had more than one commit related to
> >> systemd-bootchart
On Wed, Feb 17 2016, Sebastian Parschauer wrote:
> On 16.02.2016 21:43, NeilBrown wrote:
>> On Wed, Feb 17 2016, Shaohua Li wrote:
>>
>>> On Tue, Feb 16, 2016 at 03:44:36PM +0100, Sebastian Parschauer wrote:
When stopping an MD device, then its device node /dev/mdX may still
exist
On Thu, Feb 18, 2016 at 08:29:28AM +1100, Neil Brown wrote:
> On Thu, Feb 18 2016, Shaohua Li wrote:
>
> > On Wed, Feb 17, 2016 at 05:25:00PM +0100, Sebastian Parschauer wrote:
> >> When stopping an MD device, then its device node /dev/mdX may still
> >> exist afterwards or it is recreated by
On Thu, Feb 18 2016, Shaohua Li wrote:
> On Wed, Feb 17, 2016 at 05:25:00PM +0100, Sebastian Parschauer wrote:
>> When stopping an MD device, then its device node /dev/mdX may still
>> exist afterwards or it is recreated by udev. The next open() call
>> can lead to creation of an inoperable MD
On 17.2.2016 20:02, Umut Tezduyar Lindskog wrote:
Hi,
src/shared & src/basic have very useful code that upstream have been static
linking to most binaries. My understanding is that we haven’t been feeling
comfortable about the API to make these paths a standalone library (or include them
in
Hi,
src/shared & src/basic have very useful code that upstream have been static
linking to most binaries. My understanding is that we haven’t been feeling
comfortable about the API to make these paths a standalone library (or include
them in libsystemd).
Now that we started duplicating the
On 02/17/2016 07:17 PM, systemd-devel-requ...@lists.freedesktop.org wrote:
3. watchdog during startup
Sometimes we need to perform expensive operations during startup
(log replay, rebuild from network replica) before we can start
serving. Rather than configure a huge start timeout, I'd prefer
On 02/17/2016 03:56 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Feb 17, 2016 at 02:35:55PM +0200, Avi Kivity wrote:
We are using systemd to supervise our NoSQL database and are
generally happy.
A few things will help even more:
1. log core dumps immediately rather than after the dump
On Wed, Feb 17, 2016 at 05:25:00PM +0100, Sebastian Parschauer wrote:
> When stopping an MD device, then its device node /dev/mdX may still
> exist afterwards or it is recreated by udev. The next open() call
> can lead to creation of an inoperable MD device. The reason for
> this is that a change
Daniel Mack [2016-02-17 18:09 +0100]:
> Barely anyone of the people working on systemd uses that tool, so it
> sees little testing.
For the record, I have automatic integration tests for that to ensure
that it stays working in principle, i. e. it boots and produces an
.svg file. Of course the
On Wed, Feb 17, 2016 at 9:03 AM, Jóhann B. Guðmundsson
wrote:
> On 02/17/2016 04:51 PM, Daniel Mack wrote:
>> [I've put all people in Cc who have had more than one commit related to
>> systemd-bootchart in the past]
>>
>> As part of our spring cleaning, we've been thinking
Hello!
I have an annoying problem with systemd and tomcat under CentOS. I try to set a
parameter
via /etc/sysconfig/tomcat:
JAVA_OPTS="-DmyPATH=\"/path to my/file\""
JAVA_OPTS="-DmyPath=\"/path to my/file\""
It is read by systemd via /usr/lib/systemd/system/tomcat.service:
On 02/17/2016 06:03 PM, Jóhann B. Guðmundsson wrote:
>
>
> On 02/17/2016 04:51 PM, Daniel Mack wrote:
>> Hey,
>>
>> [I've put all people in Cc who have had more than one commit related to
>> systemd-bootchart in the past]
>>
>> As part of our spring cleaning, we've been thinking about giving
>>
On 02/17/2016 04:51 PM, Daniel Mack wrote:
Hey,
[I've put all people in Cc who have had more than one commit related to
systemd-bootchart in the past]
As part of our spring cleaning, we've been thinking about giving
systemd-bootchart a new home, in a new repository of its own. I've been
Hey,
[I've put all people in Cc who have had more than one commit related to
systemd-bootchart in the past]
As part of our spring cleaning, we've been thinking about giving
systemd-bootchart a new home, in a new repository of its own. I've been
working on this and put the result here:
When stopping an MD device, then its device node /dev/mdX may still
exist afterwards or it is recreated by udev. The next open() call
can lead to creation of an inoperable MD device. The reason for
this is that a change event (KOBJ_CHANGE) is sent to udev which
races against the remove event
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi, I'll add to this:
W dniu 17.02.2016 o 14:56, Zbigniew Jędrzejewski-Szmek pisze:
> On Wed, Feb 17, 2016 at 02:35:55PM +0200, Avi Kivity wrote:
>> We are using systemd to supervise our NoSQL database and are
>> generally happy.
>>
>> A few
On Wed, Feb 17, 2016 at 02:35:55PM +0200, Avi Kivity wrote:
> We are using systemd to supervise our NoSQL database and are
> generally happy.
>
> A few things will help even more:
>
> 1. log core dumps immediately rather than after the dump completes
>
> A database will often consume all memory
On 17.02.2016 14:06, Jes Sorensen wrote:
> Hannes Reinecke writes:
>> On 02/16/2016 09:46 PM, NeilBrown wrote:
>>> On Wed, Feb 17 2016, Jes Sorensen wrote:
I am totally fine with this, however we should make mdadm
fail if run against a pre-2.6.28 kernel then.
We are using systemd to supervise our NoSQL database and are generally
happy.
A few things will help even more:
1. log core dumps immediately rather than after the dump completes
A database will often consume all memory on the machine; dumping 120GB
can take a lot of time, especially if
On 16.02.2016 21:43, NeilBrown wrote:
> On Wed, Feb 17 2016, Shaohua Li wrote:
>
>> On Tue, Feb 16, 2016 at 03:44:36PM +0100, Sebastian Parschauer wrote:
>>> When stopping an MD device, then its device node /dev/mdX may still
>>> exist afterwards or it is recreated by udev. The next open() call
On 16.02.2016 23:02, Jes Sorensen wrote:
> NeilBrown writes:
>> On Wed, Feb 17 2016, Jes Sorensen wrote:
>>
>>> Hannes Reinecke writes:
On 02/16/2016 07:03 PM, Sebastian Parschauer wrote:
> The worst thing that can happen is that the kernel sends the change
26 matches
Mail list logo