date:20130710

[systemd-devel] [PATCH] man: document the slice unit

2013-07-10 Thread Zbigniew Jędrzejewski-Szmek

---
Does this description fit the masterplan? What about units that
systemd will expose for CPU and BlockIO shares, will they still be
1024 and 1000 based?

Zbyszek

PS. I think that apart from this we are still missing
the .scope man page, which should be trivial to write. 

 Makefile-man.am   |   1 +
 man/systemd.slice.xml | 199 ++
 2 files changed, 200 insertions(+)
 create mode 100644 man/systemd.slice.xml

diff --git a/Makefile-man.am b/Makefile-man.am
index bef749a..12abad8 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -84,6 +84,7 @@ MANPAGES += \
man/systemd.path.5 \
man/systemd.preset.5 \
man/systemd.service.5 \
+   man/systemd.slice.5 \
man/systemd.snapshot.5 \
man/systemd.socket.5 \
man/systemd.special.7 \
diff --git a/man/systemd.slice.xml b/man/systemd.slice.xml
new file mode 100644
index 000..24cca0a
--- /dev/null
+++ b/man/systemd.slice.xml
@@ -0,0 +1,199 @@
+?xml version='1.0'? !--*-nxml-*--
+?xml-stylesheet type=text/xsl 
href=http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl;?
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+
+!--
+This file is part of systemd.
+
+Copyright 2013 Zbigniew Jędrzejewski-Szmek
+
+systemd is free software; you can redistribute it and/or modify it
+under the terms of the GNU Lesser General Public License as published by
+the Free Software Foundation; either version 2.1 of the License, or
+(at your option) any later version.
+
+systemd is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+Lesser General Public License for more details.
+
+You should have received a copy of the GNU Lesser General Public License
+along with systemd; If not, see http://www.gnu.org/licenses/.
+--
+
+refentry id=systemd.slice
+  refentryinfo
+titlesystemd.slice/title
+productnamesystemd/productname
+
+authorgroup
+  author
+contribDeveloper/contrib
+firstnameLennart/firstname
+surnamePoettering/surname
+emaillenn...@poettering.net/email
+  /author
+/authorgroup
+  /refentryinfo
+
+  refmeta
+refentrytitlesystemd.slice/refentrytitle
+manvolnum5/manvolnum
+  /refmeta
+
+  refnamediv
+refnamesystemd.slice/refname
+refpurposeSlice unit configuration/refpurpose
+  /refnamediv
+
+  refsynopsisdiv
+parafilenamereplaceableslice/replaceable.slice/filename/para
+  /refsynopsisdiv
+
+  refsect1
+titleDescription/title
+
+paraA unit configuration file whose name ends in
+literal.slice/literal encodes information about a slice
+created by systemd to manage resources used by a certain group of
+processes. Those processes are part of different units, usually
+literal.service/literal units (see
+
citerefentryrefentrytitlesystemd.unit/refentrytitlemanvolnum5/manvolnum/citerefentry).
+/para
+
+paraThis man page lists the configuration options
+specific to this unit type. See
+
citerefentryrefentrytitlesystemd.unit/refentrytitlemanvolnum5/manvolnum/citerefentry
+for the common options of all unit configuration
+files. The common configuration items are configured
+in the generic [Unit] and [Install] sections. The
+slice specific configuration options are configured in
+the [Slice] section./para
+
+paraUnless varnameDefaultDependencies=false/varname
+is used, slice units will implicitly have dependencies of
+type varnameConflicts=/varname and
+varnameBefore=/varname on
+filenameshutdown.target/filename. These ensure
+that slice units are removed prior to system
+shutdown. Only slice units involved with early boot or
+late system shutdown should disable this option.
+/para
+  /refsect1
+
+  refsect1
+titleOptions/title
+
+paraSlice files may include a [Slice] section,
+which carries settings for that slice.
+The options specific to the [Slice] section
+of slice units are the following:/para
+
+variablelist class='unit-directives'
+  varlistentry
+termvarnameCPUAccounting=/varname/term
+
+listitem
+  paraTurn on the CPU usage accounting for this
+  slice./para
+/listitem
+  /varlistentry
+
+  varlistentry
+termvarnameBlockIOAccounting=/varname/term
+
+listitem
+  paraTurn on the Block IO bandwidth accounting
+  for this slice./para
+/listitem
+  /varlistentry
+
+  varlistentry
+termvarnameMemoryAccounting=/varname/term
+
+listitem
+  paraTurn on the process and kernel memory
+  accounting for this slice./para
+/listitem
+  /varlistentry
+
+  varlistentry
+termvarnameCPUShares=/varname/term
+
+listitem
+

[systemd-devel] [PATCH] core: notify triggered by socket of a service

2013-07-10 Thread Umut Tezduyar

---
 systemd/src/core/service.c |   31 ---
 systemd/src/core/socket.c  |   33 -
 systemd/src/core/socket.h  |3 ---
 3 files changed, 32 insertions(+), 35 deletions(-)

diff --git a/src/core/service.c b/src/core/service.c
index 3617c24..78ee272 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -1474,24 +1474,6 @@ static int service_search_main_pid(Service *s) {
 return 0;
 }
 
