date:20130410

On Wed, Apr 10, 2013 at 12:53:58PM +0200, Lukas Nykryn wrote:
> ---
>  src/journal/journalctl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
Applied 1/5, 3/5, 5/5.

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

Re: [systemd-devel] [PATCH 4/5] journal: close fd in sd_journal_send

On Wed, Apr 10, 2013 at 12:54:01PM +0200, Lukas Nykryn wrote:
> ---
>  src/journal/journal-send.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/journal/journal-send.c b/src/journal/journal-send.c
> index 4b9109a..ae7f5e8 100644
> --- a/src/journal/journal-send.c
> +++ b/src/journal/journal-send.c
> @@ -200,7 +200,9 @@ finish:
>  
>  _public_ int sd_journal_sendv(const struct iovec *iov, int n) {
>  PROTECT_ERRNO;
> -int fd, buffer_fd;
> +_cleanup_close_ int fd = -1;
> +int buffer_fd;
> +
journal_fd() returns a global resource, it shouldn't be closed.

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

Re: [systemd-devel] [PATCH 2/5] sd-id128: properly check position in buffer

On Wed, Apr 10, 2013 at 12:53:59PM +0200, Lukas Nykryn wrote:
> ---
>  src/libsystemd-id128/sd-id128.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/libsystemd-id128/sd-id128.c b/src/libsystemd-id128/sd-id128.c
> index 68c4987..a6345c8 100644
> --- a/src/libsystemd-id128/sd-id128.c
> +++ b/src/libsystemd-id128/sd-id128.c
> @@ -176,6 +176,9 @@ _public_ int sd_id128_get_boot(sd_id128_t *ret) {
>  if (*p == '-')
>  p++;
>  
> +if (p >= buf + k - 1)
> +return -EIO;
> +
Somethign like that is already in master. (There's only a difference of one
between the checks,  p >= buf + k - 1 or p >= buf + k. Both are correct.)

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

[systemd-devel] 70-persistent-net.rules

2013-04-10 Thread Reindl Harald

/usr/share/doc/systemd/README.Fedora-18

- A hacky workaround that allows udev to rename network interfaces into
  kernel's ethX namespace has been re-added. This is to support users who still
  rely on udev rules such as 70-persistent-net.rules generated in previous
  Fedora releases to name their network interfaces. Note that the workaround is
  only temporary and will go away in a future Fedora release
__

PLEASE DO NOT remove this mechanism

well, you are not creating it since a long time, BUT do not
stop use this config file if it is present!



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] [PATCH] Move bus_error to dbus-common and remove bus_error_message_or_strerror

2013-04-10 Thread Simon Peeters

bus_error and bus_error_message_or_strerror dit almost exactly the same,
so use only one of them and place it in dbus-common.
---
 src/core/bus-errors.h| 13 -
 src/core/load-fragment.c |  2 +-
 src/core/main.c  |  2 +-
 src/core/path.c  |  2 +-
 src/core/service.c   |  2 +-
 src/core/socket.c|  2 +-
 src/core/timer.c |  2 +-
 src/core/transaction.c   |  1 +
 src/login/inhibit.c  |  4 ++--
 src/login/logind-dbus.c  |  2 +-
 src/shared/dbus-common.c |  6 --
 src/shared/dbus-common.h |  2 +-
 12 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/src/core/bus-errors.h b/src/core/bus-errors.h
index 04c1b28..7a4084e 100644
--- a/src/core/bus-errors.h
+++ b/src/core/bus-errors.h
@@ -21,9 +21,6 @@
   along with systemd; If not, see .
 ***/
 
-#include 
-#include 
-
 #define BUS_ERROR_NO_SUCH_UNIT "org.freedesktop.systemd1.NoSuchUnit"
 #define BUS_ERROR_NO_SUCH_JOB "org.freedesktop.systemd1.NoSuchJob"
 #define BUS_ERROR_NOT_SUBSCRIBED "org.freedesktop.systemd1.NotSubscribed"
@@ -43,13 +40,3 @@
 #define BUS_ERROR_TRANSACTION_ORDER_IS_CYCLIC 
"org.freedesktop.systemd1.TransactionOrderIsCyclic"
 #define BUS_ERROR_SHUTTING_DOWN "org.freedesktop.systemd1.ShuttingDown"
 #define BUS_ERROR_NO_SUCH_PROCESS "org.freedesktop.systemd1.NoSuchProcess"
-
-static inline const char *bus_error(const DBusError *e, int r) {
-if (e && e->message)
-return e->message;
-
-if (r >= 0)
-return strerror(r);
-
-return strerror(-r);
-}
diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
index 42c181d..0f16fd9 100644
--- a/src/core/load-fragment.c
+++ b/src/core/load-fragment.c
@@ -44,7 +44,7 @@
 #include "missing.h"
 #include "unit-name.h"
 #include "unit-printf.h"
-#include "bus-errors.h"
+#include "dbus-common.h"
 #include "utf8.h"
 #include "path-util.h"
 #include "syscall-list.h"
diff --git a/src/core/main.c b/src/core/main.c
index 7899761..fe9932b 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -40,7 +40,7 @@
 #include "fdset.h"
 #include "special.h"
 #include "conf-parser.h"
-#include "bus-errors.h"
+#include "dbus-common.h"
 #include "missing.h"
 #include "label.h"
 #include "build.h"
diff --git a/src/core/path.c b/src/core/path.c
index ff49c06..b8ba057 100644
--- a/src/core/path.c
+++ b/src/core/path.c
@@ -31,7 +31,7 @@
 #include "mkdir.h"
 #include "dbus-path.h"
 #include "special.h"
-#include "bus-errors.h"
+#include "dbus-common.h"
 #include "path-util.h"
 #include "macro.h"
 
diff --git a/src/core/service.c b/src/core/service.c
index a104b30..cf19ccb 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -36,7 +36,7 @@
 #include "unit-printf.h"
 #include "dbus-service.h"
 #include "special.h"
-#include "bus-errors.h"
+#include "dbus-common.h"
 #include "exit-status.h"
 #include "def.h"
 #include "path-util.h"
diff --git a/src/core/socket.c b/src/core/socket.c
index f3cbe08..9f1af1e 100644
--- a/src/core/socket.c
+++ b/src/core/socket.c
@@ -46,7 +46,7 @@
 #include "dbus-socket.h"
 #include "missing.h"
 #include "special.h"
-#include "bus-errors.h"
+#include "dbus-common.h"
 #include "label.h"
 #include "exit-status.h"
 #include "def.h"
diff --git a/src/core/timer.c b/src/core/timer.c
index 16ca573..107dbb3 100644
--- a/src/core/timer.c
+++ b/src/core/timer.c
@@ -26,7 +26,7 @@
 #include "timer.h"
 #include "dbus-timer.h"
 #include "special.h"
-#include "bus-errors.h"
+#include "dbus-common.h"
 
 static const UnitActiveState state_translation_table[_TIMER_STATE_MAX] = {
 [TIMER_DEAD] = UNIT_INACTIVE,
diff --git a/src/core/transaction.c b/src/core/transaction.c
index 4a8d90e..610344e 100644
--- a/src/core/transaction.c
+++ b/src/core/transaction.c
@@ -24,6 +24,7 @@
 
 #include "transaction.h"
 #include "bus-errors.h"
+#include "dbus-common.h"
 
 static void transaction_unlink_job(Transaction *tr, Job *j, bool 
delete_dependencies);
 
diff --git a/src/login/inhibit.c b/src/login/inhibit.c
index 9cb321f..fbab42a 100644
--- a/src/login/inhibit.c
+++ b/src/login/inhibit.c
@@ -251,7 +251,7 @@ int main(int argc, char *argv[]) {
 
 r = print_inhibitors(bus, &error);
 if (r < 0) {
-log_error("Failed to list inhibitors: %s", 
bus_error_message_or_strerror(&error, -r));
+log_error("Failed to list inhibitors: %s", 
bus_error(&error, r));
 goto finish;
 }
 
@@ -266,7 +266,7 @@ int main(int argc, char *argv[]) {
 free(w);
 
 if (fd < 0) {
-log_error("Failed to inhibit: %s", 
bus_error_message_or_strerror(&error, -r));
+log_error("Failed to inhibit: %s", bus_error(&error, 
r));
 r = fd;
 goto finish;
 }
diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 230dd2b..bc46de7 100644
--- a/src

Re: [systemd-devel] Socket is dying, how to automatically restart it?

2013-04-10 Thread David Strauss

On Wed, Apr 10, 2013 at 1:20 PM, Kok, Auke-jan H
 wrote:
> actually, that's a good point, but if the "socket" unit is dead, I
> assume that systemd no longer is bind()ed to the ports...

I'd have to look at source or run some experiments for details, but I
know systemd's socket listeners can get into a funk when the
corresponding service is marked as failed.

--
David Strauss
   | da...@davidstrauss.net
   | +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Socket is dying, how to automatically restart it?

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

On Wed, Apr 10, 2013 at 1:12 PM, David Strauss  wrote:
> Are you sure it's not the corresponding service that really failed?

actually, that's a good point, but if the "socket" unit is dead, I
assume that systemd no longer is bind()ed to the ports...

Koen, can you verify that that is the case?

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

Re: [systemd-devel] Socket is dying, how to automatically restart it?

2013-04-10 Thread David Strauss

Are you sure it's not the corresponding service that really failed?

On Wed, Apr 10, 2013 at 11:46 AM, Kok, Auke-jan H
 wrote:
> On Wed, Apr 10, 2013 at 11:10 AM, Koen Kooi  
> wrote:
>>
>> Op 10 apr. 2013, om 19:13 heeft Mantas Mikulėnas  het 
>> volgende geschreven:
>>
>>> On Wed, Apr 10, 2013 at 8:03 PM, Koen Kooi  
>>> wrote:
 Hi,

 I have a bit of a heisenbug where dropbear.socket will just die and needs 
 a systemctl restart dropbear.socket. I can't tell why it's dying, just 
 that it does within 3 days of uptime. After restarting it it seems to be 
 rock solid again for at least some weeks.

 The real way to fix this is to find out why it dies,
>>>
>>> After death, does `systemctl status dropbear.socket` show any error
>>> messages in the status line?
>>
>> No, only that it's dead, so systemd knows that it's has failed somehow
>
> "dead" isn't necessarily the same as "failed"... and I wonder if you
> can use ExecStartPost= here to kick it - it's valid for [Socket]
> sections.
>
> Auke
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
David Strauss
   | da...@davidstrauss.net
   | +1 512 577 5827 [mobile]
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Socket is dying, how to automatically restart it?

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

On Wed, Apr 10, 2013 at 11:10 AM, Koen Kooi  wrote:
>
> Op 10 apr. 2013, om 19:13 heeft Mantas Mikulėnas  het 
> volgende geschreven:
>
>> On Wed, Apr 10, 2013 at 8:03 PM, Koen Kooi  
>> wrote:
>>> Hi,
>>>
>>> I have a bit of a heisenbug where dropbear.socket will just die and needs a 
>>> systemctl restart dropbear.socket. I can't tell why it's dying, just that 
>>> it does within 3 days of uptime. After restarting it it seems to be rock 
>>> solid again for at least some weeks.
>>>
>>> The real way to fix this is to find out why it dies,
>>
>> After death, does `systemctl status dropbear.socket` show any error
>> messages in the status line?
>
> No, only that it's dead, so systemd knows that it's has failed somehow

"dead" isn't necessarily the same as "failed"... and I wonder if you
can use ExecStartPost= here to kick it - it's valid for [Socket]
sections.

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

Re: [systemd-devel] Socket is dying, how to automatically restart it?

2013-04-10 Thread Koen Kooi


Op 10 apr. 2013, om 19:13 heeft Mantas Mikulėnas  het 
volgende geschreven:

> On Wed, Apr 10, 2013 at 8:03 PM, Koen Kooi  wrote:
>> Hi,
>> 
>> I have a bit of a heisenbug where dropbear.socket will just die and needs a 
>> systemctl restart dropbear.socket. I can't tell why it's dying, just that it 
>> does within 3 days of uptime. After restarting it it seems to be rock solid 
>> again for at least some weeks.
>> 
>> The real way to fix this is to find out why it dies,
> 
> After death, does `systemctl status dropbear.socket` show any error
> messages in the status line?

No, only that it's dead, so systemd knows that it's has failed somehow

regards,

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

Re: [systemd-devel] Socket is dying, how to automatically restart it?

2013-04-10 Thread Mantas Mikulėnas

On Wed, Apr 10, 2013 at 8:03 PM, Koen Kooi  wrote:
> Hi,
>
> I have a bit of a heisenbug where dropbear.socket will just die and needs a 
> systemctl restart dropbear.socket. I can't tell why it's dying, just that it 
> does within 3 days of uptime. After restarting it it seems to be rock solid 
> again for at least some weeks.
>
> The real way to fix this is to find out why it dies,

After death, does `systemctl status dropbear.socket` show any error
messages in the status line?

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

Re: [systemd-devel] Socket is dying, how to automatically restart it?

2013-04-10 Thread Jóhann B. Guðmundsson


On 04/10/2013 05:03 PM, Koen Kooi wrote:

Hi,

I have a bit of a heisenbug where dropbear.socket will just die and needs a 
systemctl restart dropbear.socket. I can't tell why it's dying, just that it 
does within 3 days of uptime. After restarting it it seems to be rock solid 
again for at least some weeks.

The real way to fix this is to find out why it dies, but till someone figures 
that out I'm looking to a way to automatically restart the socket when it 
fails, kinda like Restart=Always for services. Is such a thing possible? This 
is with 195 and 196, haven't tried 201 yet.



When tackling things like this it's properly better to use timer unit 
that checks it periodically if the service responds ( some times they 
are up but in weird state ) and restarts it if it fails


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

[systemd-devel] Socket is dying, how to automatically restart it?

2013-04-10 Thread Koen Kooi

Hi,

I have a bit of a heisenbug where dropbear.socket will just die and needs a 
systemctl restart dropbear.socket. I can't tell why it's dying, just that it 
does within 3 days of uptime. After restarting it it seems to be rock solid 
again for at least some weeks.

The real way to fix this is to find out why it dies, but till someone figures 
that out I'm looking to a way to automatically restart the socket when it 
fails, kinda like Restart=Always for services. Is such a thing possible? This 
is with 195 and 196, haven't tried 201 yet.

regards,

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

[systemd-devel] [PATCH V4] service: Support environment variable substition for PIDFile=

From: Harald Hoyer 

This patch adds environment variable substition for PIDFile=. To read
the environment files only once, ExecContext holds a copy of the
environment gathered.

RFE: https://bugzilla.redhat.com/show_bug.cgi?id=840260

$ cat test.service
[Unit]
Description=test

[Service]
PIDFile=${PIDFILE}
EnvironmentFile=/etc/test-file
ExecStart=/bin/bash -c 'sleep 1& jobs -p > $$PIDFILE; exit 0'
Type=forking

$ cat /etc/test-file
PIDFILE=/tmp/test.pid

$ systemctl status test.service
test.service - test
Loaded: loaded (/usr/lib/systemd/system/test.service; static)
   Active: active (running) since Mi 2013-04-10 15:06:42 CEST; 2s ago
  Process: 22407 ExecStart=/bin/bash -c sleep 1& jobs -p > $$PIDFILE; exit 
0 (code=exited, status=0/SUCCESS)
 Main PID: 22408 (sleep)
   CGroup: name=systemd:/system/test.service
   └─22408 sleep 1

Apr 10 15:06:42 lenovo systemd[1]: Started test.
---
 man/systemd.service.xml   |  3 +++
 src/core/execute.c| 11 +++---
 src/core/execute.h|  1 +
 src/core/load-fragment-gperf.gperf.m4 |  2 +-
 src/core/service.c| 38 ++-
 src/core/service.h|  1 +
 6 files changed, 47 insertions(+), 9 deletions(-)

diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index b82a5c1..14ce395 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -276,6 +276,9 @@
 the daemon after start-up of the
 service. systemd will not write to the
 file configured here.
+Basic environment variable
+substitution is supported like in
+ExecStart=.
 
 
 
diff --git a/src/core/execute.c b/src/core/execute.c
index fabd38e..1cf33f9 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -997,7 +997,6 @@ int exec_spawn(ExecCommand *command,
 int r;
 char *line;
 int socket_fd;
-char _cleanup_strv_free_ **files_env = NULL;
 
 assert(command);
 assert(context);
@@ -1018,7 +1017,10 @@ int exec_spawn(ExecCommand *command,
 } else
 socket_fd = -1;
 
-r = exec_context_load_environment(context, &files_env);
+strv_free(context->files_environment);
+context->files_environment = NULL;
+
+r = exec_context_load_environment(context, 
&context->files_environment);
 if (r < 0) {
 log_struct_unit(LOG_ERR,
unit_id,
@@ -1498,7 +1500,7 @@ int exec_spawn(ExecCommand *command,
environment,
our_env,
context->environment,
-   files_env,
+   context->files_environment,
pam_env,
NULL);
 if (!final_env) {
@@ -1619,6 +1621,9 @@ void exec_context_done(ExecContext *c, bool 
reloading_or_reexecuting) {
 strv_free(c->environment_files);
 c->environment_files = NULL;
 
+strv_free(c->files_environment);
+c->files_environment = NULL;
+
 for (l = 0; l < ELEMENTSOF(c->rlimit); l++) {
 free(c->rlimit[l]);
 c->rlimit[l] = NULL;
diff --git a/src/core/execute.h b/src/core/execute.h
index 3ce9221..1ba08a5 100644
--- a/src/core/execute.h
+++ b/src/core/execute.h
@@ -85,6 +85,7 @@ struct ExecCommand {
 struct ExecContext {
 char **environment;
 char **environment_files;
+char **files_environment;
 
 struct rlimit *rlimit[RLIMIT_NLIMITS];
 char *working_directory, *root_directory;
diff --git a/src/core/load-fragment-gperf.gperf.m4 
b/src/core/load-fragment-gperf.gperf.m4
index d5e579f..4592f3d 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -140,7 +140,7 @@ Unit.ConditionHost,  
config_parse_unit_condition_string, CONDITION_H
 Unit.ConditionACPower,   config_parse_unit_condition_string, 
CONDITION_AC_POWER,0
 Unit.ConditionNull,  config_parse_unit_condition_null,   0,
 0
 m4_dnl
-Service.PIDFile, config_parse_unit_path_printf,  0,
 offsetof(Service, pid_file)
+Service.PIDFile, config_parse_unit_string_printf,0,
 offsetof(Service, pid_file)
 Service.ExecStartPre,config_parse_exec,  
SERVICE_EXEC_START_PRE,offsetof(Service, exec_command)
 Service.ExecStart,   config_parse_exec,  
SERVICE_EXEC_START

[systemd-devel] [PATCH V3] service: Support environment variable substition for PIDFile=

From: Harald Hoyer 

This patch adds environment variable substition for PIDFile=. To read
the environment files only once, ExecContext holds a copy of the
environment gathered.

RFE: https://bugzilla.redhat.com/show_bug.cgi?id=840260

$ cat test.service
[Unit]
Description=test

[Service]
PIDFile=${PIDFILE}
EnvironmentFile=/etc/test-file
ExecStart=/bin/bash -c 'sleep 1& jobs -p > $$PIDFILE; exit 0'
Type=forking

$ cat /etc/test-file
PIDFILE=/tmp/test.pid

$ systemctl status test.service
test.service - test
Loaded: loaded (/usr/lib/systemd/system/test.service; static)
   Active: active (running) since Mi 2013-04-10 15:06:42 CEST; 2s ago
  Process: 22407 ExecStart=/bin/bash -c sleep 1& jobs -p > $$PIDFILE; exit 
0 (code=exited, status=0/SUCCESS)
 Main PID: 22408 (sleep)
   CGroup: name=systemd:/system/test.service
   └─22408 sleep 1

Apr 10 15:06:42 lenovo systemd[1]: Started test.
---
 man/systemd.service.xml   |  3 +++
 src/core/execute.c| 24 +++
 src/core/execute.h|  1 +
 src/core/load-fragment-gperf.gperf.m4 |  2 +-
 src/core/service.c| 45 +++
 src/core/service.h|  1 +
 6 files changed, 60 insertions(+), 16 deletions(-)

diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index b82a5c1..14ce395 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -276,6 +276,9 @@
 the daemon after start-up of the
 service. systemd will not write to the
 file configured here.
+Basic environment variable
+substitution is supported like in
+ExecStart=.
 
 
 
diff --git a/src/core/execute.c b/src/core/execute.c
index fabd38e..09fb49f 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -997,7 +997,6 @@ int exec_spawn(ExecCommand *command,
 int r;
 char *line;
 int socket_fd;
-char _cleanup_strv_free_ **files_env = NULL;
 
 assert(command);
 assert(context);
@@ -1018,14 +1017,16 @@ int exec_spawn(ExecCommand *command,
 } else
 socket_fd = -1;
 
-r = exec_context_load_environment(context, &files_env);
-if (r < 0) {
-log_struct_unit(LOG_ERR,
-   unit_id,
-   "MESSAGE=Failed to load environment files: %s", 
strerror(-r),
-   "ERRNO=%d", -r,
-   NULL);
-return r;
+if (!context->files_environment) {
+r = exec_context_load_environment(context, 
&context->files_environment);
+if (r < 0) {
+log_struct_unit(LOG_ERR,
+   unit_id,
+   "MESSAGE=Failed to load environment files: 
%s", strerror(-r),
+   "ERRNO=%d", -r,
+   NULL);
+return r;
+}
 }
 
 if (!argv)
@@ -1498,7 +1499,7 @@ int exec_spawn(ExecCommand *command,
environment,
our_env,
context->environment,
-   files_env,
+   context->files_environment,
pam_env,
NULL);
 if (!final_env) {
@@ -1619,6 +1620,9 @@ void exec_context_done(ExecContext *c, bool 
reloading_or_reexecuting) {
 strv_free(c->environment_files);
 c->environment_files = NULL;
 
+strv_free(c->files_environment);
+c->files_environment = NULL;
+
 for (l = 0; l < ELEMENTSOF(c->rlimit); l++) {
 free(c->rlimit[l]);
 c->rlimit[l] = NULL;
diff --git a/src/core/execute.h b/src/core/execute.h
index 3ce9221..1ba08a5 100644
--- a/src/core/execute.h
+++ b/src/core/execute.h
@@ -85,6 +85,7 @@ struct ExecCommand {
 struct ExecContext {
 char **environment;
 char **environment_files;
+char **files_environment;
 
 struct rlimit *rlimit[RLIMIT_NLIMITS];
 char *working_directory, *root_directory;
diff --git a/src/core/load-fragment-gperf.gperf.m4 
b/src/core/load-fragment-gperf.gperf.m4
index d5e579f..4592f3d 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -140,7 +140,7 @@ Unit.ConditionHost,  
config_parse_unit_condition_string, CONDITION_H
 Unit.ConditionACPower,   config_parse_unit_condition_string, 
CONDITION_AC_POWER,0
 Unit.ConditionNull,

Re: [systemd-devel] dbus user services using the session bus

2013-04-10 Thread Will Stephenson

On 03/04/13 18:48, Kok, Auke-jan H wrote:

On Wed, Apr 3, 2013 at 6:22 AM, Will Stephenson wrote:

I'm joining the flock of desktop people investigating using systemd to start a
desktop session. So far I've checked out user-session-units and have created
some more granular unit files that will do a native systemd start rather than
u-s-u's wrapper around the upstream start script.

As Tom asked, I'm interested in these changes as well - do you have
your code posted somewhere?

Sorry for the late response, but I wanted to get a bit further on.
Having found a bit more time for this project I've got things working.

https://github.com/wstephenson/klyde/tree/master/startup/kde-session-units

It uses cmake to configure the service files and that uses a cmake
module from libkde4-devel or equivalent, but if you don't want to
install that, you can simply sed the bits between @@ in the .service.in
files to the location of your KDE installation.

Then set systemdkde.target as default and away you go.

Also, you're saying there's a "start script" somewhere, can you tell
me what you mean by that?

http://quickgit.kde.org/?p=kde-workspace.git&a=blob&h=21c117492268db828990ee7cc232d991ee757126&hb=a7d0ef49cb7839d42646334459f1140ed32c0a41&f=startkde.cmake

startkde sets up the basic environment for a KDE session, but the start
of actual processes (kwin, kded, knotify, plasma, etc etc) is sequenced
by ksmserver and started by forking off of kdeinit/klauncher. The
startkde script just starts kdeinit and ksmserver.

More details here:
https://github.com/wstephenson/klyde/blob/master/startup/kde-session-units/DESIGN

I don't understand what you refer to by "wrapper", either. Technically
user-session-units doesn't wrap anything, it just provides straight
unit files. One of them is derivative of user@.service from systemd,
sure.

I meant that user-session-units' kde.service runs the startkde shell
script, which is a container for several other processes as described
above. For a native session I'd like to break all this out into unit files.

I'm stuck now, because I want to start a service with Type=dbus that puts a
service on the session bus, however, I can't see a way to specify the bus in
the unit file.

you can insert variables into the user session by `systemctl --user
set-environment DBUS_S`. This is the only way to globally assign a
dbus address to the session, but you'll have to do it before any
significant service runs in the first place, which includes before
dbus starts.

Tom was right, it Just Worked. The problem was elsewhere; because
kdeinit is started in a convoluted way that requires
RemainAfterExit=true to prevent systemd killing things that should
remain running.

The next step is to hand off as much of the complexity to systemd,
breaking up ksmserver into individual unit files.

I don't want to use dbus activation here to start the service as that invokes
the chicken-egg problem that the service in question (kdeinit) job is to start
all the processes that will be calling it via dbus later. Long term I would
like to do away with this and perform this task via systemd too, but Type=dbus
on the session bus seems like a valid use case that should work.

I see there's a way to get the dbus session bus address into systemd because of
the patch to fix this in user-session-units; would the right approach be to add
a BusInstance= field to service and use the provided session bus address when
watching for Type=dbus services that depend on user/dbus.service?

all of this stuff seems to work just fine with user-session-units - of
course the login/DM integration is wholly missing right now, but could
you start with user-session-units and make modifications to get where
you want?

That's what I started with, thanks. I've packaged it and its
dependencies here:
https://build.opensuse.org/project/show?project=home%3Awstephenson%3Aworkbench%3Asystemd

Will

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

Re: [systemd-devel] dbus user services using the session bus

2013-04-10 Thread Will Stephenson

Please disregard this, I pressed ctrl-enter by mistake. Full version to 
follow.


On 10/04/13 16:14, Will Stephenson wrote:

On 03/04/13 18:48, Kok, Auke-jan H wrote:
On Wed, Apr 3, 2013 at 6:22 AM, Will Stephenson  
wrote:
I'm joining the flock of desktop people investigating using systemd 
to start a desktop session.  So far I've checked out 
user-session-units and have created some more granular unit files 
that will do a native systemd start rather than u-s-u's wrapper 
around the upstream start script.

As Tom asked, I'm interested in these changes as well - do you have
your code posted somewhere?


I got a bit more time for this project and got things working.

https://github.com/wstephenson/klyde/tree/master/startup/kde-session-units 



Also, you're saying there's a "start script" somewhere, can you tell
me what you mean by that?


http://quickgit.kde.org/?p=kde-workspace.git&a=blob&h=21c117492268db828990ee7cc232d991ee757126&hb=a7d0ef49cb7839d42646334459f1140ed32c0a41&f=startkde.cmake 





I don't understand what you refer to by "wrapper", either. Technically
user-session-units doesn't wrap anything, it just provides straight
unit files. One of them is derivative of user@.service from systemd,
sure.

I meant that kde.service is a wrapper around the startkde shell script.


I'm stuck now, because I want to start a service with Type=dbus that 
puts a service on the session bus, however, I can't see a way to 
specify the bus in the unit file.

you can insert variables into the user session by `systemctl --user
set-environment DBUS_S`. This is the only way to globally assign a
dbus address to the session, but you'll have to do it before any
significant service runs in the first place, which includes before
dbus starts.

I don't want to use dbus activation here to start the service as 
that invokes the chicken-egg problem that the service in question 
(kdeinit) job is to start all the processes that will be calling it 
via dbus later. Long term I would like to do away with this and 
perform this task via systemd too, but Type=dbus on the session bus 
seems like a valid use case that should work.


I see there's a way to get the dbus session bus address into systemd 
because of the patch to fix this in user-session-units; would the 
right approach be to add a BusInstance= field to service and use the 
provided session bus address when watching for Type=dbus services 
that depend on user/dbus.service?

all of this stuff seems to work just fine with user-session-units - of
course the login/DM integration is wholly missing right now, but could
you start with user-session-units and make modifications to get where
you want?

Cheers,


Auke


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


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

Re: [systemd-devel] dbus user services using the session bus

2013-04-10 Thread Will Stephenson


On 03/04/13 18:48, Kok, Auke-jan H wrote:

On Wed, Apr 3, 2013 at 6:22 AM, Will Stephenson  wrote:

I'm joining the flock of desktop people investigating using systemd to start a 
desktop session.  So far I've checked out user-session-units and have created 
some more granular unit files that will do a native systemd start rather than 
u-s-u's wrapper around the upstream start script.

As Tom asked, I'm interested in these changes as well - do you have
your code posted somewhere?


I got a bit more time for this project and got things working.

https://github.com/wstephenson/klyde/tree/master/startup/kde-session-units


Also, you're saying there's a "start script" somewhere, can you tell
me what you mean by that?


http://quickgit.kde.org/?p=kde-workspace.git&a=blob&h=21c117492268db828990ee7cc232d991ee757126&hb=a7d0ef49cb7839d42646334459f1140ed32c0a41&f=startkde.cmake



I don't understand what you refer to by "wrapper", either. Technically
user-session-units doesn't wrap anything, it just provides straight
unit files. One of them is derivative of user@.service from systemd,
sure.

I meant that kde.service is a wrapper around the startkde shell script.



I'm stuck now, because I want to start a service with Type=dbus that puts a 
service on the session bus, however, I can't see a way to specify the bus in 
the unit file.

you can insert variables into the user session by `systemctl --user
set-environment DBUS_S`. This is the only way to globally assign a
dbus address to the session, but you'll have to do it before any
significant service runs in the first place, which includes before
dbus starts.


I don't want to use dbus activation here to start the service as that invokes 
the chicken-egg problem that the service in question (kdeinit) job is to start 
all the processes that will be calling it via dbus later. Long term I would 
like to do away with this and perform this task via systemd too, but Type=dbus 
on the session bus seems like a valid use case that should work.

I see there's a way to get the dbus session bus address into systemd because of 
the patch to fix this in user-session-units; would the right approach be to add 
a BusInstance= field to service and use the provided session bus address when 
watching for Type=dbus services that depend on user/dbus.service?

all of this stuff seems to work just fine with user-session-units - of
course the login/DM integration is wholly missing right now, but could
you start with user-session-units and make modifications to get where
you want?

Cheers,


Auke


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

[systemd-devel] [PATCH V2] service: Support environment variable substition for PIDFile=

From: Harald Hoyer 

RFE: https://bugzilla.redhat.com/show_bug.cgi?id=840260

$ cat test.service
[Unit]
Description=test

[Service]
PIDFile=${PIDFILE}
EnvironmentFile=/etc/test-file
ExecStart=/bin/bash -c 'sleep 1& jobs -p > $$PIDFILE; exit 0'
Type=forking

$ cat /etc/test-file
PIDFILE=/tmp/test.pid

$ systemctl status test.service
test.service - test
Loaded: loaded (/usr/lib/systemd/system/test.service; static)
   Active: active (running) since Mi 2013-04-10 15:06:42 CEST; 2s ago
  Process: 22407 ExecStart=/bin/bash -c sleep 1& jobs -p > $$PIDFILE; exit 
0 (code=exited, status=0/SUCCESS)
 Main PID: 22408 (sleep)
   CGroup: name=systemd:/system/test.service
   └─22408 sleep 1

Apr 10 15:06:42 lenovo systemd[1]: Started test.
---
 man/systemd.service.xml   |  3 +++
 src/core/load-fragment-gperf.gperf.m4 |  2 +-
 src/core/service.c| 27 ++-
 src/core/service.h|  1 +
 4 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index b82a5c1..14ce395 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -276,6 +276,9 @@
 the daemon after start-up of the
 service. systemd will not write to the
 file configured here.
+Basic environment variable
+substitution is supported like in
+ExecStart=.
 
 
 
diff --git a/src/core/load-fragment-gperf.gperf.m4 
b/src/core/load-fragment-gperf.gperf.m4
index d5e579f..4592f3d 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -140,7 +140,7 @@ Unit.ConditionHost,  
config_parse_unit_condition_string, CONDITION_H
 Unit.ConditionACPower,   config_parse_unit_condition_string, 
CONDITION_AC_POWER,0
 Unit.ConditionNull,  config_parse_unit_condition_null,   0,
 0
 m4_dnl
-Service.PIDFile, config_parse_unit_path_printf,  0,
 offsetof(Service, pid_file)
+Service.PIDFile, config_parse_unit_string_printf,0,
 offsetof(Service, pid_file)
 Service.ExecStartPre,config_parse_exec,  
SERVICE_EXEC_START_PRE,offsetof(Service, exec_command)
 Service.ExecStart,   config_parse_exec,  
SERVICE_EXEC_START,offsetof(Service, exec_command)
 Service.ExecStartPost,   config_parse_exec,  
SERVICE_EXEC_START_POST,   offsetof(Service, exec_command)
diff --git a/src/core/service.c b/src/core/service.c
index a104b30..fd4c183 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -275,6 +275,9 @@ static void service_done(Unit *u) {
 free(s->pid_file);
 s->pid_file = NULL;
 
+free(s->pid_file_env);
+s->pid_file_env = NULL;
+
 #ifdef HAVE_SYSV_COMPAT
 free(s->sysv_runlevels);
 s->sysv_runlevels = NULL;
@@ -703,7 +706,9 @@ static int service_load_sysv_path(Service *s, const char 
*path) {
 }
 
 free(s->pid_file);
+free(s->pid_file_env);
 s->pid_file = fn;
+s->pid_file_env = NULL;
 }
 
 } else if (state == DESCRIPTION) {
@@ -1376,18 +1381,27 @@ static int service_load_pid_file(Service *s, bool 
may_warn) {
 char _cleanup_free_ *k = NULL;
 int r;
 pid_t pid;
+char _cleanup_strv_free_ **context_env = NULL;
+char _cleanup_free_ *fe = NULL;
 
 assert(s);
 
 if (!s->pid_file)
 return -ENOENT;
 
-r = read_one_line_file(s->pid_file, &k);
+if (!s->pid_file_env)
+if (!exec_context_load_environment(&s->exec_context, 
&context_env))
+s->pid_file_env = replace_env(s->pid_file, 
context_env);
+
+if (!s->pid_file_env)
+s->pid_file_env = strdup(s->pid_file);
+
+r = read_one_line_file(s->pid_file_env, &k);
 if (r < 0) {
 if (may_warn)
 log_info_unit(UNIT(s)->id,
   "PID file %s not readable (yet?) after 
%s.",
-  s->pid_file, 
service_state_to_string(s->state));
+  s->pid_file_env, 
service_state_to_string(s->state));
 return r;
 }
 
@@ -1396,7 +1410,7 @@ static int service_load_pid_file(Service *s, bool 
may_warn) {
 if (may_warn)
 log_info_unit(UNIT(s)->id,

Re: [systemd-devel] [PATCH V4] core/execute.c: debug log final execve() with argv[]

2013-04-10 Thread Harald Hoyer

Am 10.04.2013 14:29, schrieb Lennart Poettering:
> On Wed, 10.04.13 11:51, har...@redhat.com (har...@redhat.com) wrote:
> 
>> From: Harald Hoyer 
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=772073
> 
> Well, at the top of exec_spawn() we actuallly already output this on
> debug level. Why do we need this twice?
> 

With actual argv[] arguments (requested in the bugzilla) ??

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

[systemd-devel] [PATCH] service: Support environment variable substition for PIDFile=

From: Harald Hoyer 

RFE: https://bugzilla.redhat.com/show_bug.cgi?id=840260

$ cat test.service
[Unit]
Description=test

[Service]
PIDFile=${PIDFILE}
EnvironmentFile=/etc/test-file
ExecStart=/bin/bash -c 'sleep 1& jobs -p > $$PIDFILE; exit 0'
Type=forking

$ cat /etc/test-file
PIDFILE=/tmp/test.pid

$ systemctl status test.service
test.service - test
Loaded: loaded (/usr/lib/systemd/system/test.service; static)
   Active: active (running) since Mi 2013-04-10 15:06:42 CEST; 2s ago
  Process: 22407 ExecStart=/bin/bash -c sleep 1& jobs -p > $$PIDFILE; exit 
0 (code=exited, status=0/SUCCESS)
 Main PID: 22408 (sleep)
   CGroup: name=systemd:/system/test.service
   └─22408 sleep 1

Apr 10 15:06:42 lenovo systemd[1]: Started test.
---
 man/systemd.service.xml   |  3 +++
 src/core/load-fragment-gperf.gperf.m4 |  2 +-
 src/core/service.c| 25 -
 src/core/service.h|  1 +
 4 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index b82a5c1..14ce395 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -276,6 +276,9 @@
 the daemon after start-up of the
 service. systemd will not write to the
 file configured here.
+Basic environment variable
+substitution is supported like in
+ExecStart=.
 
 
 
diff --git a/src/core/load-fragment-gperf.gperf.m4 
b/src/core/load-fragment-gperf.gperf.m4
index d5e579f..4592f3d 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -140,7 +140,7 @@ Unit.ConditionHost,  
config_parse_unit_condition_string, CONDITION_H
 Unit.ConditionACPower,   config_parse_unit_condition_string, 
CONDITION_AC_POWER,0
 Unit.ConditionNull,  config_parse_unit_condition_null,   0,
 0
 m4_dnl
-Service.PIDFile, config_parse_unit_path_printf,  0,
 offsetof(Service, pid_file)
+Service.PIDFile, config_parse_unit_string_printf,0,
 offsetof(Service, pid_file)
 Service.ExecStartPre,config_parse_exec,  
SERVICE_EXEC_START_PRE,offsetof(Service, exec_command)
 Service.ExecStart,   config_parse_exec,  
SERVICE_EXEC_START,offsetof(Service, exec_command)
 Service.ExecStartPost,   config_parse_exec,  
SERVICE_EXEC_START_POST,   offsetof(Service, exec_command)
diff --git a/src/core/service.c b/src/core/service.c
index a104b30..0de8f20 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -275,6 +275,9 @@ static void service_done(Unit *u) {
 free(s->pid_file);
 s->pid_file = NULL;
 
+free(s->pid_file_env);
+s->pid_file_env = NULL;
+
 #ifdef HAVE_SYSV_COMPAT
 free(s->sysv_runlevels);
 s->sysv_runlevels = NULL;
@@ -703,7 +706,9 @@ static int service_load_sysv_path(Service *s, const char 
*path) {
 }
 
 free(s->pid_file);
+free(s->pid_file_env);
 s->pid_file = fn;
+s->pid_file_env = NULL;
 }
 
 } else if (state == DESCRIPTION) {
@@ -1376,18 +1381,27 @@ static int service_load_pid_file(Service *s, bool 
may_warn) {
 char _cleanup_free_ *k = NULL;
 int r;
 pid_t pid;
+char _cleanup_strv_free_ **context_env = NULL;
+char _cleanup_free_ *fe = NULL;
 
 assert(s);
 
 if (!s->pid_file)
 return -ENOENT;
 
-r = read_one_line_file(s->pid_file, &k);
+if (!s->pid_file_env)
+if (!exec_context_load_environment(&s->exec_context, 
&context_env))
+s->pid_file_env = replace_env(s->pid_file, 
context_env);
+
+if (!s->pid_file_env)
+s->pid_file_env = strdup(s->pid_file);
+
+r = read_one_line_file(s->pid_file_env, &k);
 if (r < 0) {
 if (may_warn)
 log_info_unit(UNIT(s)->id,
   "PID file %s not readable (yet?) after 
%s.",
-  s->pid_file, 
service_state_to_string(s->state));
+  s->pid_file_env, 
service_state_to_string(s->state));
 return r;
 }
 
@@ -1396,7 +1410,7 @@ static int service_load_pid_file(Service *s, bool 
may_warn) {
 if (may_warn)
 log_info_unit(UNIT(s)->id,

Re: [systemd-devel] [PATCH] systemctl: clarify usage of "--all" versus list-unit-files

On Wed, Apr 10, 2013 at 12:34:43PM +0200, har...@redhat.com wrote:
> From: Harald Hoyer 
> 
> Novice users might think, that
>  $ systemctl --all
> is equal to
>  $ systemctl list-unit-files
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=748512
Makes sense.

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

Re: [systemd-devel] [PATCH V4] core/execute.c: debug log final execve() with argv[]

2013-04-10 Thread Lennart Poettering

On Wed, 10.04.13 11:51, har...@redhat.com (har...@redhat.com) wrote:

> From: Harald Hoyer 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=772073

Well, at the top of exec_spawn() we actuallly already output this on
debug level. Why do we need this twice?

> ---
>  src/core/execute.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/src/core/execute.c b/src/core/execute.c
> index 5083af9..fabd38e 100644
> --- a/src/core/execute.c
> +++ b/src/core/execute.c
> @@ -1516,6 +1516,18 @@ int exec_spawn(ExecCommand *command,
>  
>  final_env = strv_env_clean(final_env);
>  
> +if (_unlikely_(log_get_max_level() >= LOG_PRI(LOG_DEBUG))) {
> +char _cleanup_free_ *argvs = NULL;
> +log_open();
> +argvs = strv_join(&final_argv[1], " ");
> +log_struct_unit(LOG_DEBUG,
> +unit_id,
> +"EXECUTABLE=%s", command->path,
> +"MESSAGE=Executing: %s %s",
> +command->path, argvs,
> +NULL);
> +log_close();
> +}
>  execve(command->path, final_argv, final_env);
>  err = -errno;
>  r = EXIT_EXEC;


Lennart

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

[systemd-devel] [PATCH 5/5] libsystemd-bus: initalize handle_cmsg to false

---
 src/libsystemd-bus/bus-socket.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/libsystemd-bus/bus-socket.c b/src/libsystemd-bus/bus-socket.c
index 145f454..1a0d926 100644
--- a/src/libsystemd-bus/bus-socket.c
+++ b/src/libsystemd-bus/bus-socket.c
@@ -877,7 +877,7 @@ int bus_socket_read_message(sd_bus *bus, sd_bus_message 
**m) {
 CMSG_SPACE(NAME_MAX)]; /*selinux label */
 } control;
 struct cmsghdr *cmsg;
-bool handle_cmsg;
+bool handle_cmsg = false;
 
 assert(bus);
 assert(m);
-- 
1.8.1.4

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

[systemd-devel] [PATCH 4/5] journal: close fd in sd_journal_send

---
 src/journal/journal-send.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/journal/journal-send.c b/src/journal/journal-send.c
index 4b9109a..ae7f5e8 100644
--- a/src/journal/journal-send.c
+++ b/src/journal/journal-send.c
@@ -200,7 +200,9 @@ finish:
 
 _public_ int sd_journal_sendv(const struct iovec *iov, int n) {
 PROTECT_ERRNO;
-int fd, buffer_fd;
+_cleanup_close_ int fd = -1;
+int buffer_fd;
+
 struct iovec *w;
 uint64_t *l;
 int i, j = 0;
-- 
1.8.1.4

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

[systemd-devel] [PATCH 3/5] tty-ask-password-agent: free passwords

---
 src/tty-ask-password-agent/tty-ask-password-agent.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/tty-ask-password-agent/tty-ask-password-agent.c 
b/src/tty-ask-password-agent/tty-ask-password-agent.c
index 3f5706e..1f55e32 100644
--- a/src/tty-ask-password-agent/tty-ask-password-agent.c
+++ b/src/tty-ask-password-agent/tty-ask-password-agent.c
@@ -339,7 +339,7 @@ static int parse_password(const char *filename, char 
**wall) {
 }
 
 if (arg_plymouth) {
-char **passwords = NULL;
+_cleanup_strv_free_ char **passwords = NULL;
 
 if ((r = ask_password_plymouth(message, not_after, 
filename, accept_cached, &passwords)) >= 0) {
 char **p;
-- 
1.8.1.4

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

[systemd-devel] [PATCH 2/5] sd-id128: properly check position in buffer

---
 src/libsystemd-id128/sd-id128.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/libsystemd-id128/sd-id128.c b/src/libsystemd-id128/sd-id128.c
index 68c4987..a6345c8 100644
--- a/src/libsystemd-id128/sd-id128.c
+++ b/src/libsystemd-id128/sd-id128.c
@@ -176,6 +176,9 @@ _public_ int sd_id128_get_boot(sd_id128_t *ret) {
 if (*p == '-')
 p++;
 
+if (p >= buf + k - 1)
+return -EIO;
+
 a = unhexchar(p[0]);
 b = unhexchar(p[1]);
 
-- 
1.8.1.4

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

[systemd-devel] [PATCH 1/5] journalctl: check return of strjoin

---
 src/journal/journalctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 86895b8..002ff7c 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -1035,7 +1035,7 @@ int main(int argc, char *argv[]) {
 char _cleanup_free_ *copy = NULL;
 if (arg_root) {
 copy = strjoin(arg_root, "/", CATALOG_DATABASE, NULL);
-if (!database) {
+if (!copy) {
 r = log_oom();
 goto finish;
 }
-- 
1.8.1.4

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

[systemd-devel] [PATCH] systemctl: clarify usage of "--all" versus list-unit-files

From: Harald Hoyer 

Novice users might think, that
 $ systemctl --all
is equal to
 $ systemctl list-unit-files

https://bugzilla.redhat.com/show_bug.cgi?id=748512
---
 man/systemctl.xml | 4 +++-
 src/systemctl/systemctl.c | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/man/systemctl.xml b/man/systemctl.xml
index 5656564..053d25c 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -132,10 +132,12 @@ along with systemd; If not, see 
.
 --all
 
 
-  When listing units, show all units, regardless of
+  When listing units, show all internally loaded units, 
regardless of
   their state, including inactive units. When showing
   unit/job/manager properties, show all properties regardless
   whether they are set or not.
+  To list all units installed on disk, use the command
+  list-unit-files instead.
 
   
 
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index fd9f580..3373b88 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4147,7 +4147,9 @@ static int systemctl_help(void) {
" --versionShow package version\n"
"  -t --type=TYPE  List only units of a particular type\n"
"  -p --property=NAME  Show only properties by this name\n"
-   "  -a --allShow all units/properties, including 
dead/empty ones\n"
+   "  -a --allShow all internally loaded 
units/properties,\n"
+   "  including dead/empty ones. To list all 
units installed\n"
+   "  on disk, use the command 
'list-unit-files' instead.\n"
" --failed Show only failed units\n"
" --full   Don't ellipsize unit names on output\n"
" --fail   When queueing a new job, fail if 
conflicting jobs are\n"
-- 
1.8.2

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

Re: [systemd-devel] Systemd and cgroups

2013-04-10 Thread Daniel P. Berrange

On Wed, Apr 10, 2013 at 12:43:56PM +0300, Kevin Wilson wrote:
> Hello,
> I have a question about systemd and cgroups:
> "mount | grep cgroups" shows that only one entry has name=systemd.
> and is mounted on /sys/fs/cgroup/systemd . (see below the full output
> of "mount | grep cgroups"
> 
> Is it true that all other cgroup entry shown by "mount | grep cgroups"
> were not mounted by systemd (and may be unmounted without directly
> causing problems is systemd)?

If some 3rd party application has mounted cgroups controllers before
systemd starts, it will honour that setup. If they were not already
mounted, then systemd itself will mount all the resource controllers
that are compiled into the kernel.

Systemd will only actually create sub-dirs in those controllers
that are listed in the 'DefaultControllers' setting of systemd.conf,
which defaults to 'cpu'.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH V3] core/execute.c: debug log final execve() with argv[]

2013-04-10 Thread Harald Hoyer

Am 10.04.2013 11:49, schrieb har...@redhat.com:
> From: Harald Hoyer 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=772073
> ---
>  src/core/execute.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/src/core/execute.c b/src/core/execute.c
> index 5083af9..c881e56 100644
> --- a/src/core/execute.c
> +++ b/src/core/execute.c
> @@ -1516,6 +1516,16 @@ int exec_spawn(ExecCommand *command,
>  
>  final_env = strv_env_clean(final_env);
>  
> +if (_unlikely_(log_get_max_level() >= LOG_PRI(LOG_DEBUG))) {
> +log_open();
> +log_struct_unit(LOG_DEBUG,
> +unit_id,
> +"EXECUTABLE=%s", command->path,
> +"MESSAGE=Executing: %s %s",
> +command->path, 
> strv_join(&final_argv[1], " "),
> +NULL);
> +log_close();
> +}
>  execve(command->path, final_argv, final_env);
>  err = -errno;
>  r = EXIT_EXEC;
> 

-ENOCOFFEE... sorry for the spam :-)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH V4] core/execute.c: debug log final execve() with argv[]

From: Harald Hoyer 

https://bugzilla.redhat.com/show_bug.cgi?id=772073
---
 src/core/execute.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/src/core/execute.c b/src/core/execute.c
index 5083af9..fabd38e 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1516,6 +1516,18 @@ int exec_spawn(ExecCommand *command,
 
 final_env = strv_env_clean(final_env);
 
+if (_unlikely_(log_get_max_level() >= LOG_PRI(LOG_DEBUG))) {
+char _cleanup_free_ *argvs = NULL;
+log_open();
+argvs = strv_join(&final_argv[1], " ");
+log_struct_unit(LOG_DEBUG,
+unit_id,
+"EXECUTABLE=%s", command->path,
+"MESSAGE=Executing: %s %s",
+command->path, argvs,
+NULL);
+log_close();
+}
 execve(command->path, final_argv, final_env);
 err = -errno;
 r = EXIT_EXEC;
-- 
1.8.2

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

[systemd-devel] [PATCH V3] core/execute.c: debug log final execve() with argv[]

From: Harald Hoyer 

https://bugzilla.redhat.com/show_bug.cgi?id=772073
---
 src/core/execute.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/core/execute.c b/src/core/execute.c
index 5083af9..c881e56 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1516,6 +1516,16 @@ int exec_spawn(ExecCommand *command,
 
 final_env = strv_env_clean(final_env);
 
+if (_unlikely_(log_get_max_level() >= LOG_PRI(LOG_DEBUG))) {
+log_open();
+log_struct_unit(LOG_DEBUG,
+unit_id,
+"EXECUTABLE=%s", command->path,
+"MESSAGE=Executing: %s %s",
+command->path, 
strv_join(&final_argv[1], " "),
+NULL);
+log_close();
+}
 execve(command->path, final_argv, final_env);
 err = -errno;
 r = EXIT_EXEC;
-- 
1.8.2

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

[systemd-devel] [PATCH V2] core/execute.c: debug log final execve() with argv[]

From: Harald Hoyer 

https://bugzilla.redhat.com/show_bug.cgi?id=772073
---
 src/core/execute.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/core/execute.c b/src/core/execute.c
index 5083af9..c881e56 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -1516,6 +1516,16 @@ int exec_spawn(ExecCommand *command,
 
 final_env = strv_env_clean(final_env);
 
+if (_unlikely_(log_get_max_level() >= LOG_PRI(LOG_DEBUG))) {
+log_open();
+log_struct_unit(LOG_DEBUG,
+unit_id,
+"EXECUTABLE=%s", command->path,
+"MESSAGE=Executing: %s %s",
+command->path, 
strv_join(&final_argv[1], " "),
+NULL);
+log_close();
+}
 execve(command->path, final_argv, final_env);
 err = -errno;
 r = EXIT_EXEC;
-- 
1.8.2

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

[systemd-devel] Systemd and cgroups

2013-04-10 Thread Kevin Wilson

Hello,
I have a question about systemd and cgroups:
"mount | grep cgroups" shows that only one entry has name=systemd.
and is mounted on /sys/fs/cgroup/systemd . (see below the full output
of "mount | grep cgroups"

Is it true that all other cgroup entry shown by "mount | grep cgroups"
were not mounted by systemd (and may be unmounted without directly
causing problems is systemd)?

tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup
(rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup
(rw,nosuid,nodev,noexec,relatime,perf_event)

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

[systemd-devel] [PATCH] core/execute.c: debug log final execve() with argv[]