Re: [systemd-devel] [PATCH 1/2] bus-util: add ssh and polkit connection methods
2013/10/30 Simon Peeters :
> bus_connect_system_ssh is shamelessly copied from Tom Gundersen's wip
> patches
Aparently i am 3 hours late to the party, so only the polkit part from
this patch is needed
> ---
> src/libsystemd-bus/bus-util.c | 61
> +++
> src/libsystemd-bus/bus-util.h | 2 ++
> 2 files changed, 63 insertions(+)
>
> diff --git a/src/libsystemd-bus/bus-util.c b/src/libsystemd-bus/bus-util.c
> index 42374fe..464e5fb 100644
> --- a/src/libsystemd-bus/bus-util.c
> +++ b/src/libsystemd-bus/bus-util.c
> @@ -450,3 +450,64 @@ int bus_connect_system(sd_bus **_bus) {
> *_bus = bus;
> return 0;
> }
> +
> +int bus_connect_system_ssh(const char *host, sd_bus **_bus) {
> +sd_bus *bus;
> +char *p = NULL;
> +int r;
> +
> +assert(_bus);
> +assert(host);
> +
> +asprintf(&p,
> "unixexec:path=ssh,argv1=-xT,argv2=%s,argv3=systemd-stdio-bridge", host);
> +if (!p)
> +return -ENOMEM;
> +
> +r = sd_bus_new(&bus);
> +if (r < 0)
> +return r;
> +
> +r = sd_bus_set_address(bus, p);
> +if (r < 0)
> +return r;
> +
> +r = sd_bus_set_bus_client(bus, true);
> +if (r < 0)
> +return r;
> +
> +r = sd_bus_start(bus);
> +if (r < 0)
> +return r;
> +
> +*_bus = bus;
> +return 0;
> +}
> +
> +int bus_connect_system_polkit(sd_bus **_bus) {
> +sd_bus *bus;
> +int r;
> +
> +assert(_bus);
> +
> +if (geteuid() == 0)
> +return sd_bus_open_system(_bus);
> +
> +r = sd_bus_new(&bus);
> +if (r < 0)
> +return r;
> +
> +r = sd_bus_set_address(bus, "unixexec:path=pkexec,argv1="
> SYSTEMD_STDIO_BRIDGE_BINARY_PATH);
> +if (r < 0)
> +return r;
> +
> +r = sd_bus_set_bus_client(bus, true);
> +if (r < 0)
> +return r;
> +
> +r = sd_bus_start(bus);
> +if (r < 0)
> +return r;
> +
> +*_bus = bus;
> +return 0;
> +}
> diff --git a/src/libsystemd-bus/bus-util.h b/src/libsystemd-bus/bus-util.h
> index cf00436..92df3c2 100644
> --- a/src/libsystemd-bus/bus-util.h
> +++ b/src/libsystemd-bus/bus-util.h
> @@ -38,6 +38,8 @@ int bus_verify_polkit_async(sd_bus *bus, Hashmap
> **registry, sd_bus_message *m,
> void bus_verify_polkit_async_registry_free(sd_bus *bus, Hashmap *registry);
>
> int bus_connect_system(sd_bus **_bus);
> +int bus_connect_system_ssh(const char *host, sd_bus **_bus);
> +int bus_connect_system_polkit(sd_bus **_bus);
>
> DEFINE_TRIVIAL_CLEANUP_FUNC(sd_bus*, sd_bus_unref);
> DEFINE_TRIVIAL_CLEANUP_FUNC(sd_bus_message*, sd_bus_message_unref);
> --
> 1.8.4.2
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] bus-util: add ssh and polkit connection methods
bus_connect_system_ssh is shamelessly copied from Tom Gundersen's wip
patches
---
src/libsystemd-bus/bus-util.c | 61 +++
src/libsystemd-bus/bus-util.h | 2 ++
2 files changed, 63 insertions(+)
diff --git a/src/libsystemd-bus/bus-util.c b/src/libsystemd-bus/bus-util.c
index 42374fe..464e5fb 100644
--- a/src/libsystemd-bus/bus-util.c
+++ b/src/libsystemd-bus/bus-util.c
@@ -450,3 +450,64 @@ int bus_connect_system(sd_bus **_bus) {
*_bus = bus;
return 0;
}
+
+int bus_connect_system_ssh(const char *host, sd_bus **_bus) {
+sd_bus *bus;
+char *p = NULL;
+int r;
+
+assert(_bus);
+assert(host);
+
+asprintf(&p,
"unixexec:path=ssh,argv1=-xT,argv2=%s,argv3=systemd-stdio-bridge", host);
+if (!p)
+return -ENOMEM;
+
+r = sd_bus_new(&bus);
+if (r < 0)
+return r;
+
+r = sd_bus_set_address(bus, p);
+if (r < 0)
+return r;
+
+r = sd_bus_set_bus_client(bus, true);
+if (r < 0)
+return r;
+
+r = sd_bus_start(bus);
+if (r < 0)
+return r;
+
+*_bus = bus;
+return 0;
+}
+
+int bus_connect_system_polkit(sd_bus **_bus) {
+sd_bus *bus;
+int r;
+
+assert(_bus);
+
+if (geteuid() == 0)
+return sd_bus_open_system(_bus);
+
+r = sd_bus_new(&bus);
+if (r < 0)
+return r;
+
+r = sd_bus_set_address(bus, "unixexec:path=pkexec,argv1="
SYSTEMD_STDIO_BRIDGE_BINARY_PATH);
+if (r < 0)
+return r;
+
+r = sd_bus_set_bus_client(bus, true);
+if (r < 0)
+return r;
+
+r = sd_bus_start(bus);
+if (r < 0)
+return r;
+
+*_bus = bus;
+return 0;
+}
diff --git a/src/libsystemd-bus/bus-util.h b/src/libsystemd-bus/bus-util.h
index cf00436..92df3c2 100644
--- a/src/libsystemd-bus/bus-util.h
+++ b/src/libsystemd-bus/bus-util.h
@@ -38,6 +38,8 @@ int bus_verify_polkit_async(sd_bus *bus, Hashmap **registry,
sd_bus_message *m,
void bus_verify_polkit_async_registry_free(sd_bus *bus, Hashmap *registry);
int bus_connect_system(sd_bus **_bus);
+int bus_connect_system_ssh(const char *host, sd_bus **_bus);
+int bus_connect_system_polkit(sd_bus **_bus);
DEFINE_TRIVIAL_CLEANUP_FUNC(sd_bus*, sd_bus_unref);
DEFINE_TRIVIAL_CLEANUP_FUNC(sd_bus_message*, sd_bus_message_unref);
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] hostnamectl: port to sd-bus
---
Makefile.am | 5 +-
src/hostname/hostnamectl.c| 335 --
src/libsystemd-bus/bus-util.h | 40 +
src/shared/macro.h| 3 +
4 files changed, 142 insertions(+), 241 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 8d1e85d..088689d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3515,12 +3515,11 @@ hostnamectl_SOURCES = \
src/hostname/hostnamectl.c
hostnamectl_CFLAGS = \
- $(AM_CFLAGS) \
- $(DBUS_CFLAGS)
+ $(AM_CFLAGS)
hostnamectl_LDADD = \
libsystemd-shared.la \
- libsystemd-dbus.la \
+ libsystemd-bus.la \
libsystemd-id128-internal.la
bin_PROGRAMS += \
diff --git a/src/hostname/hostnamectl.c b/src/hostname/hostnamectl.c
index c6d72b5..a087ac7 100644
--- a/src/hostname/hostnamectl.c
+++ b/src/hostname/hostnamectl.c
@@ -28,7 +28,10 @@
#include
#include
-#include "dbus-common.h"
+#include "sd-bus.h"
+
+#include "bus-util.h"
+#include "bus-error.h"
#include "util.h"
#include "spawn-polkit-agent.h"
#include "build.h"
@@ -50,16 +53,6 @@ static bool arg_transient = false;
static bool arg_pretty = false;
static bool arg_static = false;
-static void polkit_agent_open_if_enabled(void) {
-
-/* Open the polkit agent as a child process if necessary */
-
-if (!arg_ask_password)
-return;
-
-polkit_agent_open();
-}
-
typedef struct StatusInfo {
const char *hostname;
const char *static_hostname;
@@ -125,139 +118,77 @@ static void print_status_info(StatusInfo *i) {
}
-static int status_property(const char *name, DBusMessageIter *iter, StatusInfo
*i) {
-assert(name);
-assert(iter);
-
-switch (dbus_message_iter_get_arg_type(iter)) {
-
-case DBUS_TYPE_STRING: {
-const char *s;
-
-dbus_message_iter_get_basic(iter, &s);
-if (!isempty(s)) {
-if (streq(name, "Hostname"))
-i->hostname = s;
-if (streq(name, "StaticHostname"))
-i->static_hostname = s;
-if (streq(name, "PrettyHostname"))
-i->pretty_hostname = s;
-if (streq(name, "IconName"))
-i->icon_name = s;
-if (streq(name, "Chassis"))
-i->chassis = s;
-}
-break;
-}
-}
-
-return 0;
-}
-
-static int show_one_name(DBusConnection *bus, const char* attr) {
-_cleanup_dbus_message_unref_ DBusMessage *reply = NULL;
-const char *interface = "org.freedesktop.hostname1", *s;
-DBusMessageIter iter, sub;
+static int show_one_name(sd_bus *bus, const char* attr) {
+_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
+_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+const char *s;
int r;
-r = bus_method_call_with_reply(
+r = sd_bus_get_property(
bus,
"org.freedesktop.hostname1",
"/org/freedesktop/hostname1",
-"org.freedesktop.DBus.Properties",
-"Get",
-&reply,
-NULL,
-DBUS_TYPE_STRING, &interface,
-DBUS_TYPE_STRING, &attr,
-DBUS_TYPE_INVALID);
-if (r < 0)
+"org.freedesktop.hostname1",
+attr,
+&error, &reply, "s");
+if (r < 0) {
+log_error("Could not get property: %s",
bus_error_message(&error, -r));
return r;
-
-if (!dbus_message_iter_init(reply, &iter) ||
-dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_VARIANT) {
-log_error("Failed to parse reply.");
-return -EIO;
}
-dbus_message_iter_recurse(&iter, &sub);
-
-if (dbus_message_iter_get_arg_type(&sub) != DBUS_TYPE_STRING) {
-log_error("Failed to parse reply.");
-return -EIO;
-}
+r = sd_bus_message_read(reply, "s", &s);
+if (r < 0)
+return r;
-dbus_message_iter_get_basic(&sub, &s);
printf("%s\n", s);
return 0;
}
-static int show_all_names(DBusConnection *bus) {
-_cleanup_dbus_message_unref_ DBusMessage *reply = NULL;
-const char *interface = "";
-int r;
-DBusMessageIter iter, sub, sub2, sub3;
-StatusInfo info = {};
+static int show_all_names(sd_bus *bus) {
+_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
+StatusInfo i = {};
+cons
Re: [systemd-devel] tree-wide conversion from libdbus to libsystemd-bus
sorry for te confusion in my previous mail, i meant: "I'll take a shot at hostnamectl (probably loginctl afterwards)" and my hostnamectl patches are actualy just finished (i will mail them in a couple of minutes) Simon 2013/10/30 Marc-Antoine Perennou : > On 30 October 2013 11:48, Kay Sievers wrote: >> On Wed, Oct 23, 2013 at 1:22 AM, Kay Sievers wrote: >> >> [update] >> >>> To avoid any duplication of work, here are the tools which still need >>> conversion. Please reply to this mail, in case you decide to work on >>> anything in that area. >> >> - timedatectl >> >> - systemd-logind >> >> - loginctl >> Peeters Simon: "I'll take ... (probably loginctl afterwards)" >> >> - localectl >> Kay will do that next >> >> - hostnamectl >> >> - pam_systemd >>Zbigniew: "I'll do pam_systemd" >> >> - systemctl >> >> - systemd >> ___ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/systemd-devel > > I have some work in progress for hostnamectl > ___ > 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] tree-wide conversion from libdbus to libsystemd-bus
On 30 October 2013 11:48, Kay Sievers wrote: > On Wed, Oct 23, 2013 at 1:22 AM, Kay Sievers wrote: > > [update] > >> To avoid any duplication of work, here are the tools which still need >> conversion. Please reply to this mail, in case you decide to work on >> anything in that area. > > - timedatectl > > - systemd-logind > > - loginctl > Peeters Simon: "I'll take ... (probably loginctl afterwards)" > > - localectl > Kay will do that next > > - hostnamectl > > - pam_systemd >Zbigniew: "I'll do pam_systemd" > > - systemctl > > - systemd > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel I have some work in progress for hostnamectl ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] .libs/test-sched-prio failed
Hi: I am running the systemd test cases, but .libs/test-sched-prio always failed, whether I put sched_idle_ok.service to anywhere, who can help me? thanks .libs/test-sched-prio Assertion 'idle_ok->load_state == UNIT_LOADED' failed at src/test/test-sched-prio.c:47, function main(). Aborting. Aborted -Roy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tree-wide conversion from libdbus to libsystemd-bus
On Wed, Oct 23, 2013 at 1:22 AM, Kay Sievers wrote: [update] > To avoid any duplication of work, here are the tools which still need > conversion. Please reply to this mail, in case you decide to work on > anything in that area. - timedatectl - systemd-logind - loginctl Peeters Simon: "I'll take ... (probably loginctl afterwards)" - localectl Kay will do that next - hostnamectl - pam_systemd Zbigniew: "I'll do pam_systemd" - systemctl - systemd ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
Am 29.10.2013 17:52, schrieb Kay Sievers: >> None of this explains why systemd no longer applies certain controllers >> by default. Previously, systemd would attach cpu controllers to each >> service by default. Now, it only groups your processes in the systemd >> tree, but does not touch any cgroup controllers. >> >> The new default behaviour (or lack thereof) seems like a step back to me. > > It's a property of a unit now which cgroup controllers get attached: > > http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html > > The global mirroring across trees makes no sense in the future. The > several independent trees will go away in the kernel next year, and > then systemd would not know what to do with an instruction like > DefaultControllers. I realized that when I set the CPUShares attribute on any unit, systemd mirrors the whole cgroup tree into the cpu,cpuacct tree. However, in the past, it was mirrored regardless of such setting. This had the benefit that CPU was equally distributed among services, not among processes. That benefit is now gone if I choose to not configure any cpu settings. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.
On Tue, Oct 29, 2013 at 12:02 AM, WaLyong Cho wrote:
> How about add specific options for smack? According to
> http://schaufler-ca.com/description_from_the_linux_source_tree
>
> Smack supports some mount options:
>
> smackfsdef=label: specifies the label to give files that lack
> the Smack label extended attribute.
>
> smackfsroot=label: specifies the label to assign the root of the
> file system if it lacks the Smack extended attribute.
>
> smackfshat=label: specifies a label that must have read access to
> all labels set on the filesystem. Not yet enforced.
>
> smackfsfloor=label: specifies a label to which all labels set on the
> filesystem must have read access. Not yet enforced.
>
> If we support 'SmackFsRoot=label' option and append the 'smackfsroot' option
> after checking the smack by test_security("smack"), then I think we can
> solve most problems.(with Auke's worry)
Adding config options for optional mount options that aren't even
standard sorry, that just sounds like a terrible idea.
Let's see why the -s option in mount isn't working. For Tizen, I'd
rather see a ConditionSecurity=!smack / ConditionSecurity=smack pair
of complementary unit files since that is a method that should aready
work and even cover the case where you boot with security=none or even
a kernel with smack disabled. Again a solution I would not recommend
carrying upstream but it solves the problem for Tizen well and would
be a 20-line patch or so.
Cheers,
Auke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
On Tue, Oct 29, 2013 at 6:56 PM, Kay Sievers wrote: > On Tue, Oct 29, 2013 at 6:45 PM, Umut Tezduyar wrote: > >>> The global mirroring across trees makes no sense in the future. The >>> several independent trees will go away in the kernel next year, and >>> then systemd would not know what to do with an instruction like >>> DefaultControllers. >> >> I don't disagree that mirroring will not make sense in the future. >> Though, without global mirroring on cpuacct I don't understand how >> systemd-cgtop is expected to give cpu accounting information of >> individual services. Also without global mirroring on cpu control >> group, how would CPUShares=weight even work on any service. I am just >> confused. > > The kernel will only have one single hierarchy, all properties will be > located in this single tree. Thats great but all in the future as you are also saying. > > Cgtop just reads the stuff from the controller *attributes* there, > instead of finding them in a separate controller *tree*. Actually, cgtop just reads the stuff from the cpuacct controller's hierarchy as of today and thats why it is not working for me. Thank you for your email but I think my confusion still remains. Umut > > Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
On Tue, Oct 29, 2013 at 6:45 PM, Umut Tezduyar wrote: >> The global mirroring across trees makes no sense in the future. The >> several independent trees will go away in the kernel next year, and >> then systemd would not know what to do with an instruction like >> DefaultControllers. > > I don't disagree that mirroring will not make sense in the future. > Though, without global mirroring on cpuacct I don't understand how > systemd-cgtop is expected to give cpu accounting information of > individual services. Also without global mirroring on cpu control > group, how would CPUShares=weight even work on any service. I am just > confused. The kernel will only have one single hierarchy, all properties will be located in this single tree. Cgtop just reads the stuff from the controller *attributes* there, instead of finding them in a separate controller *tree*. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
On Tue, Oct 29, 2013 at 5:52 PM, Kay Sievers wrote: > On Tue, Oct 29, 2013 at 5:39 PM, Thomas Bächler wrote: >> Am 29.10.2013 17:21, schrieb Colin Guthrie: > >>> 'Twas brillig, and Umut Tezduyar at 29/10/13 15:17 did gyre and gimble: I have noticed DefaultControllers= option is no longer in system.conf file. Has it been moved to somewhere else or are all controllers default controllers by default? >>> >>> See the various posts on this list and in blogs regarding the cgroups >>> rework. In particular see the mails with the subject "[HEADSUP] cgroup..." >>> >>> See also: >>> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ >> >> None of this explains why systemd no longer applies certain controllers >> by default. Previously, systemd would attach cpu controllers to each >> service by default. Now, it only groups your processes in the systemd >> tree, but does not touch any cgroup controllers. >> >> The new default behaviour (or lack thereof) seems like a step back to me. > > It's a property of a unit now which cgroup controllers get attached: > > http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html > > The global mirroring across trees makes no sense in the future. The > several independent trees will go away in the kernel next year, and > then systemd would not know what to do with an instruction like > DefaultControllers. I don't disagree that mirroring will not make sense in the future. Though, without global mirroring on cpuacct I don't understand how systemd-cgtop is expected to give cpu accounting information of individual services. Also without global mirroring on cpu control group, how would CPUShares=weight even work on any service. I am just confused. Umut > > All implementation details of kernel cgroups are no longer exposed in > systemd, which is a huge step forward, not back. > > Kay > ___ > 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] [PATCH] Experimental socket process pool.
On Mon, Oct 28, 2013 at 11:30 AM, Lennart Poettering wrote: > So yeah, cool feature, and I'd be very happy to see this in PID 1, but I > am very sure we shouldn't merge this tool like this! Can I get some pointers on how to do it in PID 1? If I start them the same way as the semicolon delimiter for ExecStart= does, then they'll all have different namespaces if any are in use. I'd like to avoid that. I'd also like to spawn replacements for ones that exit, and that's an equally hard problem if there's no supervisor process in the namespace. Would it be better to build this around a child instance of systemd, container-style, that manages the pool? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
On Tue, Oct 29, 2013 at 5:39 PM, Thomas Bächler wrote: > Am 29.10.2013 17:21, schrieb Colin Guthrie: >> 'Twas brillig, and Umut Tezduyar at 29/10/13 15:17 did gyre and gimble: >>> I have noticed DefaultControllers= option is no longer in system.conf >>> file. Has it been moved to somewhere else or are all controllers >>> default controllers by default? >> >> See the various posts on this list and in blogs regarding the cgroups >> rework. In particular see the mails with the subject "[HEADSUP] cgroup..." >> >> See also: >> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ > > None of this explains why systemd no longer applies certain controllers > by default. Previously, systemd would attach cpu controllers to each > service by default. Now, it only groups your processes in the systemd > tree, but does not touch any cgroup controllers. > > The new default behaviour (or lack thereof) seems like a step back to me. It's a property of a unit now which cgroup controllers get attached: http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html The global mirroring across trees makes no sense in the future. The several independent trees will go away in the kernel next year, and then systemd would not know what to do with an instruction like DefaultControllers. All implementation details of kernel cgroups are no longer exposed in systemd, which is a huge step forward, not back. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
'Twas brillig, and Thomas Bächler at 29/10/13 16:39 did gyre and gimble: > Am 29.10.2013 17:21, schrieb Colin Guthrie: >> Hi, >> >> 'Twas brillig, and Umut Tezduyar at 29/10/13 15:17 did gyre and gimble: >>> I have noticed DefaultControllers= option is no longer in system.conf >>> file. Has it been moved to somewhere else or are all controllers >>> default controllers by default? >> >> See the various posts on this list and in blogs regarding the cgroups >> rework. In particular see the mails with the subject "[HEADSUP] cgroup..." >> >> See also: >> http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ > > None of this explains why systemd no longer applies certain controllers > by default. Previously, systemd would attach cpu controllers to each > service by default. Now, it only groups your processes in the systemd > tree, but does not touch any cgroup controllers. I can't remember the details but I'm sure there was an explanation posted at some point. I'll let Lennart or Tejun explain the details. I think it relates to the CPUAccounting, MemoryAccounting and BlockIOAccounting settings detailed in systemd.resource-control(5) In addition, if clarifications are added to the previously provided URL, http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/ should likely be updated (used to be referenced in man pages but was dropped in 7ac807320a7416463d7ff3ef6ede574863a601c5 although the wiki page itself still exists obviously) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
Am 29.10.2013 17:21, schrieb Colin Guthrie: > Hi, > > 'Twas brillig, and Umut Tezduyar at 29/10/13 15:17 did gyre and gimble: >> I have noticed DefaultControllers= option is no longer in system.conf >> file. Has it been moved to somewhere else or are all controllers >> default controllers by default? > > See the various posts on this list and in blogs regarding the cgroups > rework. In particular see the mails with the subject "[HEADSUP] cgroup..." > > See also: > http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ None of this explains why systemd no longer applies certain controllers by default. Previously, systemd would attach cpu controllers to each service by default. Now, it only groups your processes in the systemd tree, but does not touch any cgroup controllers. The new default behaviour (or lack thereof) seems like a step back to me. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Where did DefaultControllers= option go?
Hi, 'Twas brillig, and Umut Tezduyar at 29/10/13 15:17 did gyre and gimble: > I have noticed DefaultControllers= option is no longer in system.conf > file. Has it been moved to somewhere else or are all controllers > default controllers by default? See the various posts on this list and in blogs regarding the cgroups rework. In particular see the mails with the subject "[HEADSUP] cgroup..." See also: http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Xorg+logind+DM issue: inactive graphical session for seat0
On Tue, Oct 29, 2013 at 01:44:49PM -0200, Laércio de Sousa wrote: > Joseph Nuzman, who opened the bug above, suggests some approachs to avoid > this problem, and I really want to know what do you think about them: > > * DMs should always set the XDG_VTNR variable for seat0. GDM currently > doesn't set this variable, but a forked version of LightDM, maintained by > Ubuntu Multiseat team (merging into upstream is under consideration), does > it. If I understand the analysis, *two* different X instances would share the same VT. This might work, but option 4 seems superior. > * pam_systemd should have its heuristic to infer the seat0 VT number > improved. Maybe parsing X server /proc//cmdline for a vtXX argument. This looks ugly. > * DMs should ensure that seat0 X server starts before any other one. Stefan > Brüns has provided a similar approach for KDM on Fedora/openSUSE: it > ensures seat0 X server starts at the same VT previously used by Plymouth. This looks racy — let's say that at some point two users on two seats kill their X's. It's impossible to order such events. > I would append another approach to the list: > > * For non-seat0 seats, X server should open no VT at all. Currently, even > with -sharevts option, it seems Xorg does open a VT, although it can't > control this. Right, so why not do this? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Xorg+logind+DM issue: inactive graphical session for seat0
Hello there! I'm posting this question in both systemd-devel and xorg-devel lists because I want to know each one's opinion about it. In some multiseat setups involving multiple video cards, sometimes we get the following error: depending on the display manager currently used, systemd-logind gives us an INACTIVE graphical session for seat0. An interesting analysis of the problem can be found at https://bugzilla.redhat.com/show_bug.cgi?id=1018196. To summarize, due to some race condition between seat0 and non-seat0 seats, a non-seat0 X server can "steal" the VT expected by seat0 X server. In this case, unless XDG_VTNR is explicitly defined by display manager, the pam_systemd module fails to infer the correct VT for seat0 X server (i.e., the one corresponding to vtXX command line argument), returning XDG_VTNR=0 to seat0's graphic session, which causes all the trouble. Joseph Nuzman, who opened the bug above, suggests some approachs to avoid this problem, and I really want to know what do you think about them: * DMs should always set the XDG_VTNR variable for seat0. GDM currently doesn't set this variable, but a forked version of LightDM, maintained by Ubuntu Multiseat team (merging into upstream is under consideration), does it. * pam_systemd should have its heuristic to infer the seat0 VT number improved. Maybe parsing X server /proc//cmdline for a vtXX argument. * DMs should ensure that seat0 X server starts before any other one. Stefan Brüns has provided a similar approach for KDM on Fedora/openSUSE: it ensures seat0 X server starts at the same VT previously used by Plymouth. I would append another approach to the list: * For non-seat0 seats, X server should open no VT at all. Currently, even with -sharevts option, it seems Xorg does open a VT, although it can't control this. CANTATE DOMINO CANTICUM NOVUM QUIA MIRABILIA FECIT Laércio ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Where did DefaultControllers= option go?
Hi, I have noticed DefaultControllers= option is no longer in system.conf file. Has it been moved to somewhere else or are all controllers default controllers by default? If all the controllers are default controllers then something is weird. I have both cpu and cpuacct controllers (and they are joined by systemd) but they don't have system.slice in it (basically they are not mirrored). What could it be? Kernel: 3.10 Impact, systemd-cgtop doesn't work, cpu resource allocation doesn't work, etc. ls -al /sys/fs/cgroup/cpu,cpuacct/ -rw-r--r--1 root root 0 Feb 1 01:15 cgroup.clone_children --w--w--w-1 root root 0 Feb 1 01:15 cgroup.event_control -rw-r--r--1 root root 0 Feb 1 01:29 cgroup.procs -r--r--r--1 root root 0 Feb 1 01:15 cgroup.sane_behavior -rw-r--r--1 root root 0 Feb 1 01:15 cpu.shares -r--r--r--1 root root 0 Feb 1 01:15 cpuacct.stat -rw-r--r--1 root root 0 Feb 1 01:15 cpuacct.usage -r--r--r--1 root root 0 Feb 1 01:15 cpuacct.usage_percpu -rw-r--r--1 root root 0 Feb 1 01:15 notify_on_release -rw-r--r--1 root root 0 Feb 1 01:15 release_agent -rw-r--r--1 root root 0 Feb 1 01:15 tasks ls -al /sys/fs/cgroup/systemd/ -rw-r--r--1 root root 0 Feb 1 01:15 cgroup.clone_children --w--w--w-1 root root 0 Feb 1 01:15 cgroup.event_control -rw-r--r--1 root root 0 Feb 1 01:15 cgroup.procs -r--r--r--1 root root 0 Feb 1 01:15 cgroup.sane_behavior -rw-r--r--1 root root 0 Feb 1 01:15 notify_on_release -rw-r--r--1 root root 0 Feb 1 01:15 release_agent drwxr-xr-x 54 root root 0 Feb 1 01:17 system.slice -rw-r--r--1 root root 0 Feb 1 01:15 tasks Note, I have checked it on arch with latest systemd and it is not mirrored there either. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2]add parameters checking for 'udevadm settle'
On Tue, Oct 29, 2013 at 01:34:33PM +0800, YangZhiyong wrote:
>
>
> > -Original Message-
> > From: YangZhiyong [mailto:yangzy.f...@cn.fujitsu.com]
> > Sent: Tuesday, October 29, 2013 11:33 AM
> > To: 'Zbigniew Jędrzejewski-Szmek'
> > Cc: systemd-devel@lists.freedesktop.org; k...@vrfy.org; fnst-
> > dri...@cn.fujitsu.com
> > Subject: 答复: [systemd-devel] [PATCH 1/2]add parameters checking for
> > 'udevadm settle'
> >
> >
> >
> > > - Original Message -
> > > From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl]
> > > Sent: October 27, 2013 3:29 PM
> > > To: Yang Zhiyong
> > > Cc: systemd-devel@lists.freedesktop.org; k...@vrfy.org
> > > Subject: Re: [systemd-devel] [PATCH 1/2]add parameters checking for
> > > 'udevadm settle'
> > >
> > > On Wed, Oct 23, 2013 at 03:09:36PM +0800, Yang Zhiyong wrote:
> > > > This patch adds parameters checking for 'udevadm settle'
> > > > Signed-off-by: Yang Zhiyong
> > > > ---
> > > > src/udev/udevadm-settle.c | 15 ---
> > > > 1 files changed, 12 insertions(+), 3 deletions(-) mode change
> > > > 100644 => 100755 src/udev/udevadm-settle.c
> > > >
> > > > diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
> > > > old mode 100644 new mode 100755 index c4fc4ee..cacc7e3
> > > > --- a/src/udev/udevadm-settle.c
> > > > +++ b/src/udev/udevadm-settle.c
> > > > @@ -62,8 +62,13 @@ static int adm_settle(struct udev *udev, int
> > > > argc, char
> > > *argv[])
> > > > int seconds;
> > > >
> > > > option = getopt_long(argc, argv, "s:e:t:E:qh",
> > > > options,
> > > NULL);
> > > > -if (option == -1)
> > > > +if (option == -1) {
> > > > +if (optind < argc) {
> > > > +fprintf(stderr, "unknown option\n");
> > > > +exit(EXIT_FAILURE);
> > > > +}
> > > > break;
> > > > +}
> > > I don't think that getopt_long will return -1 for an unknown option.
> > > According to the manpage, -1 mean that all command-line options have
> > been parsed.
> >
> > I'm very sure that getopt_long() will return -1 when we use an unknown
> > option such as " udevadm settle bjjkhgjk" by using "
> > printf("option=%d\n",option);" in the code.
> >
> If we use " udevadm settle --bjjkhgjk"(add "--")the that getopt_long()
> will return "?" as the manpage said, and print error info.
> But if lacking"--", getopt_long() will treat " bjjkhgjk "as parameter
> instead of option .
> Because of this , getopt_long() returns -1 and does not print any error info.
> By the way,some other source code also uses the same method to process the
> more rigorous parameter checking.
Yes! So your code is fine, but please don't say "unknown option", but
rather "Extraneous argument: %s" or something like that.
> > > > switch (option) {
> > > > case 's':
> > > > @@ -74,10 +79,14 @@ static int adm_settle(struct udev *udev, int
> > > > argc,
> > > char *argv[])
> > > > break;
> > > > case 't':
> > > > seconds = atoi(optarg);
> > > > -if (seconds >= 0)
> > > > +if (seconds > 0)
> > > > timeout = seconds;
> > > > -else
> > > > +else if (seconds == 0 && !strcmp(optarg,"0"))
> > > > +timeout = seconds;
> > > > +else {
> > > > fprintf(stderr, "invalid timeout
> > > > value\n");
> > > > +exit(EXIT_FAILURE);
> > > > +}
> > > > break;
> > > > case 'q':
> > > > quiet = 1;
> > > This looks legitimate, but please use safe_atou().
> >
> > You mean using safe_atoi() ?
No, atou, because the timeout must be non-negative.
> Because the type of "seconds" is "int".
>
> > Shall I write like this:
> case 't':
> if (safe_atoi(optarg,&seconds) < 0){
> fprintf(stderr, "invalid timeout value\n");
> exit(EXIT_FAILURE);
> }
> break;
The error message can be improved:
int r;
r = safe_atou(optarg, &seconds);
if (r < 0) {
fprintf(stderr, "Invalid timeout value '%s': %s\n",
optarg, strerror(-r));
exit(EXIT_FAILURE);
}
break;
(Notice the extra whitespace at various points. And please ident with spaces)
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.
On Tue, 29.10.13 16:02, WaLyong Cho (walyong@samsung.com) wrote: > >> Hmm, here's an idea: there has been a long standig feature request to > >> add a configurable boolean to mount unit files that controls > >> /bin/mount's "-s" switch. Let's say we call it > >> "SloppyOptions=yes/no", or so. Then, we could set this for this unit > >> file and apply the rest of the patch and things should work, and where > >> they don't we can easily reassign to the kernel to respect the "-s" flag > >> properly. > >> > >> Doing a patch that allows "-s" to be controlled should be fairly easy, > >> would be happy to merge a patch for that! > > ahhh I hadn't even seen -s in /bin/mount yet, so I can see this > > helping out a lot. > > > > I'd be okay with a solution like that, it would certainly simplify > > things a lot, but we need to be careful not to overload mount options > > with all sorts of nonstandard options - it will make problems harder > > to debug and for some of these security enabled systems we will most > > likely want to actually _not_ use -s. After all, we want to make sure > > we're actually booting with properly setup Smack options e.g. a typo > > in 'nodev,nosuid,nexec' could be disastrous. (typo deliberate). > > > > Auke > > > I am not sure we can use the -s option. First I tried that in my fedora > machine. > > # mount -t tmpfs -s -o mode=1777,strictatime,smackfsroot=* tmpfs /test > mount: wrong fs type, bad option, bad superblock on tmpfs, >missing codepage or helper program, or other error > >In some cases useful info is found in syslog - try >dmesg | tail or so. > > # dmesg > [ 752.222803] tmpfs: Bad mount option smackfsroot Hmm, it appears that libmount/util-linux actually appears to ignore the sloppy mount option entirely. Adding kzak to CC. Karel, what's going on here? Does "-s" have any use at all? Can we make it work for us? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] split journal by loglevel
It was <2013-10-28 pon 19:38>, when Lennart Poettering wrote: > On Tue, 22.10.13 16:45, Łukasz Stelmach (l.stelm...@samsung.com) wrote: [Adding Dariush Michaluk and Juho Son] >> Hello Everyone. >> >> >> Some of you may know I and my colleagues work hard to make Tizen work >> for you. >> > > Rant? Hmm? By definition[1] (n2 fits best IMHO ;) >> Tizen is growing really fast and we've got a problem. A lot of code >> produce a lot of messages. Some of them are more important than others. >> We want to access debug (and info) messages when a system is working and >> we don't want to keep them accross rebots. The obvious solution is to >> split messages into two journal files based on log-level. Less >> important messages would be saved in /run/log/journal more important >> ones in /var/log/journal. > > Sounds like a useful feature! > >> >> RFC. >> >> As obvious as the desired result occurs I am not sure what is the best >> place to hook and configure it. Is it another keyword (or set of >> keywords) for SplitMode: level (level+uid, level+login (level+none?))? >> Or maybe something around MaxLevelStore and line 836 of >> journald-server.c[1]? > > I am tempted to suggest to add a new value to Storage=, maybe called > "level" or so? And then add a new switch StoragePersistentLevel= which > is only interpreted when Storage= equals "level" or if it equals "auto" > and /var/log/journal actually exists. Looks reasonable. >> There is yet another way I can think of: log everything to /run and >> filter out everything below certain log-level. This solution however may >> incur moments heavy load on systems during log rotation. >> >> RFC. >> >> Please give me some clues. > > We currently operate on the runtime journal only if the system journal > is not open. If we keep both open we need to start working on both all > the time. I figure this means a number of changes in journald-server.c, > but most of them should be fairly straightforward... We'll do. Thank you. [1] http://www.dict.org/bin/Dict?Form=Dict1&Query=rant&Strategy=*&Database=wn&Submit=Submit%20query -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics pgpXZRaav7tTX.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] SMACK: assign * label to /tmp when using SMACK.
On 10/29/2013 07:48 AM, Kok, Auke-jan H wrote:
> On Mon, Oct 28, 2013 at 1:09 PM, Lennart Poettering
> wrote:
>> On Mon, 28.10.13 12:59, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:
>>
>>> On Mon, Oct 28, 2013 at 8:58 AM, Lennart Poettering
>>> wrote:
On Mon, 28.10.13 19:44, WaLyong Cho (walyong@samsung.com) wrote:
> At the same reason of /run and /dev/shm, when systemd is running with
> SMACK, countless tasks are failed by missed privilege.
> To avoid, /tmp is assigned '*' label.
Won't this break if people compile systemd with SMACK enabled but
run a kernel that has it disabled?
We had a similar problem for the other mounts like /run, where we found
a somewhat nice solution, but I am not sure how we can make the same
work here...
>>> Our posts intersected, badly. Yes, as I said in my mail, this sadly
>>> does a bad job for those folks running with smack enabled in systemd
>>> but with it disabled in the kernel.
>>>
>>> For Tizen, we're thinking of just keeping this patch out of tree (and
>>> it will just be a one-liner).
>>>
>>> We could do a ConditionSecurity=Smack, or something like that (ottomh)
>>> but we'd get duplicate tmp mounts, which is bad due to the way we name
>>> mount units. ick.
>> Hmm, here's an idea: there has been a long standig feature request to
>> add a configurable boolean to mount unit files that controls
>> /bin/mount's "-s" switch. Let's say we call it
>> "SloppyOptions=yes/no", or so. Then, we could set this for this unit
>> file and apply the rest of the patch and things should work, and where
>> they don't we can easily reassign to the kernel to respect the "-s" flag
>> properly.
>>
>> Doing a patch that allows "-s" to be controlled should be fairly easy,
>> would be happy to merge a patch for that!
> ahhh I hadn't even seen -s in /bin/mount yet, so I can see this
> helping out a lot.
>
> I'd be okay with a solution like that, it would certainly simplify
> things a lot, but we need to be careful not to overload mount options
> with all sorts of nonstandard options - it will make problems harder
> to debug and for some of these security enabled systems we will most
> likely want to actually _not_ use -s. After all, we want to make sure
> we're actually booting with properly setup Smack options e.g. a typo
> in 'nodev,nosuid,nexec' could be disastrous. (typo deliberate).
>
> Auke
>
I am not sure we can use the -s option. First I tried that in my fedora
machine.
# mount -t tmpfs -s -o mode=1777,strictatime,smackfsroot=* tmpfs /test
mount: wrong fs type, bad option, bad superblock on tmpfs,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
# dmesg
[ 752.222803] tmpfs: Bad mount option smackfsroot
In spite of the -s option, we can still see "Bad mount option
smackfsroot". Was I something wrong?
How about add specific options for smack? According to
http://schaufler-ca.com/description_from_the_linux_source_tree
Smack supports some mount options:
smackfsdef=label: specifies the label to give files that lack
the Smack label extended attribute.
smackfsroot=label: specifies the label to assign the root of the
file system if it lacks the Smack extended attribute.
smackfshat=label: specifies a label that must have read access to
all labels set on the filesystem. Not yet enforced.
smackfsfloor=label: specifies a label to which all labels set on the
filesystem must have read access. Not yet enforced.
If we support 'SmackFsRoot=label' option and append the 'smackfsroot'
option after checking the smack by test_security("smack"), then I think
we can solve most problems.(with Auke's worry)
WaLyong
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