-static void service_notify_sockets_dead(Service *s, bool failed_permanent) {
-Iterator i;
-Unit *u;
-
-assert(s);
-
-/* Notifies all our sockets when we die */
-
-if (s-socket_fd = 0)
-return;
-
-SET_FOREACH(u, UNIT(s)-dependencies[UNIT_TRIGGERED_BY], i)
-if (u-type == UNIT_SOCKET)
-socket_notify_service_dead(SOCKET(u), 
failed_permanent);
-
-return;
-}
-
 static void service_set_state(Service *s, ServiceState state) {
 ServiceState old_state;
 const UnitActiveState *table;
@@ -1543,19 +1525,6 @@ static void service_set_state(Service *s, ServiceState 
state) {
 s-control_command_id = _SERVICE_EXEC_COMMAND_INVALID;
 }
 
-if (state == SERVICE_FAILED)
-service_notify_sockets_dead(s, s-result == 
SERVICE_FAILURE_START_LIMIT);
-
-if (state == SERVICE_DEAD ||
-state == SERVICE_STOP ||
-state == SERVICE_STOP_SIGTERM ||
-state == SERVICE_STOP_SIGKILL ||
-state == SERVICE_STOP_POST ||
-state == SERVICE_FINAL_SIGTERM ||
-state == SERVICE_FINAL_SIGKILL ||
-state == SERVICE_AUTO_RESTART)
-service_notify_sockets_dead(s, false);
-
 if (state != SERVICE_START_PRE 
 state != SERVICE_START 
 state != SERVICE_START_POST 
diff --git a/src/core/socket.c b/src/core/socket.c
index 1b08f0a..21bbba5 100644
--- a/src/core/socket.c
+++ b/src/core/socket.c
@@ -2261,7 +2261,7 @@ int socket_collect_fds(Socket *s, int **fds, unsigned 
*n_fds) {
 return 0;
 }
 
-void socket_notify_service_dead(Socket *s, bool failed_permanent) {
+static void socket_notify_service_dead(Socket *s, bool failed_permanent) {
 assert(s);
 
 /* The service is dead. Dang!
@@ -2306,6 +2306,35 @@ static void socket_reset_failed(Unit *u) {
 s-result = SOCKET_SUCCESS;
 }
 
+static void socket_trigger_notify(Unit *u, Unit *other) {
+Socket *s = SOCKET(u);
+Service *se = SERVICE(other);
+
+assert(u);
+assert(other);
+
+if (other-load_state != UNIT_LOADED ||
+other-type != UNIT_SERVICE)
+return;
+
+if (se-state == SERVICE_FAILED  se-socket_fd  0)
+socket_notify_service_dead(s, se-result == 
SERVICE_FAILURE_START_LIMIT);
+
+if ((se-state == SERVICE_DEAD ||
+se-state == SERVICE_STOP ||
+se-state == SERVICE_STOP_SIGTERM ||
+se-state == SERVICE_STOP_SIGKILL ||
+se-state == SERVICE_STOP_POST ||
+se-state == SERVICE_FINAL_SIGTERM ||
+se-state == SERVICE_FINAL_SIGKILL ||
+se-state == SERVICE_AUTO_RESTART) 
+se-socket_fd  0)
+socket_notify_service_dead(s, false);
+
+if (se-state == SERVICE_RUNNING)
+socket_set_state(s, SOCKET_RUNNING);
+}
+
 static int socket_kill(Unit *u, KillWho who, int signo, DBusError *error) {
 return unit_kill_common(u, who, signo, -1, SOCKET(u)-control_pid, 
error);
 }
@@ -2385,6 +2414,8 @@ const UnitVTable socket_vtable = {
 .sigchld_event = socket_sigchld_event,
 .timer_event = socket_timer_event,
 
+.trigger_notify = socket_trigger_notify,
+
 .reset_failed = socket_reset_failed,
 
 .bus_interface = org.freedesktop.systemd1.Socket,
diff --git a/src/core/socket.h b/src/core/socket.h
index 9d48cde..9714303 100644
--- a/src/core/socket.h
+++ b/src/core/socket.h
@@ -154,9 +154,6 @@ struct Socket {
 /* Called from the service code when collecting fds */
 int socket_collect_fds(Socket *s, int **fds, unsigned *n_fds);
 
-/* Called from the service when it shut down */
-void socket_notify_service_dead(Socket *s, bool failed_permanent);
-
 /* Called from the mount code figure out if a mount is a dependency of
  * any of the sockets of this socket */
 int socket_add_one_mount_link(Socket *s, Mount *m);
-- 
1.7.2.5

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] core: notify triggered by socket of a service

2013-07-10 Thread Umut Tezduyar

Hi,

This patch is in reference to
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011405.html
in case your mail client doesn't group it by the thread. I have tested
it on systemd 204 but patch applies to 205 (not tested).

Thanks

On Wed, Jul 10, 2013 at 9:19 AM, Umut Tezduyar u...@tezduyar.com wrote:
 ---
  systemd/src/core/service.c |   31 ---
  systemd/src/core/socket.c  |   33 -
  systemd/src/core/socket.h  |3 ---
  3 files changed, 32 insertions(+), 35 deletions(-)

 diff --git a/src/core/service.c b/src/core/service.c
 index 3617c24..78ee272 100644
 --- a/src/core/service.c
 +++ b/src/core/service.c
 @@ -1474,24 +1474,6 @@ static int service_search_main_pid(Service *s) {
  return 0;
  }

 -static void service_notify_sockets_dead(Service *s, bool failed_permanent) {
 -Iterator i;
 -Unit *u;
 -
 -assert(s);
 -
 -/* Notifies all our sockets when we die */
 -
 -if (s-socket_fd = 0)
 -return;
 -
 -SET_FOREACH(u, UNIT(s)-dependencies[UNIT_TRIGGERED_BY], i)
 -if (u-type == UNIT_SOCKET)
 -socket_notify_service_dead(SOCKET(u), 
 failed_permanent);
 -
 -return;
 -}
 -
  static void service_set_state(Service *s, ServiceState state) {
  ServiceState old_state;
  const UnitActiveState *table;
 @@ -1543,19 +1525,6 @@ static void service_set_state(Service *s, ServiceState 
 state) {
  s-control_command_id = _SERVICE_EXEC_COMMAND_INVALID;
  }

 -if (state == SERVICE_FAILED)
 -service_notify_sockets_dead(s, s-result == 
 SERVICE_FAILURE_START_LIMIT);
 -
 -if (state == SERVICE_DEAD ||
 -state == SERVICE_STOP ||
 -state == SERVICE_STOP_SIGTERM ||
 -state == SERVICE_STOP_SIGKILL ||
 -state == SERVICE_STOP_POST ||
 -state == SERVICE_FINAL_SIGTERM ||
 -state == SERVICE_FINAL_SIGKILL ||
 -state == SERVICE_AUTO_RESTART)
 -service_notify_sockets_dead(s, false);
 -
  if (state != SERVICE_START_PRE 
  state != SERVICE_START 
  state != SERVICE_START_POST 
 diff --git a/src/core/socket.c b/src/core/socket.c
 index 1b08f0a..21bbba5 100644
 --- a/src/core/socket.c
 +++ b/src/core/socket.c
 @@ -2261,7 +2261,7 @@ int socket_collect_fds(Socket *s, int **fds, unsigned 
 *n_fds) {
  return 0;
  }

 -void socket_notify_service_dead(Socket *s, bool failed_permanent) {
 +static void socket_notify_service_dead(Socket *s, bool failed_permanent) {
  assert(s);

  /* The service is dead. Dang!
 @@ -2306,6 +2306,35 @@ static void socket_reset_failed(Unit *u) {
  s-result = SOCKET_SUCCESS;
  }

 +static void socket_trigger_notify(Unit *u, Unit *other) {
 +Socket *s = SOCKET(u);
 +Service *se = SERVICE(other);
 +
 +assert(u);
 +assert(other);
 +
 +if (other-load_state != UNIT_LOADED ||
 +other-type != UNIT_SERVICE)
 +return;
 +
 +if (se-state == SERVICE_FAILED  se-socket_fd  0)
 +socket_notify_service_dead(s, se-result == 
 SERVICE_FAILURE_START_LIMIT);
 +
 +if ((se-state == SERVICE_DEAD ||
 +se-state == SERVICE_STOP ||
 +se-state == SERVICE_STOP_SIGTERM ||
 +se-state == SERVICE_STOP_SIGKILL ||
 +se-state == SERVICE_STOP_POST ||
 +se-state == SERVICE_FINAL_SIGTERM ||
 +se-state == SERVICE_FINAL_SIGKILL ||
 +se-state == SERVICE_AUTO_RESTART) 
 +se-socket_fd  0)
 +socket_notify_service_dead(s, false);
 +
 +if (se-state == SERVICE_RUNNING)
 +socket_set_state(s, SOCKET_RUNNING);
 +}
 +
  static int socket_kill(Unit *u, KillWho who, int signo, DBusError *error) {
  return unit_kill_common(u, who, signo, -1, SOCKET(u)-control_pid, 
 error);
  }
 @@ -2385,6 +2414,8 @@ const UnitVTable socket_vtable = {
  .sigchld_event = socket_sigchld_event,
  .timer_event = socket_timer_event,

 +.trigger_notify = socket_trigger_notify,
 +
  .reset_failed = socket_reset_failed,

  .bus_interface = org.freedesktop.systemd1.Socket,
 diff --git a/src/core/socket.h b/src/core/socket.h
 index 9d48cde..9714303 100644
 --- a/src/core/socket.h
 +++ b/src/core/socket.h
 @@ -154,9 +154,6 @@ struct Socket {
  /* Called from the service code when collecting fds */
  int socket_collect_fds(Socket *s, int **fds, unsigned *n_fds);

 -/* Called from the service when it shut down */
 -void socket_notify_service_dead(Socket *s, bool failed_permanent);
 -
  /* Called from the mount code figure out if a mount is a dependency of
   * any of the sockets of this socket */
  int socket_add_one_mount_link(Socket *s, Mount *m);
 --
 1.7.2.5

Re: [systemd-devel] journal and /run/systemd/journal/syslog

2013-07-10 Thread Umut Tezduyar

On Tue, Jul 9, 2013 at 1:58 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Sun, 07.07.13 19:18, Umut Tezduyar (u...@tezduyar.com) wrote:

 Hi,

 I have noticed that if journal fails to send messages to
 /run/systemd/journal/syslog, it increments a counter and every 30
 seconds it prints out a message on journal informing that forwarding x
 many messages has failed. If journal storage is set to none, there is
 no way of being informed about the missing messages. Should we not try
 to send a message to /run/systemd/journal/syslog if/when it has space
 again?

 Yes, sounds sensible. Added to the TODO list.

 syslog.socket sets ReceiveBuffer=8M. My understanding is intention of
 setting this value is specifying the maximum size of one datagram
 message that is allowed to send. socket.c is setting the SO_RCVBUF on
 the socket. According to man unix 7, SO_RCVBUF has no effect on the
 datagram but SO_SNDBUF does. Am I missing something?

 Oh, hm, this sucks. I wasn't aware of this. I always assumed SO_RCVBUF
 and SO_SNDBUF would both alter the same buffer, just from differente
 sides.

 Number of messages that can be queued on /run/systemd/journal/syslog
 is controlled by /proc/sys/net/unix/max_dgram_qlen and this value is
 by default 10 in most distributions. What this means is, after journal
 forwards 11 messages to the socket, it will not be able to do so until
 external logging daemon comes up and clears up
 /run/systemd/journal/syslog. If logging daemon is starting after
 basic.target, it is pretty certain that it will not be able to receive
 all the early boot messages. Increasing
 /proc/sys/net/unix/max_dgram_qlen is an option but is increasing a
 system wide limit right thing to do?

 Yeah, this is a big issue. For a long time there has been an item on the
 kernel wishlist to get an ioctl for setting the qlen per-socket. The
 code for that should actually be simple.

Luckily kernel doesn't allocate a buffer for the socket
(kernel:net/unix/af_unix.c) according to the value meaning setting it
to 10 or 1000 doesn't matter in terms of pre-allocating memory.


 We though about just bumping this globally via sysctl, but we feared
 that might not sit well with some folks, as we shouldn't change a global
 setting just because one user of it would benefit, especially given that
 we don't know the effect this might have on others...

I want to go this route and I think it is not possible at the moment
due to undetermined start order between syslog.socket and
systemd-sysctl.service. Can we change that?


 The better approach really appeared to us to be fixing the kernel
 properly instead, and get that new ioctl.

 Lennart

 --
 Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journal and /run/systemd/journal/syslog

2013-07-10 Thread Kay Sievers

On Wed, Jul 10, 2013 at 12:30 PM, Umut Tezduyar u...@tezduyar.com wrote:
 On Tue, Jul 9, 2013 at 1:58 AM, Lennart Poettering
 lenn...@poettering.net wrote:

 We though about just bumping this globally via sysctl, but we feared
 that might not sit well with some folks, as we shouldn't change a global
 setting just because one user of it would benefit, especially given that
 we don't know the effect this might have on others...

 I want to go this route and I think it is not possible at the moment
 due to undetermined start order between syslog.socket and
 systemd-sysctl.service. Can we change that?

It really makes more sense to add a socket option to the kernel to
allow a privileged process to bump the limit for the one socket
setsockopt() is called, and not change and rely on a global
system-wide value affecting the entire system.

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journal and /run/systemd/journal/syslog

2013-07-10 Thread Umut Tezduyar

On Wed, Jul 10, 2013 at 12:55 PM, Kay Sievers k...@vrfy.org wrote:
 On Wed, Jul 10, 2013 at 12:30 PM, Umut Tezduyar u...@tezduyar.com wrote:
 On Tue, Jul 9, 2013 at 1:58 AM, Lennart Poettering
 lenn...@poettering.net wrote:

 We though about just bumping this globally via sysctl, but we feared
 that might not sit well with some folks, as we shouldn't change a global
 setting just because one user of it would benefit, especially given that
 we don't know the effect this might have on others...

 I want to go this route and I think it is not possible at the moment
 due to undetermined start order between syslog.socket and
 systemd-sysctl.service. Can we change that?

 It really makes more sense to add a socket option to the kernel to
 allow a privileged process to bump the limit for the one socket
 setsockopt() is called, and not change and rely on a global
 system-wide value affecting the entire system.

 Kay

We are totally on the same page on having a per-socket limit but I am
guessing this change is not going to happen tomorrow. Even if it did,
adopting the new kernel will also take some time. It would be nice to
have a solution meanwhile.

Umut
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] core: notify triggered by socket of a service

2013-07-10 Thread Umut Tezduyar

On Wed, Jul 10, 2013 at 9:19 AM, Umut Tezduyar u...@tezduyar.com wrote:
 ---
  systemd/src/core/service.c |   31 ---
  systemd/src/core/socket.c  |   33 -
  systemd/src/core/socket.h  |3 ---
  3 files changed, 32 insertions(+), 35 deletions(-)

 diff --git a/src/core/service.c b/src/core/service.c
 index 3617c24..78ee272 100644
 --- a/src/core/service.c
 +++ b/src/core/service.c
 @@ -1474,24 +1474,6 @@ static int service_search_main_pid(Service *s) {
  return 0;
  }

 -static void service_notify_sockets_dead(Service *s, bool failed_permanent) {
 -Iterator i;
 -Unit *u;
 -
 -assert(s);
 -
 -/* Notifies all our sockets when we die */
 -
 -if (s-socket_fd = 0)
 -return;
 -
 -SET_FOREACH(u, UNIT(s)-dependencies[UNIT_TRIGGERED_BY], i)
 -if (u-type == UNIT_SOCKET)
 -socket_notify_service_dead(SOCKET(u), 
 failed_permanent);
 -
 -return;
 -}
 -
  static void service_set_state(Service *s, ServiceState state) {
  ServiceState old_state;
  const UnitActiveState *table;
 @@ -1543,19 +1525,6 @@ static void service_set_state(Service *s, ServiceState 
 state) {
  s-control_command_id = _SERVICE_EXEC_COMMAND_INVALID;
  }

 -if (state == SERVICE_FAILED)
 -service_notify_sockets_dead(s, s-result == 
 SERVICE_FAILURE_START_LIMIT);
 -
 -if (state == SERVICE_DEAD ||
 -state == SERVICE_STOP ||
 -state == SERVICE_STOP_SIGTERM ||
 -state == SERVICE_STOP_SIGKILL ||
 -state == SERVICE_STOP_POST ||
 -state == SERVICE_FINAL_SIGTERM ||
 -state == SERVICE_FINAL_SIGKILL ||
 -state == SERVICE_AUTO_RESTART)
 -service_notify_sockets_dead(s, false);
 -
  if (state != SERVICE_START_PRE 
  state != SERVICE_START 
  state != SERVICE_START_POST 
 diff --git a/src/core/socket.c b/src/core/socket.c
 index 1b08f0a..21bbba5 100644
 --- a/src/core/socket.c
 +++ b/src/core/socket.c
 @@ -2261,7 +2261,7 @@ int socket_collect_fds(Socket *s, int **fds, unsigned 
 *n_fds) {
  return 0;
  }

 -void socket_notify_service_dead(Socket *s, bool failed_permanent) {
 +static void socket_notify_service_dead(Socket *s, bool failed_permanent) {
  assert(s);

  /* The service is dead. Dang!
 @@ -2306,6 +2306,35 @@ static void socket_reset_failed(Unit *u) {
  s-result = SOCKET_SUCCESS;
  }

 +static void socket_trigger_notify(Unit *u, Unit *other) {
 +Socket *s = SOCKET(u);
 +Service *se = SERVICE(other);
 +
 +assert(u);
 +assert(other);
 +
 +if (other-load_state != UNIT_LOADED ||
 +other-type != UNIT_SERVICE)
 +return;
 +
 +if (se-state == SERVICE_FAILED  se-socket_fd  0)
 +socket_notify_service_dead(s, se-result == 
 SERVICE_FAILURE_START_LIMIT);
 +
 +if ((se-state == SERVICE_DEAD ||
 +se-state == SERVICE_STOP ||
 +se-state == SERVICE_STOP_SIGTERM ||
 +se-state == SERVICE_STOP_SIGKILL ||
 +se-state == SERVICE_STOP_POST ||
 +se-state == SERVICE_FINAL_SIGTERM ||
 +se-state == SERVICE_FINAL_SIGKILL ||
 +se-state == SERVICE_AUTO_RESTART) 
 +se-socket_fd  0)
 +socket_notify_service_dead(s, false);
 +
 +if (se-state == SERVICE_RUNNING)
 +socket_set_state(s, SOCKET_RUNNING);
This doesn't work for socket activated/instantiated services. I should
be able to detect if a service is instantiated..
 +}
 +
  static int socket_kill(Unit *u, KillWho who, int signo, DBusError *error) {
  return unit_kill_common(u, who, signo, -1, SOCKET(u)-control_pid, 
 error);
  }
 @@ -2385,6 +2414,8 @@ const UnitVTable socket_vtable = {
  .sigchld_event = socket_sigchld_event,
  .timer_event = socket_timer_event,

 +.trigger_notify = socket_trigger_notify,
 +
  .reset_failed = socket_reset_failed,

  .bus_interface = org.freedesktop.systemd1.Socket,
 diff --git a/src/core/socket.h b/src/core/socket.h
 index 9d48cde..9714303 100644
 --- a/src/core/socket.h
 +++ b/src/core/socket.h
 @@ -154,9 +154,6 @@ struct Socket {
  /* Called from the service code when collecting fds */
  int socket_collect_fds(Socket *s, int **fds, unsigned *n_fds);

 -/* Called from the service when it shut down */
 -void socket_notify_service_dead(Socket *s, bool failed_permanent);
 -
  /* Called from the mount code figure out if a mount is a dependency of
   * any of the sockets of this socket */
  int socket_add_one_mount_link(Socket *s, Mount *m);
 --
 1.7.2.5

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald and kernel logging

2013-07-10 Thread Tomasz Sobczyk

Hmm, it might be my system configuration or a kernel bug, not systemd.
The thing is that kernel messages instead of being outputted to
/dev/console are outputted to the currently active VT.

I use metalog as the syslog and when it's run, these messages aren't
outputted to the VT. I saw that journald reads kernel messages and
stores them in its logs, so I was wondering whether it's supposed to
intercept/block that output like syslogs or not.

On 5 July 2013 22:23, Lennart Poettering lenn...@poettering.net wrote:
 On Thu, 04.07.13 14:38, Tomasz Sobczyk (dott...@gmail.com) wrote:

 Hi,

 Is the fact that journald reads the kernel log, but doesn't prevent
 the messages from outputting to the active terminal a bug or desired
 behaviour?

 # echo Test  /dev/kmsg
 Test
 #

 If I, let's say, connect a USB device then the active terminal is
 spammed with the kernel log messages. I can prevent this by starting a
 system logger, but with journald running I shouldn't need another one,
 right?

 The log messages the kernel forwards to the console may be configured
 using /proc/sys/kernel/printk, and that's hardly something for journald
 to configure. See man 5 proc for details on tha file.

 Lennart

 --
 Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald and kernel logging

2013-07-10 Thread Kay Sievers

On Wed, Jul 10, 2013 at 2:41 PM, Tomasz Sobczyk dott...@gmail.com wrote:
 Hmm, it might be my system configuration or a kernel bug, not systemd.
 The thing is that kernel messages instead of being outputted to
 /dev/console are outputted to the currently active VT.

 I use metalog as the syslog and when it's run, these messages aren't
 outputted to the VT. I saw that journald reads kernel messages and
 stores them in its logs, so I was wondering whether it's supposed to
 intercept/block that output like syslogs or not.

No, it's not.

Systemd does not claim ownership of the kernel or console log, and
should not fiddle with the kernel's console log level.

The admin, you, can surely do that though.

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] no installed machine-id vs systemd-in-initramfs

2013-07-10 Thread Colin Walters

The gnome-ostree build system generates disk images that can be
downloaded directly; there is no installer.

In the old model of dracut shell script + systemd, systemd's main.c
has:
if (arg_running_as == SYSTEMD_SYSTEM ...) {
  ...
  machine_id_setup();
  ...
}

So after mounting the rootfs, we'd end up writing one to /etc (at least
in gnome-ostree which comes with a writable copy of /etc), and it would
persist across reboots, and all would be well with the world.

In the new systemd-in-initramfs model, journald is now launched in the
initramfs.  Dracut will copy the host's machine id into the initramfs
if it exists, but in the gnome-ostree case (or more generally
pre-canned OS case), there isn't one.  journald will attempt to start,
and fail.

One thought I had is to say:  If there's no /etc/machine-id in the
initramfs, write one to /run/machine-id.  After mounting the rootfs,
persist that to /etc.

Except to really make that work, we'd need to regenerate the initramfs
client side after doing this.  I'd really like to avoid rebuilding the
initramfs on the client.

My instinct at this point is to just generate a new
default /etc/machine-id for each build.  That would have the unfortunate
consequence of not being globally unique.  But...I could just overwrite
that default machine ID with a new one in an installer type program.
Which would be mostly OK, but still feels like a hack.

Any other thoughts on this?


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Help getting serial console working again after upgrade to systemd?

2013-07-10 Thread Dmt Ops

Hey all,

I'm starting upgrades to old production servers to newer 64-bit Linux that
runs systemd = v195.

Serial consoles are always my 1st step.  Before upgrade it worked great.

After upgrade, with the new systemd-based config, I'm not having much luck
so far.

I configured the grub conf:

serial --unit=0 --speed=57600 --word=8 --parity=no --stop=1
terminal --timeout=3 serial console
title PRODUCTION
 root (hd0,0)
 kernel /vmlinuz root=/dev/sd1a noresume showopts x11failsafe vga=0x31a
console=tty0 console=com1,vga
 initrd /initrd

I installed the getty service on S0:

cat /etc/systemd/system/getty.target.wants/serial-getty@ttyS0.service
[Unit]
Description=Serial Getty on %I
Documentation=systemd-getty-generator
BindsTo=dev-%i.device
After=dev-%i.device systemd-user-sessions.service
Before=getty.target
IgnoreOnIsolate=yes

[Service]
ExecStart=-/sbin/agetty -s %I 57600 vt102
Type=idle
Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
KillSignal=SIGHUP

[Install]
WantedBy=getty.target


After a system boot the service is up:

systemctl status serial-getty@ttyS0.service
serial-getty@ttyS0.service - Serial Getty on ttyS0
  Loaded: loaded (/etc/systemd/system/serial-getty@.service;
enabled)
  Active: active (running) since Wed, 2013-07-10 10:55:13 PDT;
16min ago
Docs: man:agetty(8)
  man:systemd-getty-generator(8)
Main PID: 1043 (agetty)
  CGroup: name=systemd:/system/serial-getty@.service/ttyS0
  └ 1043 /sbin/agetty -s ttyS0 57600 vt102

Jul 10 10:55:13 rosencrantz.lan systemd[1]: Starting Serial Getty on
ttyS0...
Jul 10 10:55:13 rosencrantz.lan systemd[1]: Started Serial Getty on ttyS0.

ps ax | grep S0
 1043 ttyS0Ss+0:00 /sbin/agetty -s ttyS0 57600 vt102

dmesg looks like the serial port is active:

dmesg | egrep -i S0|serial|console|tty | egrep -vi usb
[0.00] Command line: root=/dev/sd1a noresume showopts
x11failsafe vga=0x31a console=tty0 console=com1,vga
[0.00] Kernel command line: root=/dev/sd1a noresume showopts
x11failsafe vga=0x31a console=tty0 console=com1,vga
[0.00] console [tty0] enabled
[0.218685] ACPI: (supports S0 S1 S3 S4 S5)
[1.228895] Console: switching to colour frame buffer device 160x64
[1.318499] Serial: 8250/16550 driver, 32 ports, IRQ sharing disabled
[1.339563] 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   21.032996] systemd[1]: Expecting device dev-ttyS0.device...
[   21.739832] systemd[1]: Starting Dispatch Password Requests to
Console Directory Watch.
[   21.775883] systemd[1]: Started Dispatch Password Requests to
Console Directory Watch.
[   24.305690] systemd[1]: Starting Setup Virtual Console...
[   25.384797] systemd[1]: Started Setup Virtual Console.
[   26.942274] systemd[1]: Found device /dev/ttyS0.
[   32.493821] Console: switching to colour dummy device 80x25
[   32.691960] Console: switching to colour frame buffer device 240x67
[   41.849014] systemd[1]: Starting Console System Startup Logging...
[   42.550658] systemd[1]: Started Console System Startup Logging.

With that setup I get nothing out the serial port.  I probably have the
grub cmd line wrong for using with systemd.  I could use some help getting
this untangled.

Dave
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Forward systemd's sleep.target to a systemd user session

2013-07-10 Thread Jörg Thalheim

How I can trigger sleep.target in systemd --user session?

My naive approach was first:

user-sleep@.service

   [Unit]
   Description=sleep.target of a systemd user session
   Before=sleep.target
   StopWhenUnneeded=yes

   [Service]
   Type=oneshot
   User=%I
   RemainAfterExit=yes
   ExecStart=/usr/bin/systemctl --user start sleep.target
   ExecStop=/usr/bin/systemctl --user stop sleep.target

   [Install]
   WantedBy=sleep.target

sleep.target

   [|Unit]
   Description=Sleep Timer Target
   StopWhenUnneeded=yes

|
|Unfortunately I got the following error:

||$ systemctl status user-sleep@joerg
user-sleep@joerg.service - sleep.target of a systemd user session
   Loaded: loaded (/etc/systemd/system/user-sleep@.service; enabled)
   Active: failed (Result: exit-code) since Mo 2013-06-10 12:30:41 CEST; 
43min ago
  Process: 10503 ExecStart=/usr/bin/systemctl --user start sleep.target 
(code=exited, status=1/FAILURE)

Jun 10 12:30:41 turing-machine systemd[1]: Service user-sleep@joerg.service 
is not needed anymore. Stopping.
Jun 10 12:30:41 turing-machine systemd[1]: user-sleep@joerg.service: main 
process exited, code=exited, status=1/FAILURE
Jun 10 12:30:41 turing-machine systemd[1]: Failed to start sleep.target of 
a systemd user session.
Jun 10 12:30:41 turing-machine systemd[1]: Unit user-sleep@joerg.service 
entered failed state.|

Can I use systemctl --user only at a login shell and not in a systemd
unit? Because using systemd --user from tty works great.
My use case is to logout my jabber client before suspend (I hope this
does not sounds to trivial compared to your serious problems, but you
might come up with other use cases).
This cannot be done in a normal .service file, because it does require a
connection to the current dbus session.




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] update: udev keymaps are moving to hwdb

2013-07-10 Thread Kay Sievers

We need to cut down the use of udev rules, and move all hardware
matches to the magnitudes more efficient hardware database. Udev rules
were not meant to carry out huge lists of sequential matches against
hardware IDs, this model just doesn't scale too well.

The keymaps are the first, other users like libsane, libgphoto, media
player, ... should be converted too.

The systemd git source tree has now all the pieces to prepare the move
from the current keymap handling to the hardware database. None of it
will take any action at the moment, the hwdb file is not committed.

All keymap scan/key code pairs, and the force-release lists will move
into the file:
  /usr/lib/udev/hwdb.d/60-keyboard.hwdb

The input device will import the keymap data into the udev database like:
  $ udevadm test /class/input/event5
  ...
  KEYBOARD_KEY_01=screenlock
  KEYBOARD_KEY_02=battery
  KEYBOARD_KEY_03=sleep
  KEYBOARD_KEY_04=wlan
  KEYBOARD_KEY_06=switchvideomode
  KEYBOARD_KEY_07=f21
  KEYBOARD_KEY_08=f24
  KEYBOARD_KEY_0b=suspend
  KEYBOARD_KEY_0f=brightnessup
  KEYBOARD_KEY_10=brightnessdown
  ...

There is a new builtin keyboard which will read these keys and
install them into the kernel device.

The force-release flag is carried as '!' in front of the key identifier like:
  KEYBOARD_KEY_78=mail
  KEYBOARD_KEY_82=!switchvideomode
  KEYBOARD_KEY_83=!battery

After all keymap data is moved to the 60-keyboard.hwdb file, all
current keymap files, force-release files, the keymap binary, the udev
rule and the force-release shell script will be removed from the
source tree.

Attached is the current version of the hwdb file, which is not
committed to the source tree. It contains maybe 30% of the old keymaps
and should cover all of the force-release lists. The header of the
file carries some documentation.

Some data like USB devices with too broad and insufficient matches on
the USB strings instead of the USB IDs cannot be ported over and need
to be reworked if they are still needed.

Any help or testing would be more than welcome to get that thing
properly working.

Thanks,
Kay


60-keyboard.hwdb
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] basic SO_REUSEPORT support

2013-07-10 Thread Shawn

On Tue, Jul 9, 2013 at 1:32 PM, Tomasz Torcz to...@pipebreaker.pl wrote:

 On Tue, Jul 09, 2013 at 01:01:13PM -0700, Shawn wrote:
  --

   How do you envision using this?  Does it even make sense with
 systemd-managed sockets?

I want systemd to be able to have multiple systemd.socket units attached to
the same tcp or udp port. Among other things, this would allow a system to
do a graceful handoff/restart/shutdown-into-socket-activated-to-save-memory
thing.

---
Shawn Landden
+1 360 389 3001 (SMS preferred)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] basic SO_REUSEPORT support

2013-07-10 Thread Shawn

The idea (not supported in this patch) is that a service could feed via
dbus a systemd.socket of itsself, and when that is activated, then close
its own listen()/bind() and shut down, cleanly waiting for systemd to start
it up again when needed. This could be used by ssh for example, triggered
when the last user logs out.


On Tue, Jul 9, 2013 at 1:49 PM, Lennart Poettering
lenn...@poettering.netwrote:

 On Tue, 09.07.13 13:01, Shawn (shawnland...@gmail.com) wrote:

 Heya,

 reuse is an english word, hence no need to put a middle capital letter
 in it, i.e. ReUsePort looks wrong, ReusePort looks better.

 The thing is a boolean, so it should have type bool. It's not an int.

 Also, there are tabs in the sources, please use spaces instead.

 How precisely is this supposed to be used, can you provide an example?

 Lennart

 --
 Lennart Poettering - Red Hat, Inc.




-- 

---
Shawn Landden
+1 360 389 3001 (SMS preferred)


0001-basic-SO_REUSEPORT-support.patch
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] basic SO_REUSEPORT support

2013-07-10 Thread Shawn

fixed ReUsePort


On Wed, Jul 10, 2013 at 3:42 PM, Shawn shawnland...@gmail.com wrote:

 The idea (not supported in this patch) is that a service could feed via
 dbus a systemd.socket of itsself, and when that is activated, then close
 its own listen()/bind() and shut down, cleanly waiting for systemd to start
 it up again when needed. This could be used by ssh for example, triggered
 when the last user logs out.


 On Tue, Jul 9, 2013 at 1:49 PM, Lennart Poettering lenn...@poettering.net
  wrote:

 On Tue, 09.07.13 13:01, Shawn (shawnland...@gmail.com) wrote:

 Heya,

 reuse is an english word, hence no need to put a middle capital letter
 in it, i.e. ReUsePort looks wrong, ReusePort looks better.

 The thing is a boolean, so it should have type bool. It's not an int.

 Also, there are tabs in the sources, please use spaces instead.

 How precisely is this supposed to be used, can you provide an example?

 Lennart

 --
 Lennart Poettering - Red Hat, Inc.




 --

 ---
 Shawn Landden
 +1 360 389 3001 (SMS preferred)




-- 

---
Shawn Landden
+1 360 389 3001 (SMS preferred)


0001-basic-SO_REUSEPORT-support.patch
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] basic SO_REUSEPORT support

2013-07-10 Thread Shawn

really fix ReUsePort capitalization


On Wed, Jul 10, 2013 at 3:43 PM, Shawn shawnland...@gmail.com wrote:

 fixed ReUsePort


 On Wed, Jul 10, 2013 at 3:42 PM, Shawn shawnland...@gmail.com wrote:

 The idea (not supported in this patch) is that a service could feed via
 dbus a systemd.socket of itsself, and when that is activated, then close
 its own listen()/bind() and shut down, cleanly waiting for systemd to start
 it up again when needed. This could be used by ssh for example, triggered
 when the last user logs out.


 On Tue, Jul 9, 2013 at 1:49 PM, Lennart Poettering 
 lenn...@poettering.net wrote:

 On Tue, 09.07.13 13:01, Shawn (shawnland...@gmail.com) wrote:

 Heya,

 reuse is an english word, hence no need to put a middle capital letter
 in it, i.e. ReUsePort looks wrong, ReusePort looks better.

 The thing is a boolean, so it should have type bool. It's not an int.

 Also, there are tabs in the sources, please use spaces instead.

 How precisely is this supposed to be used, can you provide an example?

 Lennart

 --
 Lennart Poettering - Red Hat, Inc.




 --

 ---
 Shawn Landden
 +1 360 389 3001 (SMS preferred)




 --

 ---
 Shawn Landden
 +1 360 389 3001 (SMS preferred)




-- 

---
Shawn Landden
+1 360 389 3001 (SMS preferred)


0001-basic-SO_REUSEPORT-support.patch
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] cgroups: chown user slices

2013-07-10 Thread Lennart Poettering

On Sat, 06.07.13 01:16, Marc-Antoine Perennou (marc-anto...@perennou.com) wrote:

 When creating the cgroup hierarchy for a user slice,
 chown this slice to the user uid.
 
 Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
 ---
  src/shared/cgroup-label.c | 8 
  1 file changed, 8 insertions(+)
 
 diff --git a/src/shared/cgroup-label.c b/src/shared/cgroup-label.c
 index 574a7be..1891c9a 100644
 --- a/src/shared/cgroup-label.c
 +++ b/src/shared/cgroup-label.c
 @@ -41,6 +41,7 @@
  
  int cg_create(const char *controller, const char *path) {
  _cleanup_free_ char *fs = NULL;
 +uid_t uid = (uid_t) -1;
  int r;
  
  r = cg_get_path_and_check(controller, path, NULL, fs);
 @@ -59,6 +60,13 @@ int cg_create(const char *controller, const char *path) {
  return -errno;
  }
  
 +r = cg_path_get_owner_uid(path, uid);
 +if (r  0  r != -ENOENT)
 +return r;
 +
 +if (uid != (uid_t) -1)
 +chown(fs, uid, (gid_t) -1);
 +

systemd in git will now grant access to the cgroup subtree in
user@.service to the specific user. That should solve the issue. (Note
that this means systemd --user will only work when run from
user@.service, as access to the cgroup tree is *not* granted for normal
sessions directly.)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] man: document the slice unit

2013-07-10 Thread Lennart Poettering

On Wed, 10.07.13 02:23, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 ---
 Does this description fit the masterplan? What about units that
 systemd will expose for CPU and BlockIO shares, will they still be
 1024 and 1000 based?

Yes, they will.

We probably should split the cgroup stuff out into a separate man page
systemd.cgroup or so, similar to the way we already have
systemd.exec and systemd.kill. Note that the cgroup properties are
not only available for slice units but also for service and scope units
(and mount, swap, socket, i.e. everything that forks of processes).

service, socket, swap, mount units all need to reference systemd.exec,
systemd.kill, systemd.cgroup.

scope units need to reference only systemd.kill and
systemd.cgroup. (they do not have any of the settings listed in
systemd.exec, since the processes they contain are created by somebody
else, and hence the settings cannot be applied anymore.)

slice units need to reference only systemd.cgroup. (they contain no
processes directly).

I figure both systemd.slice and systemd.scope will have very short man
pages...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] basic SO_REUSEPORT support

