Re: [systemd-devel] getty : how to run getty on every ttyX

On 12/14/2013 12:20 AM, Lennart Poettering wrote: > On Fri, 13.12.13 16:15, Lennart Poettering (lenn...@poettering.net) wrote: > >>> We had discussed this back at Linux Plumbers last year, and at the time >>> you had suggested that rather than create /dev/ttyN symlinks we should >>> instead do som

Re: [systemd-devel] getty : how to run getty on every ttyX

Hello Mantas, On 12/13/2013 04:17 PM, Mantas Mikulėnas wrote: > > On Dec 13, 2013 10:09 AM, "Gao feng" <mailto:gaof...@cn.fujitsu.com>> wrote: >> >> Hi, >> >> As we know, systemd only forks getty on ttyX when we press ctrl + alt + FX. >>

[systemd-devel] getty : how to run getty on every ttyX

Hi, As we know, systemd only forks getty on ttyX when we press ctrl + alt + FX. I whould like to let systemd forks server gettys on all of tty deivces by default. this is very useful in container environment, since we can't use ctrl+alt+FX to trigger getty in container. If there are some configu

Re: [systemd-devel] [PATCH v2 1/4] cgroup: add the setting memory.use_hierarchy support for systemd

On 09/25/2013 08:23 AM, Lennart Poettering wrote: > On Tue, 24.09.13 08:36, Gao feng (gaof...@cn.fujitsu.com) wrote: > >>>> Some programs need to set the memory.use_hierarchy(such as libvirt), >>>> Add this feature. >>> >>> As mentioned already:

Re: [systemd-devel] [PATCH v2 1/4] cgroup: add the setting memory.use_hierarchy support for systemd

On 09/24/2013 08:36 AM, Gao feng wrote: > On 09/24/2013 05:06 AM, Lennart Poettering wrote: >> On Mon, 23.09.13 14:30, Gao feng (gaof...@cn.fujitsu.com) wrote: >> >>> Some programs need to set the memory.use_hierarchy(such as libvirt), >>> Add this feature. >&g

Re: [systemd-devel] [PATCH v2 1/4] cgroup: add the setting memory.use_hierarchy support for systemd

On 09/24/2013 05:06 AM, Lennart Poettering wrote: > On Mon, 23.09.13 14:30, Gao feng (gaof...@cn.fujitsu.com) wrote: > >> Some programs need to set the memory.use_hierarchy(such as libvirt), >> Add this feature. > > As mentioned already: this really shouldn't be

[systemd-devel] [PATCH v2 4/4] man: add manpage for MemoryHierarchy

--- man/systemd.cgroup.xml | 11 +++ 1 file changed, 11 insertions(+) diff --git a/man/systemd.cgroup.xml b/man/systemd.cgroup.xml index ac58962..f347f1b 100644 --- a/man/systemd.cgroup.xml +++ b/man/systemd.cgroup.xml @@ -135,6 +135,17 @@ along with systemd; If not, see

[systemd-devel] [PATCH v2 3/4] systemctl: support setting MemoryHierarchy through systemctl

support setting MemoryHierarchy of unit through systemctl. --- src/systemctl/systemctl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c index 8b9183d..7d251a0 100644 --- a/src/systemctl/systemctl.c +++ b/src/systemctl/systemctl.c @@ -3644,

[systemd-devel] [PATCH v2 2/4] cgroup: show MemoryHierarchy in cgroup_context_dump