2013-07-10 Thread Lennart Poettering

On Wed, 10.07.13 15:44, Shawn (shawnland...@gmail.com) wrote:

 really fix ReUsePort capitalization

I fixed two more cases of ReUse. Also made the man page compile, fixed
a couple of other things and commited this.

Thanks,

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] man: document the slice unit

2013-07-10 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Jul 11, 2013 at 03:02:44AM +0200, Lennart Poettering wrote:
 On Wed, 10.07.13 02:23, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
 
  ---
  Does this description fit the masterplan? What about units that
  systemd will expose for CPU and BlockIO shares, will they still be
  1024 and 1000 based?
 
 Yes, they will.
Thanks, this clarifies things.

I think we could introduce additional syntax using %:
CPUShares=15%

This would fit nicely with https://bugzilla.redhat.com/show_bug.cgi?id=874631
(RFE: allow configuration of percentage values for disk space in journald.conf).

 We probably should split the cgroup stuff out into a separate man page
 systemd.cgroup
Yep.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] cgroups: chown user slices

2013-07-10 Thread Kok, Auke-jan H

On Wed, Jul 10, 2013 at 5:48 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Sat, 06.07.13 01:16, Marc-Antoine Perennou (marc-anto...@perennou.com) 
 wrote:

 When creating the cgroup hierarchy for a user slice,
 chown this slice to the user uid.

 Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
 ---
  src/shared/cgroup-label.c | 8 
  1 file changed, 8 insertions(+)

 diff --git a/src/shared/cgroup-label.c b/src/shared/cgroup-label.c
 index 574a7be..1891c9a 100644
 --- a/src/shared/cgroup-label.c
 +++ b/src/shared/cgroup-label.c
 @@ -41,6 +41,7 @@

  int cg_create(const char *controller, const char *path) {
  _cleanup_free_ char *fs = NULL;
 +uid_t uid = (uid_t) -1;
  int r;

  r = cg_get_path_and_check(controller, path, NULL, fs);
 @@ -59,6 +60,13 @@ int cg_create(const char *controller, const char *path) {
  return -errno;
  }

 +r = cg_path_get_owner_uid(path, uid);
 +if (r  0  r != -ENOENT)
 +return r;
 +
 +if (uid != (uid_t) -1)
 +chown(fs, uid, (gid_t) -1);
 +

 systemd in git will now grant access to the cgroup subtree in
 user@.service to the specific user. That should solve the issue. (Note
 that this means systemd --user will only work when run from
 user@.service, as access to the cgroup tree is *not* granted for normal
 sessions directly.)

can you elaborate what normal sessions are? Are we talking about
`PAMName=systemd-shared` being the part that distinguishes them?

Thanks,

Auke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] man: document the slice unit

[systemd-devel] [PATCH] core: notify triggered by socket of a service

Re: [systemd-devel] [PATCH] core: notify triggered by socket of a service

Re: [systemd-devel] journal and /run/systemd/journal/syslog

Re: [systemd-devel] journal and /run/systemd/journal/syslog

Re: [systemd-devel] journal and /run/systemd/journal/syslog

Re: [systemd-devel] [PATCH] core: notify triggered by socket of a service

Re: [systemd-devel] journald and kernel logging

Re: [systemd-devel] journald and kernel logging

[systemd-devel] no installed machine-id vs systemd-in-initramfs

[systemd-devel] Help getting serial console working again after upgrade to systemd?

[systemd-devel] Forward systemd's sleep.target to a systemd user session

[systemd-devel] update: udev keymaps are moving to hwdb

Re: [systemd-devel] [PATCH] basic SO_REUSEPORT support

Re: [systemd-devel] [PATCH] basic SO_REUSEPORT support

Re: [systemd-devel] [PATCH] basic SO_REUSEPORT support

Re: [systemd-devel] [PATCH] basic SO_REUSEPORT support

Re: [systemd-devel] [PATCH] cgroups: chown user slices

Re: [systemd-devel] [PATCH] man: document the slice unit

Re: [systemd-devel] [PATCH] basic SO_REUSEPORT support

Re: [systemd-devel] [PATCH] man: document the slice unit

Re: [systemd-devel] [PATCH] cgroups: chown user slices

22 matches

Site Navigation

Mail list logo

Footer information