Show MemoryHierarchy in cgroup_context_dump. --- src/core/cgroup.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/core/cgroup.c b/src/core/cgroup.c index 68615c3..362b074 100644 --- a/src/core/cgroup.c +++ b/src/core/cgroup.c @@ -92,6 +92,7 @@ void cgroup_context_dump(CGroupContext *c,

[systemd-devel] [PATCH v2 1/4] cgroup: add the setting memory.use_hierarchy support for systemd

Some programs need to set the memory.use_hierarchy(such as libvirt), Add this feature. --- src/core/cgroup.c | 6 ++ src/core/cgroup.h | 1 + src/core/dbus-cgroup.c| 16 src/core/load-fragment-gperf.gperf.m4 | 1 + 4 f

Re: [systemd-devel] Question: who should set up the cpuset cgroup

On 09/18/2013 12:56 AM, Lennart Poettering wrote: > On Tue, 17.09.13 17:45, Lennart Poettering (lenn...@poettering.net) wrote: > >>> 1, set up when systemd creates cpuset cgroup for machine.slice? >>> 2, the programs which create the machines? >>> 3, other ideas? kernel? >> >> I have the suspicion

[systemd-devel] Question: who should set up the cpuset cgroup

Hi I'm working on adding set cpuset cgroup support for systemd. this work almost finished. but I faced a problem. As we know, if we create a machine,the cgroup for this machine will be created as well. and the cgroup of this machine is a sub-directory of machine.slice(or other slices..). And if t

[systemd-devel] [PATCH] cgroup: add missing equals for BlockIOWeight

--- src/core/cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/cgroup.c b/src/core/cgroup.c index 1f41efc..9277dd6 100644 --- a/src/core/cgroup.c +++ b/src/core/cgroup.c @@ -92,7 +92,7 @@ void cgroup_context_dump(CGroupContext *c, FILE* f, const char *prefix) {

Re: [systemd-devel] [PATCH 1/5] cgroup: add the setting memory.use_hierarchy support for systemd

On 09/13/2013 08:26 PM, Lennart Poettering wrote: > On Fri, 13.09.13 17:49, Gao feng (gaof...@cn.fujitsu.com) wrote: > >> Some programs need to set the memory.use_hierarchy(such as libvirt), >> Add this feature. > > Hmm, should this really be an option? Shouldn't

[systemd-devel] [PATCH 4/5] man: add manpage for MemoryHierarchy

add the manpage for MemoryHierarchy. --- man/systemd.cgroup.xml | 11 +++ 1 file changed, 11 insertions(+) diff --git a/man/systemd.cgroup.xml b/man/systemd.cgroup.xml index cc0eb15..80fc2e2 100644 --- a/man/systemd.cgroup.xml +++ b/man/systemd.cgroup.xml @@ -135,6 +135,17 @@ along with s

[systemd-devel] [PATCH 5/5] machine.slice: enable MemoryHierarchy by default

We can simply limit the total memory usage of machines through setting the memory usage limit of machine.slice. --- units/machine.slice | 3 +++ 1 file changed, 3 insertions(+) diff --git a/units/machine.slice b/units/machine.slice index 3d40dfd..c959598 100644 --- a/units/machine.slice +++ b/uni

[systemd-devel] [PATCH 3/5] systemctl: support setting MemoryHierarchy through systemctl

support setting MemoryHierarchy of unit through systemctl. --- src/systemctl/systemctl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c index 57e5bb9..87388bb 100644 --- a/src/systemctl/systemctl.c +++ b/src/systemctl/systemctl.c @@ -3643,

[systemd-devel] [PATCH 2/5] cgroup: show MemoryHierarchy in cgroup_context_dump

Show MemoryHierarchy in cgroup_context_dump. --- src/core/cgroup.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/core/cgroup.c b/src/core/cgroup.c index 336d394..2c8aa22 100644 --- a/src/core/cgroup.c +++ b/src/core/cgroup.c @@ -91,6 +91,7 @@ void cgroup_context_dump(CGroupContext *c,

[systemd-devel] [PATCH 1/5] cgroup: add the setting memory.use_hierarchy support for systemd

Some programs need to set the memory.use_hierarchy(such as libvirt), Add this feature. --- src/core/cgroup.c | 9 + src/core/cgroup.h | 1 + src/core/dbus-cgroup.c| 16 src/core/load-fragment-gperf.gperf.m4 | 1 +

[systemd-devel] [PATCH] cgroup: fix incorrectly setting memory cgroup

If the memory_limit of unit is -1, we should write "-1" to the file memory.limit_in_bytes. not the (unit64_t) -1. otherwise the memory.limit_in_bytes will be set to zero. --- src/core/cgroup.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/src/core/cgroup.c b

[systemd-devel] [PATCH 2/2] cgroup: correct the log information

it should be memory.soft_limit_in_bytes. --- src/core/cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/cgroup.c b/src/core/cgroup.c index fba0b2f..aee93ba 100644 --- a/src/core/cgroup.c +++ b/src/core/cgroup.c @@ -266,7 +266,7 @@ void cgroup_context_apply(CGrou

[systemd-devel] [PATCH 1/2] cgroup: add the missing setting of variable's value

set the value of variable "r" to the return value of cg_set_attribute. --- src/core/cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/cgroup.c b/src/core/cgroup.c index 3eeb475..fba0b2f 100644 --- a/src/core/cgroup.c +++ b/src/core/cgroup.c @@ -264,7 +264,7 @@ v

Re: [systemd-devel] implies "MemoryAccounting=true"

On 09/11/2013 08:07 PM, Lennart Poettering wrote: > On Wed, 11.09.13 09:18, Gao feng (gaof...@cn.fujitsu.com) wrote: > >>>> The SYSTEMD.CGROUP(5) said if MemoryLimit=bytes is set for unit, it >>>> implies MemeoryAccounting=true for this unit. >>>> >>

Re: [systemd-devel] [PATCH 1/3] blkio bandwidth: don't clean up all of entries in blockio_device_bandwidths list

On 09/10/2013 11:13 PM, Lennart Poettering wrote: > On Fri, 30.08.13 10:56, Gao feng (gaof...@cn.fujitsu.com) wrote: > >> if we get BlockIOReadBandwidth="", we should only remove the >> read-bandwidth-entries in blockio_device_bandwidths list. > > Thank

Re: [systemd-devel] implies "MemoryAccounting=true"

On 09/10/2013 11:50 PM, Lennart Poettering wrote: > On Mon, 26.08.13 11:19, Gao feng (gaof...@cn.fujitsu.com) wrote: > >> Hi >> >> The SYSTEMD.CGROUP(5) said if MemoryLimit=bytes is set for unit, it >> implies MemeoryAccounting=true for this unit. >> >&g

Re: [systemd-devel] [PATCH 1/3] cgroup: setup BlockIODeviceWeight in bus_cgroup_set_property

On 08/27/2013 01:36 PM, Gao feng wrote: > This patch adds the support for setting up BlockIODeviceWeight > in bus_cgroup_set_property. most of the codes are copied from > the case that sets up DeviceAllow. any comments? > --- > src/core/dbu

Re: [systemd-devel] implies "MemoryAccounting=true"

On 08/28/2013 07:45 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Aug 26, 2013 at 11:19:54AM +0800, Gao feng wrote: >> Hi >> >> The SYSTEMD.CGROUP(5) said if MemoryLimit=bytes is set for unit, it >> implies MemeoryAccounting=true for this unit. >> >> But s

[systemd-devel] [PATCH 3/3] systemcl: add support for setting BlockIORead/WriteBandwidth for unit

This patch allows user to set up BlockIOReadBandwidth and BlockIOWriteBandwidth for unit through systemctl. Such as systemctl set-property sshd.service BlockIOReadBandwidth="/dev/sda 10" systemctl set-property sshd.service BlockIOWriteBandwidth="/dev/sda 20" --- src/systemctl/systemctl.c

[systemd-devel] [PATCH 2/3] cgroup: setup BlockIORead/WriteBandwidth in bus_cgroup_set_property

This patch adds the support for setting up BlockIORead/WriteBandwidth in bus_cgroup_set_property. --- src/core/dbus-cgroup.c | 101 + 1 file changed, 101 insertions(+) diff --git a/src/core/dbus-cgroup.c b/src/core/dbus-cgroup.c index c0e2371..4ef20

[systemd-devel] [PATCH 1/3] blkio bandwidth: don't clean up all of entries in blockio_device_bandwidths list

if we get BlockIOReadBandwidth="", we should only remove the read-bandwidth-entries in blockio_device_bandwidths list. --- src/core/load-fragment.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c index 471468

[systemd-devel] [PATCH] blcokio bandwidth: add missing set of CGroupBlockIODeviceBandwidth's read

BlockIOReadBandwidth and BlockIOWriteBandwidth both use config_parse_blockio_bandwidth to set up CGroupBlockIODeviceBandwidth, We should set the read value based on the left values in config files. --- src/core/load-fragment.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/core/load-fragm

[systemd-devel] [PATCH v2] device cgroup: don't create a new CGroupDeviceAllow when it already in the list

If a device node is already in the device_allow list of CGroupContext, we should replace it instead of create a new one and append this new one to the end of device_allow list. change from v1: use streq to replace !strcmp --- src/core/dbus-cgroup.c | 32 +++- 1 file ch

[systemd-devel] [PATCH 3/3] systemctl: show BlockIODeviceWeight for unit

We can use systemctl show unitname to show the BlockIODeviceWeight of unit. --- src/systemctl/systemctl.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c index ff29b0f..4ea301a 100644 --- a/src/systemctl/systemctl.c +++

[systemd-devel] [PATCH 2/3] systemcl: add support for setting BlockIODeviceWeight for unit

This patch allows user to set up BlockIODeviceWeight for unit through systemctl. Such as systemctl set-property sshd.service BlockIODeviceWeight="/dev/sda 100" --- src/systemctl/systemctl.c | 37 + 1 file changed, 37 insertions(+) diff --git a/src/systemctl/sy

[systemd-devel] [PATCH 1/3] cgroup: setup BlockIODeviceWeight in bus_cgroup_set_property

This patch adds the support for setting up BlockIODeviceWeight in bus_cgroup_set_property. most of the codes are copied from the case that sets up DeviceAllow. --- src/core/dbus-cgroup.c | 85 ++ 1 file changed, 85 insertions(+) diff --git a/src/cor

[systemd-devel] [PATCH] device cgroup: don't create a new CGroupDeviceAllow when it already in the list

If a device node is already in the device_allow list of CGroupContext, we should replace it instead of create a new one and append this new one to the end of device_allow list. --- src/core/dbus-cgroup.c | 32 +++- 1 file changed, 23 insertions(+), 9 deletions(-) diff

Re: [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace

On 08/26/2013 11:19 AM, James Bottomley wrote: > On Mon, 2013-08-26 at 09:06 +0800, Gao feng wrote: >> On 08/26/2013 02:16 AM, James Bottomley wrote: >>> On Sun, 2013-08-25 at 19:37 +0200, Kay Sievers wrote: >>>> On Sun, Aug 25, 2013 at 7:16 PM, James Bottomley >

[systemd-devel] implies "MemoryAccounting=true"

Hi The SYSTEMD.CGROUP(5) said if MemoryLimit=bytes is set for unit, it implies MemeoryAccounting=true for this unit. But seems systemd didn't implement this hint. CPUShares & BlockIO have the same problem, this is a shortage? patch needed? Thanks ___ s

[systemd-devel] [PATCH] cgroup: only check once when mode is UNIT_CHECK

If the mode is UNIT_CHECK,it means we only want to check if the paramaters are valid. the first round of cycle already did this check, no need to check again. --- src/core/dbus-unit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/dbus-unit.c b/src/core/dbus-unit.c in

Re: [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace

On 08/26/2013 02:16 AM, James Bottomley wrote: > On Sun, 2013-08-25 at 19:37 +0200, Kay Sievers wrote: >> On Sun, Aug 25, 2013 at 7:16 PM, James Bottomley >> wrote: >>> On Wed, 2013-08-21 at 11:51 +0200, Kay Sievers wrote: >>>> On Wed, Aug 21, 2013 at 9:22 AM,

[systemd-devel] [PATCH] blkio: fix incorrect setting of cpu_shares

We should set up blockio_weight not cpu_shares. Signed-off-by: Gao feng --- src/core/dbus-cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/dbus-cgroup.c b/src/core/dbus-cgroup.c index 8ad3d11..9e97b20 100644 --- a/src/core/dbus-cgroup.c +++ b/src/core/dbus

Re: [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace

On 08/21/2013 06:42 PM, Eric W. Biederman wrote: > Gao feng writes: > >> right now I only take note of the unix socket /run/systemd/private, >> but there may have many similar unix sockets, they can exist in any >> path. the strange problems will still happen. > >

Re: [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace

On 08/21/2013 03:06 PM, Eric W. Biederman wrote: > Gao feng writes: > >> cc libvirt-list >> >> On 08/21/2013 01:30 PM, Eric W. Biederman wrote: >>> Gao feng writes: >>> >>>> Unix sockets are private resources of net namespace, >>&

Re: [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace

cc libvirt-list On 08/21/2013 01:30 PM, Eric W. Biederman wrote: > Gao feng writes: > >> Unix sockets are private resources of net namespace, >> allowing one net namespace to access to other netns's unix >> sockets is meaningless. > > Allowing one net names

Re: [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace

cc contain...@lists.linux-foundation.org On 08/21/2013 12:31 PM, Gao feng wrote: > Unix sockets are private resources of net namespace, > allowing one net namespace to access to other netns's unix > sockets is meaningless. > > I'm researching a problem about shutdown

[systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace

-h xxx in container, the shutdown message will be send to the systemd-shutdownd through unix socket /run/systemd/private, and because systemd-shutdownd is running in host, so finally, the host will become shutdown. We should make sure unix sockets are per net namespace to avoid this problem. Signed-o