Re: [systemd-devel] [RFC][PATCH] main: ISOLATE rather than REPLACE default.target
Am 05.03.2013 08:32, schrieb Tom Gundersen: On Tue, Mar 5, 2013 at 4:14 PM, Harald Hoyer harald.ho...@gmail.com wrote: Am 05.03.2013 07:56, schrieb Tom Gundersen: This allows switch-root to work correctly if a unit is active both before and after the switch-root, but its dependencies change. Before the patch, any dependencies added to active units by switch-root will not be pulled, in particular filesystems configured in /etc/fstab would not be activated if local-fs.target was active in the initrd. It is not clear to me if there is a bug in the REPLACE handling, or if it is working as expected and that we really want to use ISOLATE instead as this patch does. I think the idea was to allow service to be started in the initramfs and be active even until the pivot() shutdown. Now, that I think of it, such services can have IgnoreOnIsolate=yes. That, or they could simply be enabled in the real root. Depends on the service I guess. -t Not for services, which e.g. enable root over network, or s.th. like mdmon. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] initrd-fs.target
Am 05.03.2013 08:33, schrieb Harald Hoyer: For me the sysroot-usr.mount is not mounted in my testsuite unless I patch it like mentioned above. switch_root:/# ls /sysroot/usr/ switch_root:/# systemctl status sysroot-usr.mount sysroot-usr.mount - /sysroot/usr Loaded: loaded (/sysroot/etc/fstab) Active: inactive (dead) Where: /sysroot/usr What: /dev/sdb2 switch_root:/# systemctl status local-fs.target local-fs.target - Local File Systems Loaded: loaded (/usr/lib/systemd/system/local-fs.target; static) Active: active since Tue 2013-03-05 08:12:17 UTC; 58s ago Docs: man:systemd.special(7) Mar 05 08:12:17 localhost systemd[1]: Starting Local File Systems. Mar 05 08:12:17 localhost systemd[1]: Job local-fs.target/start finished, r...ne Mar 05 08:12:17 localhost systemd[1]: Reached target Local File Systems. switch_root:/# systemctl start local-fs.target switch_root:/# systemctl status sysroot-usr.mount sysroot-usr.mount - /sysroot/usr Loaded: loaded (/sysroot/etc/fstab) Active: active (mounted) since Tue 2013-03-05 08:13:41 UTC; 2s ago Where: /sysroot/usr What: /dev/sdb2 Process: 232 ExecMount=/bin/mount /dev/sdb2 /sysroot/usr -t btrfs -o subvol=usr,ro (code=exited, status=0/SUCCESS) Mar 05 08:13:41 localhost systemd[1]: Mounting /sysroot/usr... Mar 05 08:13:41 localhost systemd[1]: About to execute /bin/mount /dev/sdb2...ro Mar 05 08:13:41 localhost systemd[1]: Forked /bin/mount as 232 Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount changed dead - mounting Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount changed mounting -...ne Mar 05 08:13:41 localhost systemd[1]: Job sysroot-usr.mount/start finished,...ne Mar 05 08:13:41 localhost systemd[1]: Mounted /sysroot/usr. Mar 05 08:13:41 localhost systemd[1]: Child 232 belongs to sysroot-usr.mount Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount mount process exite...=0 Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount changed mounting-do...ed ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] initrd-fs.target
Am 05.03.2013 09:17, schrieb Harald Hoyer: Am 05.03.2013 08:33, schrieb Harald Hoyer: For me the sysroot-usr.mount is not mounted in my testsuite unless I patch it like mentioned above. switch_root:/# ls /sysroot/usr/ switch_root:/# systemctl status sysroot-usr.mount sysroot-usr.mount - /sysroot/usr Loaded: loaded (/sysroot/etc/fstab) Active: inactive (dead) Where: /sysroot/usr What: /dev/sdb2 switch_root:/# systemctl status local-fs.target local-fs.target - Local File Systems Loaded: loaded (/usr/lib/systemd/system/local-fs.target; static) Active: active since Tue 2013-03-05 08:12:17 UTC; 58s ago Docs: man:systemd.special(7) Mar 05 08:12:17 localhost systemd[1]: Starting Local File Systems. Mar 05 08:12:17 localhost systemd[1]: Job local-fs.target/start finished, r...ne Mar 05 08:12:17 localhost systemd[1]: Reached target Local File Systems. switch_root:/# systemctl start local-fs.target switch_root:/# systemctl status sysroot-usr.mount sysroot-usr.mount - /sysroot/usr Loaded: loaded (/sysroot/etc/fstab) Active: active (mounted) since Tue 2013-03-05 08:13:41 UTC; 2s ago Where: /sysroot/usr What: /dev/sdb2 Process: 232 ExecMount=/bin/mount /dev/sdb2 /sysroot/usr -t btrfs -o subvol=usr,ro (code=exited, status=0/SUCCESS) Mar 05 08:13:41 localhost systemd[1]: Mounting /sysroot/usr... Mar 05 08:13:41 localhost systemd[1]: About to execute /bin/mount /dev/sdb2...ro Mar 05 08:13:41 localhost systemd[1]: Forked /bin/mount as 232 Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount changed dead - mounting Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount changed mounting -...ne Mar 05 08:13:41 localhost systemd[1]: Job sysroot-usr.mount/start finished,...ne Mar 05 08:13:41 localhost systemd[1]: Mounted /sysroot/usr. Mar 05 08:13:41 localhost systemd[1]: Child 232 belongs to sysroot-usr.mount Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount mount process exite...=0 Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount changed mounting-do...ed ok, seems to work after a 30s pause. [ OK ] Reached target dracut. [1.067854] systemd[1]: Reloading. [1.125337] ib700wdt: WDT device closed unexpectedly. WDT will not stop! [1.126285] ib700wdt: WDT device closed unexpectedly. WDT will not stop! [1.128650] ib700wdt: WDT device closed unexpectedly. WDT will not stop! [1.130201] ib700wdt: WDT device closed unexpectedly. WDT will not stop! [1.143238] device label dracutusr devid 1 transid 10 /dev/sdb2 [1.148033] btrfs: disk space caching is enabled [1.328218] tsc: Refined TSC clocksource calibration: 2591.585 MHz [ 31.196611] systemd[1]: Switching root. [ 31.200509] systemd-cgroups-agent[233]: Failed to get D-Bus connection: Failed to connect to socket /org/freedesktop/systemd1/private: Connection refused [ 31.206183] systemd-journald[55]: Received SIGTERM [ OK ] Stopped Switch Root. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] initrd-fs.target
Am 05.03.2013 09:56, schrieb Harald Hoyer: Am 05.03.2013 09:17, schrieb Harald Hoyer: Am 05.03.2013 08:33, schrieb Harald Hoyer: For me the sysroot-usr.mount is not mounted in my testsuite unless I patch it like mentioned above. switch_root:/# ls /sysroot/usr/ switch_root:/# systemctl status sysroot-usr.mount sysroot-usr.mount - /sysroot/usr Loaded: loaded (/sysroot/etc/fstab) Active: inactive (dead) Where: /sysroot/usr What: /dev/sdb2 switch_root:/# systemctl status local-fs.target local-fs.target - Local File Systems Loaded: loaded (/usr/lib/systemd/system/local-fs.target; static) Active: active since Tue 2013-03-05 08:12:17 UTC; 58s ago Docs: man:systemd.special(7) Mar 05 08:12:17 localhost systemd[1]: Starting Local File Systems. Mar 05 08:12:17 localhost systemd[1]: Job local-fs.target/start finished, r...ne Mar 05 08:12:17 localhost systemd[1]: Reached target Local File Systems. switch_root:/# systemctl start local-fs.target switch_root:/# systemctl status sysroot-usr.mount sysroot-usr.mount - /sysroot/usr Loaded: loaded (/sysroot/etc/fstab) Active: active (mounted) since Tue 2013-03-05 08:13:41 UTC; 2s ago Where: /sysroot/usr What: /dev/sdb2 Process: 232 ExecMount=/bin/mount /dev/sdb2 /sysroot/usr -t btrfs -o subvol=usr,ro (code=exited, status=0/SUCCESS) Mar 05 08:13:41 localhost systemd[1]: Mounting /sysroot/usr... Mar 05 08:13:41 localhost systemd[1]: About to execute /bin/mount /dev/sdb2...ro Mar 05 08:13:41 localhost systemd[1]: Forked /bin/mount as 232 Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount changed dead - mounting Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount changed mounting -...ne Mar 05 08:13:41 localhost systemd[1]: Job sysroot-usr.mount/start finished,...ne Mar 05 08:13:41 localhost systemd[1]: Mounted /sysroot/usr. Mar 05 08:13:41 localhost systemd[1]: Child 232 belongs to sysroot-usr.mount Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount mount process exite...=0 Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount changed mounting-do...ed ok, seems to work after a 30s pause. [ OK ] Reached target dracut. [1.067854] systemd[1]: Reloading. [1.125337] ib700wdt: WDT device closed unexpectedly. WDT will not stop! [1.126285] ib700wdt: WDT device closed unexpectedly. WDT will not stop! [1.128650] ib700wdt: WDT device closed unexpectedly. WDT will not stop! [1.130201] ib700wdt: WDT device closed unexpectedly. WDT will not stop! [1.143238] device label dracutusr devid 1 transid 10 /dev/sdb2 [1.148033] btrfs: disk space caching is enabled [1.328218] tsc: Refined TSC clocksource calibration: 2591.585 MHz [ 31.196611] systemd[1]: Switching root. [ 31.200509] systemd-cgroups-agent[233]: Failed to get D-Bus connection: Failed to connect to socket /org/freedesktop/systemd1/private: Connection refused [ 31.206183] systemd-journald[55]: Received SIGTERM [ OK ] Stopped Switch Root. seems to be a timing issue also... [1.187037] device label dracutusr devid 1 transid 10 /dev/sdb2 [1.195875] systemd[1]: Switching root. [1.201063] btrfs: disk space caching is enabled [1.203918] systemd-journald[54]: Received SIGTERM [1.211544] systemd[1]: No /sbin/init, trying fallback [1.212769] systemd[1]: Failed to execute /bin/sh, giving up: No such file or directory ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] initrd-fs.target
Am 05.03.2013 10:07, schrieb Harald Hoyer:
Am 05.03.2013 09:56, schrieb Harald Hoyer:
Am 05.03.2013 09:17, schrieb Harald Hoyer:
Am 05.03.2013 08:33, schrieb Harald Hoyer:
For me the sysroot-usr.mount is not mounted in my testsuite unless I patch
it
like mentioned above.
switch_root:/# ls /sysroot/usr/
switch_root:/# systemctl status sysroot-usr.mount
sysroot-usr.mount - /sysroot/usr
Loaded: loaded (/sysroot/etc/fstab)
Active: inactive (dead)
Where: /sysroot/usr
What: /dev/sdb2
switch_root:/# systemctl status local-fs.target
local-fs.target - Local File Systems
Loaded: loaded (/usr/lib/systemd/system/local-fs.target; static)
Active: active since Tue 2013-03-05 08:12:17 UTC; 58s ago
Docs: man:systemd.special(7)
Mar 05 08:12:17 localhost systemd[1]: Starting Local File Systems.
Mar 05 08:12:17 localhost systemd[1]: Job local-fs.target/start finished,
r...ne
Mar 05 08:12:17 localhost systemd[1]: Reached target Local File Systems.
switch_root:/# systemctl start local-fs.target
switch_root:/# systemctl status sysroot-usr.mount
sysroot-usr.mount - /sysroot/usr
Loaded: loaded (/sysroot/etc/fstab)
Active: active (mounted) since Tue 2013-03-05 08:13:41 UTC; 2s ago
Where: /sysroot/usr
What: /dev/sdb2
Process: 232 ExecMount=/bin/mount /dev/sdb2 /sysroot/usr -t btrfs -o
subvol=usr,ro (code=exited, status=0/SUCCESS)
Mar 05 08:13:41 localhost systemd[1]: Mounting /sysroot/usr...
Mar 05 08:13:41 localhost systemd[1]: About to execute /bin/mount
/dev/sdb2...ro
Mar 05 08:13:41 localhost systemd[1]: Forked /bin/mount as 232
Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount changed dead -
mounting
Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount changed mounting
-...ne
Mar 05 08:13:41 localhost systemd[1]: Job sysroot-usr.mount/start
finished,...ne
Mar 05 08:13:41 localhost systemd[1]: Mounted /sysroot/usr.
Mar 05 08:13:41 localhost systemd[1]: Child 232 belongs to sysroot-usr.mount
Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount mount process
exite...=0
Mar 05 08:13:41 localhost systemd[1]: sysroot-usr.mount changed
mounting-do...ed
Resetting all targets to TARGET_DEAD after deserialization helps here without
the manual restart.
diff --git a/src/core/target.c b/src/core/target.c
index 9814241..960c2a8 100644
--- a/src/core/target.c
+++ b/src/core/target.c
@@ -114,7 +114,7 @@ static int target_coldplug(Unit *u) {
assert(t-state == TARGET_DEAD);
if (t-deserialized_state != t-state)
-target_set_state(t, t-deserialized_state);
+target_set_state(t, t-state);
return 0;
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/4] fstab-generator: skip generation, if sysroot.mount already exists
Am 05.03.2013 07:28, schrieb har...@redhat.com:
From: Harald Hoyer har...@redhat.com
---
src/fstab-generator/fstab-generator.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index fade192..3b8329b 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -450,10 +450,19 @@ finish:
static int parse_new_root_from_proc_cmdline(void) {
char *w, *state;
-_cleanup_free_ char *what = NULL, *type = NULL, *opts = NULL, *line
= NULL;
+_cleanup_free_ char *what = NULL, *type = NULL, *opts = NULL, *line
= NULL, *mu = NULL;
int r;
size_t l;
+/* Skip generation, if sysroot.mount already exists */
+mu = strjoin(arg_dest, /, sysroot.mount, NULL);
+if (!mu)
+return log_oom();
+
+r = access(mu, R_OK);
+if (r == 0)
+return 0;
+
r = read_one_line_file(/proc/cmdline, line);
if (r 0) {
log_error(Failed to read /proc/cmdline, ignoring: %s,
strerror(-r));
scratch that
most of my problems were solved with:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=135b5212d4234f5b75c9b86c9f924047c8d07589
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/4] fstab-generator: do not overwrite already generated units
Am 05.03.2013 07:28, schrieb har...@redhat.com:
From: Harald Hoyer har...@redhat.com
only checks for /run/systemd/generator/*.mount
---
src/fstab-generator/fstab-generator.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 3b8329b..502f64c 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -419,6 +419,21 @@ static int parse_fstab(const char *prefix, bool initrd) {
if (is_path(where))
path_kill_slashes(where);
+if (initrd) {
+char _cleanup_free_ *mu = NULL, *name = NULL;
+/* Skip generation, if unit already exists */
+name = unit_name_from_path(where, .mount);
+if (!name)
+return log_oom();
+mu = strjoin(arg_dest, /, name, NULL);
+if (!mu)
+return log_oom();
+
+k = access(mu, R_OK);
+if (k == 0)
+continue;
+}
+
log_debug(Found entry what=%s where=%s type=%s, what,
where, me-mnt_type);
if (streq(me-mnt_type, swap))
scratch that
most of my problems were solved with:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=135b5212d4234f5b75c9b86c9f924047c8d07589
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] main: ISOLATE rather than REPLACE default.target
Am 05.03.2013 07:56, schrieb Tom Gundersen:
This allows switch-root to work correctly if a unit is active both before and
after the switch-root, but its dependencies change. Before the patch, any
dependencies added to active units by switch-root will not be pulled, in
particular filesystems configured in /etc/fstab would not be activated if
local-fs.target was active in the initrd.
It is not clear to me if there is a bug in the REPLACE handling, or if it is
working as expected and that we really want to use ISOLATE instead as this
patch
does.
Comments?
Cc: Harald Hoyer harald.ho...@gmail.com
---
src/core/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/main.c b/src/core/main.c
index 71e0a6c..2bbea7e 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1720,7 +1720,7 @@ int main(int argc, char *argv[]) {
manager_dump_units(m, stdout, \t);
}
-r = manager_add_job(m, JOB_START, target, JOB_REPLACE,
false, error, default_unit_job);
+r = manager_add_job(m, JOB_START, target, JOB_ISOLATE,
false, error, default_unit_job);
if (r 0) {
log_error(Failed to start default target: %s,
bus_error(error, r));
dbus_error_free(error);
works for me
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd kiosk volatile $HOME
On Tue, Mar 5, 2013 at 3:41 PM, Mirco Tischler mt...@gmx.de wrote: 2013/3/5 systemdki...@yopmail.com Thank you Lennart. I wonder how your tip compares to our result? Our method employs getty.target and local-fs.target. It works but we prefer the Right Thing (tm). Would systemd-user-sessions.service be better for any reason? Here's our unit as it sits. Thanks for your input. # /etc/systemd/system/ramhome-setup.service [Unit] Description=Populate RAM user files from persistent store After=local-fs.target [Service] Type=oneshot ExecStart=/usr/bin/rsync --archive /home/ramhome/ /ramhome RemainAfterExit=no [Install] RequiredBy=getty.target After=local-fs.target is not needed, as this is implied in the default dependencies. Ordering against getty.target seems wrong, There is no ordering against getty.target. For ordering you need After/Before. not Requires. Also it probably should be WantedBy. RequiredBy implies that getty.target is stopped if this unit is stopped. But as this unit is oneshot and RemainAfterExit=no, it is stopped immediately after rsync has finished - so, getty.target should be stopped as well? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 3 commits - Makefile.am src/core src/fstab-generator units/initrd-cleanup.service units/initrd-fs-pre.target units/initrd-fs.target units/initrd-parse-etc.service
Am 05.03.2013 02:05, schrieb Lennart Poettering:
On Mon, 04.03.13 10:43, Harald Hoyer (har...@kemper.freedesktop.org) wrote:
+if (initrd) {
+char _cleanup_free_ *mu = NULL, *name = NULL;
+/* Skip generation, if unit already exists */
+name = unit_name_from_path(where, .mount);
+if (!name)
+return log_oom();
+mu = strjoin(arg_dest, /, name, NULL);
+if (!mu)
+return log_oom();
+
+k = access(mu, R_OK);
+if (k == 0)
+continue;
+}
Ahum. I can't say I like invocations to access() like this one. There
are very few cases where access() is the right syscall to invoke, and I
am pretty sure this is not one of them, due to its inherent
raciness. There might be other generators running in parallel to this
one, so the existance of the mount unit might have already changed by
the time you then go on and actually create the unit file. So, your
test here doesn't work and is pointless.
Please folks, be very careful with access()! Uses like this are broken,
you want to rely on O_EXCL (or fopen's x) instead, to ensure the file
is only created if it doesn't exist yet, and that is atomic.
Quite frankly, the majority of the uses of access()es I have seen in my
life are misuses, people really should keep the atomicity of things in mind.
static int parse_new_root_from_proc_cmdline(void) {
char *w, *state;
-_cleanup_free_ char *what = NULL, *type = NULL, *opts = NULL, *line
= NULL;
+_cleanup_free_ char *what = NULL, *type = NULL, *opts = NULL, *line
= NULL, *mu = NULL;
int r;
size_t l;
+/* Skip generation, if sysroot.mount already exists */
+mu = strjoin(arg_dest, /, sysroot.mount, NULL);
+if (!mu)
+return log_oom();
+
+r = access(mu, R_OK);
+if (r == 0)
+return 0;
+
Same here. Also: indentation is borked.
Lennart
Sorry... reverted anyway
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Python wrappers for the DBus API
On Mon, Mar 4, 2013 at 11:16 PM, Holger Winkelmann h...@travelping.com wrote: I Like the idea as well to have direct DBus access to systemd. Regarding your example of the journal wrapper. Anybody knows the API to write to the journal without using the C library? Is this DBus transport as well? Or is there a special journal socket to write to? You write by just putting output on stdout/stderr... do you mean reading from the journal instead? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] main: ISOLATE rather than REPLACE default.target
On Tue, 05.03.13 15:56, Tom Gundersen (t...@jklm.no) wrote:
This allows switch-root to work correctly if a unit is active both before and
after the switch-root, but its dependencies change. Before the patch, any
dependencies added to active units by switch-root will not be pulled, in
particular filesystems configured in /etc/fstab would not be activated if
local-fs.target was active in the initrd.
Yes, this is the intended behaviour of JOB_REPLACE: we will not pull in
dependencies of units which are satisfied anyway.
It is not clear to me if there is a bug in the REPLACE handling, or if it is
working as expected and that we really want to use ISOLATE instead as this
patch
does.
This might make sense to add. Michal, do you have an opinion on this? I
see no obvious problem with this patch, do you see any?
Comments?
Cc: Harald Hoyer harald.ho...@gmail.com
---
src/core/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/main.c b/src/core/main.c
index 71e0a6c..2bbea7e 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1720,7 +1720,7 @@ int main(int argc, char *argv[]) {
manager_dump_units(m, stdout, \t);
}
-r = manager_add_job(m, JOB_START, target, JOB_REPLACE,
false, error, default_unit_job);
+r = manager_add_job(m, JOB_START, target, JOB_ISOLATE,
false, error, default_unit_job);
if (r 0) {
log_error(Failed to start default target: %s,
bus_error(error, r));
dbus_error_free(error);
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Python wrappers for the DBus API
On Tue, 05.03.13 08:16, Holger Winkelmann (h...@travelping.com) wrote: I Like the idea as well to have direct DBus access to systemd. Regarding your example of the journal wrapper. Anybody knows the API to write to the journal without using the C library? Is this DBus transport as well? Or is there a special journal socket to write to? No, there's only the C library, and the Python module around it. Funneling journal payload through D-Bus is not a good idea I think, at least with current D-Bus, since D-Bus isn't really up for payload, it's only for small control messages. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DBus service name encoding
On Mon, 04.03.13 19:00, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 04/03/13 14:31, Lennart Poettering wrote: So here's how to do this, it's very simple: every char outside of the A-Za-z0-9 range is escaped as _XY where XY is the numeric code of the char, as 2 char lower-case hex value. Note that _ itself is also escaped, to _5f. This sounds a lot like Telepathy's tp_escape_as_identifier(). Before freezing this as ABI, you might want to consider a couple of the more subtle points from that function: * we also escape any leading digit in the same way, so that a name starting with a digit is escaped as a valid bus name component (123.service - _3123_2eservice, because the D-Bus specification says Only elements that are part of a unique connection name may begin with a digit) * for completeness, we also escape into _ (because a zero-length string is not a valid D-Bus name component) This results in its output being a valid D-Bus bus-name element, interface-name element, member, and object-path element, and also a valid C identifier. Thanks for the suggestions! I have now updated systemd to follow the same logic in these corner cases. I also added test cases so that this should be pretty much set in stone now. 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] zsh-completion: journalctl query by binary and device
implement 1883552c3d8 from bash completion in zsh-completion
---
shell-completion/systemd-zsh-completion.zsh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/shell-completion/systemd-zsh-completion.zsh
b/shell-completion/systemd-zsh-completion.zsh
index 46e29b2..77b26f6 100644
--- a/shell-completion/systemd-zsh-completion.zsh
+++ b/shell-completion/systemd-zsh-completion.zsh
@@ -94,6 +94,7 @@ _ctls()
'--verify[Verify journal file consistency]' \
'--list-catalog[List messages in catalog]' \
'--update-catalog[Update binary catalog database]' \
+'*::default: _journal_none'
;;
localectl)
_arguments \
@@ -608,6 +609,7 @@ _list_fields() {
_{P,U,G}ID _COMM _EXE _CMDLINE
_AUDIT_{SESSION,LOGINUID}
_SYSTEMD_{CGROUP,SESSION,UNIT,OWNER_UID}
+_SYSTEMD_USER_UNIT
_SELINUX_CONTEXT _SOURCE_REALTIME_TIMESTAMP
_{BOOT,MACHINE}_ID _HOSTNAME _TRANSPORT
_KERNEL_{DEVICE,SUBSYSTEM}
@@ -616,6 +618,15 @@ _list_fields() {
_describe 'possible fields' journal_fields
}
+_journal_none() {
+local -a _commands _files
+_commands=( ${(f)$(_call_program commands $service -F _EXE
2/dev/null)} )
+_alternative : \
+'files:/dev files:_files -W /dev -P /dev/' \
+commands:commands:($_commands[@]) \
+'fields:fields:_list_fields'
+}
+
_journal_fields() {
local -a _fields cmd
cmd=(journalctl -F ${@[-1]} 2/dev/null )
--
1.8.1.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: user session lifetimes vs. $DISPLAY
On Mon, 18.02.13 12:38, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:
Heya!
(Sorry for the late reply, still fighting against my mail queue after a
week of confs).
I've recently been researching systemd's current support for user
sessions, with the goal of sorting out any remaining omissions/issues
and having GDM integrate well with it.
It looks as though the intention is that if I have overlapping sessions
like this:
* 14:00: log in to GDM on X11 display :0
* 14:10: log in via ssh or getty or something
* 14:20: log out from :0
* 14:30: log in to GDM on X11 display :1
* 14:40: log out from ssh/getty
* 14:50: log out from :1
then from 14:00 to 14:50 I have one XDG_RUNTIME_DIR, one 'systemd
--user' instance (as per systemd's TODO: started by logind using
user@.service, on behalf of pam_systemd) and one 'dbus-daemon --session'
instance (presumably started by that 'systemd --user'). Is that how it's
meant to work?
Correct. This is he current plan. The user@.service bit has been missing
so far however.
Or am I meant to have one 'systemd --user' instance per
login session, or one D-Bus session bus per login session?
Nope, this is supposed to be per-user, not per-session.
Also, the idea was to allow people to run the session bus if they wish,
but this should be an exotic feature, and in all normal cases the
session bus should be redirected to the user bus.
Is there any plan for how GUI processes started via session D-Bus
activation should pick up the right value for $DISPLAY (in my example:
:0 until 14:20, nothing from 14:20 to 14:30, :1 from 14:30 onwards)
and $XAUTHORITY, or is that something that still needs to be solved? Or
are GUI processes meant to obtain their X11 display and authority file
in some other way?
$XDG_RUNTIME_DIR/display should be a symlink to the actual socket. But
this is incomplete, as libX11 has not been patched yet. (And also leaves
the question of remote displays unanswered...)
One simple example of a GUI process started by session D-Bus activation
is that /usr/bin/gnome-terminal is just a remote control which
activates ${libexecdir}/gnome-terminal-server, a GUI application, and
tells it to open a new window. This is currently a D-Bus session service
using traditional D-Bus activation, but it should presumably become a
systemd user service, with the dbus-daemon handing off activation to the
user instance of systemd.
If used in my example above, a gnome-terminal-server started at 14:05
ought to use display :0, and exit at 14:20 when it loses its connection
to the X11 server; if I then run gnome-terminal at (say) 14:35, the
desired result is a new gnome-terminal-server on display :1. If the
overlapping sessions share a 'systemd --user' and a 'dbus-daemon
--session', then that would even work if I ran gnome-terminal from the
text-mode session, which is a nice improvement over how it currently
works with a session-scoped dbus-daemon (it'd fail because the text-mode
session either doesn't have a dbus-daemon, or has a dbus-daemon with no
$DISPLAY).
If there is not currently a plan for how to deal with DISPLAY and
XAUTHORITY, I think they could be solved by having 'systemd --user'
watch logind, and include those variables (or perhaps only DISPLAY?)
from the corresponding uid's most-recently-started X11 session? (I
believe GDM only supports one simultaneous X11 session per uid anyway.)
I don't know much about Wayland, but it appears that it normally has one
socket wayland-0 in the XDG_RUNTIME_DIR, and only needs to use further
environment variables if there's more than one Wayland compositor
sharing an XDG_RUNTIME_DIR.
In the long run we really should try to get rid of the env var thing,
since that implies serialization. Instead, we should try to use bus
activation and socket activation via $XDG_RUNTIME_DIR wherever possible,
which allows parallel start-up everywhere, and even allows us to handle
nicely that the display in your example changes in the middle of
everything.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: user session lifetimes vs. $DISPLAY
On Mon, 18.02.13 11:08, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: I believe that the DBus bits are properly in place to have one single user bus per user session. Nope, we never finished that. However, you currently can invoke dbus-daemon --session in a per-user rather than per-session context and things should just work, and that's what most folks do, but in the long run, we really should fix this. For each login, you'd have an instance service (e.g. gnome-session@:0.service) to serve that display. Well, I am not convinced it is necessary to instantiate everything. People can do that if they really really want to make things work to allow one local user to run multiple sessions, but I am pretty sure that should be out of scope for GNOME. GNOME components should just be normal services that are started on the user bus and which find their display from XDG_RUNTIME_DIR. GUI processes running under a gnome-session@:0.service should be able to getenv(DISPLAY) if it's set by gnome-session@.service (Environment=DISPLAY=%I). Yes and no. For the instantiation case you are right, but as mentioned I don't think GNOME and suchlike really should bother with that. I'd hence expect that GNOME apps would run without $DISPLAY set, but libX11 would be capable of using $XDG_RUNTIME_DIR/display in that case. 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] allow more special characters in pretty hostname
this addresses the bug at:
https://bugs.freedesktop.org/show_bug.cgi?id=59311
hostnamectl is supposed to allow a range of special characters for
the 'pretty' hostname:
$ hostnamectl set-hostname --pretty Nathaniels Desktop !@#$%
..however, it rejects apostrophes, double quotes, and backslashes.
The manual for hostnamectl suggests that this should be allowed.
It makes sense to reject \0, \n, etc. pretty_string_is_safe() is
the same as string_is_safe(), but allows more special characters.
---
src/hostname/hostnamed.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index 7ea891c..979dcfd 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -159,6 +159,19 @@ static bool valid_chassis(const char *chassis) {
chassis);
}
+static bool pretty_string_is_safe(const char *p) {
+ const char *t;
+
+ assert(p);
+
+ for (t = p; *t; t++) {
+ if (*t = '\0' *t ' ')
+ return false;
+ }
+
+ return true;
+}
+
static const char* fallback_chassis(void) {
int r;
char *type;
@@ -553,7 +566,7 @@ static DBusHandlerResult hostname_message_handler(
* safe than sorry */
if (k == PROP_ICON_NAME
!filename_is_safe(name))
return
bus_send_error_reply(connection, message, NULL, -EINVAL);
-if (k == PROP_PRETTY_HOSTNAME
!string_is_safe(name))
+if (k == PROP_PRETTY_HOSTNAME
!pretty_string_is_safe(name))
return
bus_send_error_reply(connection, message, NULL, -EINVAL);
if (k == PROP_CHASSIS !valid_chassis(name))
return
bus_send_error_reply(connection, message, NULL, -EINVAL);
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: user session lifetimes vs. $DISPLAY
On Tue, Mar 5, 2013 at 11:48 AM, Lennart Poettering mzta...@0pointer.de wrote: On Mon, 18.02.13 11:08, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: I believe that the DBus bits are properly in place to have one single user bus per user session. Nope, we never finished that. However, you currently can invoke dbus-daemon --session in a per-user rather than per-session context and things should just work, and that's what most folks do, but in the long run, we really should fix this. What's actually missing here? For each login, you'd have an instance service (e.g. gnome-session@:0.service) to serve that display. Well, I am not convinced it is necessary to instantiate everything. People can do that if they really really want to make things work to allow one local user to run multiple sessions, but I am pretty sure that should be out of scope for GNOME. GNOME components should just be normal services that are started on the user bus and which find their display from XDG_RUNTIME_DIR. GUI processes running under a gnome-session@:0.service should be able to getenv(DISPLAY) if it's set by gnome-session@.service (Environment=DISPLAY=%I). Yes and no. For the instantiation case you are right, but as mentioned I don't think GNOME and suchlike really should bother with that. I'd hence expect that GNOME apps would run without $DISPLAY set, but libX11 would be capable of using $XDG_RUNTIME_DIR/display in that case. ok, thanks for replying - I'm trying to figure out the direction here and seeing if I can get some of the X11 folks here engaged in removing some of the blockers. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] allow more special characters in pretty hostname
On Tue, 05.03.13 11:46, Nathaniel Chen (nathaniel.c...@intel.com) wrote:
Thanks! Applied!
this addresses the bug at:
https://bugs.freedesktop.org/show_bug.cgi?id=59311
hostnamectl is supposed to allow a range of special characters for
the 'pretty' hostname:
$ hostnamectl set-hostname --pretty Nathaniels Desktop !@#$%
..however, it rejects apostrophes, double quotes, and backslashes.
The manual for hostnamectl suggests that this should be allowed.
It makes sense to reject \0, \n, etc. pretty_string_is_safe() is
the same as string_is_safe(), but allows more special characters.
---
src/hostname/hostnamed.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index 7ea891c..979dcfd 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -159,6 +159,19 @@ static bool valid_chassis(const char *chassis) {
chassis);
}
+static bool pretty_string_is_safe(const char *p) {
+ const char *t;
+
+ assert(p);
+
+ for (t = p; *t; t++) {
+ if (*t = '\0' *t ' ')
+ return false;
+ }
+
+ return true;
+}
+
static const char* fallback_chassis(void) {
int r;
char *type;
@@ -553,7 +566,7 @@ static DBusHandlerResult hostname_message_handler(
* safe than sorry */
if (k == PROP_ICON_NAME
!filename_is_safe(name))
return
bus_send_error_reply(connection, message, NULL, -EINVAL);
-if (k == PROP_PRETTY_HOSTNAME
!string_is_safe(name))
+if (k == PROP_PRETTY_HOSTNAME
!pretty_string_is_safe(name))
return
bus_send_error_reply(connection, message, NULL, -EINVAL);
if (k == PROP_CHASSIS
!valid_chassis(name))
return
bus_send_error_reply(connection, message, NULL, -EINVAL);
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: user session lifetimes vs. $DISPLAY
On Tue, Mar 5, 2013 at 9:48 PM, Lennart Poettering mzta...@0pointer.de wrote: On Mon, 18.02.13 11:08, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: For each login, you'd have an instance service (e.g. gnome-session@:0.service) to serve that display. Well, I am not convinced it is necessary to instantiate everything. People can do that if they really really want to make things work to allow one local user to run multiple sessions, but I am pretty sure that should be out of scope for GNOME. GNOME components should just be normal services that are started on the user bus and which find their display from XDG_RUNTIME_DIR. Hmm, could one set XDG_RUNTIME_DIR=/run/user/$UID/second-session and have multiple sessions that way? -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] zsh-completion: journalctl query by binary and device
On Tue, 05.03.13 14:32, Daniel Wallace (danielwall...@gtmanfred.com) wrote:
implement 1883552c3d8 from bash completion in zsh-completion
Thanks, applied!
---
shell-completion/systemd-zsh-completion.zsh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/shell-completion/systemd-zsh-completion.zsh
b/shell-completion/systemd-zsh-completion.zsh
index 46e29b2..77b26f6 100644
--- a/shell-completion/systemd-zsh-completion.zsh
+++ b/shell-completion/systemd-zsh-completion.zsh
@@ -94,6 +94,7 @@ _ctls()
'--verify[Verify journal file consistency]' \
'--list-catalog[List messages in catalog]' \
'--update-catalog[Update binary catalog database]' \
+'*::default: _journal_none'
;;
localectl)
_arguments \
@@ -608,6 +609,7 @@ _list_fields() {
_{P,U,G}ID _COMM _EXE _CMDLINE
_AUDIT_{SESSION,LOGINUID}
_SYSTEMD_{CGROUP,SESSION,UNIT,OWNER_UID}
+_SYSTEMD_USER_UNIT
_SELINUX_CONTEXT _SOURCE_REALTIME_TIMESTAMP
_{BOOT,MACHINE}_ID _HOSTNAME _TRANSPORT
_KERNEL_{DEVICE,SUBSYSTEM}
@@ -616,6 +618,15 @@ _list_fields() {
_describe 'possible fields' journal_fields
}
+_journal_none() {
+local -a _commands _files
+_commands=( ${(f)$(_call_program commands $service -F _EXE
2/dev/null)} )
+_alternative : \
+'files:/dev files:_files -W /dev -P /dev/' \
+commands:commands:($_commands[@]) \
+'fields:fields:_list_fields'
+}
+
_journal_fields() {
local -a _fields cmd
cmd=(journalctl -F ${@[-1]} 2/dev/null )
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: user session lifetimes vs. $DISPLAY
On Tue, Mar 5, 2013 at 12:05 PM, Mantas Mikulėnas graw...@gmail.com wrote: On Tue, Mar 5, 2013 at 9:48 PM, Lennart Poettering mzta...@0pointer.de wrote: On Mon, 18.02.13 11:08, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: For each login, you'd have an instance service (e.g. gnome-session@:0.service) to serve that display. Well, I am not convinced it is necessary to instantiate everything. People can do that if they really really want to make things work to allow one local user to run multiple sessions, but I am pretty sure that should be out of scope for GNOME. GNOME components should just be normal services that are started on the user bus and which find their display from XDG_RUNTIME_DIR. Hmm, could one set XDG_RUNTIME_DIR=/run/user/$UID/second-session and have multiple sessions that way? How will X11 applications find the user bus then? or even systemd? I doubt that will work. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: user session lifetimes vs. $DISPLAY
On Tue, 05.03.13 11:59, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: On Tue, Mar 5, 2013 at 11:48 AM, Lennart Poettering mzta...@0pointer.de wrote: On Mon, 18.02.13 11:08, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: I believe that the DBus bits are properly in place to have one single user bus per user session. Nope, we never finished that. However, you currently can invoke dbus-daemon --session in a per-user rather than per-session context and things should just work, and that's what most folks do, but in the long run, we really should fix this. What's actually missing here? Well, D-Bus would need to learn about this new bus, and determine the socket in $XDG_RUNTIME_DIR automatically, and also fallback from the session to the user bus if the session bus is not reachable otherwise... For each login, you'd have an instance service (e.g. gnome-session@:0.service) to serve that display. Well, I am not convinced it is necessary to instantiate everything. People can do that if they really really want to make things work to allow one local user to run multiple sessions, but I am pretty sure that should be out of scope for GNOME. GNOME components should just be normal services that are started on the user bus and which find their display from XDG_RUNTIME_DIR. GUI processes running under a gnome-session@:0.service should be able to getenv(DISPLAY) if it's set by gnome-session@.service (Environment=DISPLAY=%I). Yes and no. For the instantiation case you are right, but as mentioned I don't think GNOME and suchlike really should bother with that. I'd hence expect that GNOME apps would run without $DISPLAY set, but libX11 would be capable of using $XDG_RUNTIME_DIR/display in that case. ok, thanks for replying - I'm trying to figure out the direction here and seeing if I can get some of the X11 folks here engaged in removing some of the blockers. The patch should be trivial actually, and they sounded quite positive about this already. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: user session lifetimes vs. $DISPLAY
On Tue, 05.03.13 22:05, Mantas Mikulėnas (graw...@gmail.com) wrote: On Tue, Mar 5, 2013 at 9:48 PM, Lennart Poettering mzta...@0pointer.de wrote: On Mon, 18.02.13 11:08, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: For each login, you'd have an instance service (e.g. gnome-session@:0.service) to serve that display. Well, I am not convinced it is necessary to instantiate everything. People can do that if they really really want to make things work to allow one local user to run multiple sessions, but I am pretty sure that should be out of scope for GNOME. GNOME components should just be normal services that are started on the user bus and which find their display from XDG_RUNTIME_DIR. Hmm, could one set XDG_RUNTIME_DIR=/run/user/$UID/second-session and have multiple sessions that way? No. Please don't. XDG_RUNTIME_DIR is a per-user directory and it's documented in the specs. I mean, people can do whatever they want, but we should be really careful with recommending any hacks like this. From the GNOME perspective I am pretty sure multiple-sessions-per-local-user is out of scope. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: user session lifetimes vs. $DISPLAY
On Tue, Mar 05, 2013 at 09:11:28PM +0100, Lennart Poettering wrote: From the GNOME perspective I am pretty sure multiple-sessions-per-local-user is out of scope. That would be really sad. The multi-session stuff is really cool, and the whole stack should support logging in more than once. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Hoe is het met je?
Hi, hoe is het met je? Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Python wrappers for the DBus API
On Mon, Mar 4, 2013 at 11:16 PM, Holger Winkelmann h...@travelping.com wrote: Or is there a special journal socket to write to? Yes, and the Python module's use of the C library wraps all of that. Auke is also correct that you can write to stderr/stdout from a service running in systemd. That does not support structured logging, though. -- 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] RFC: user session lifetimes vs. $DISPLAY
On 05/03/13 20:10, Lennart Poettering wrote: Well, D-Bus would need to learn about this new [user] bus, and determine the socket in $XDG_RUNTIME_DIR automatically, and also fallback from the session to the user bus if the session bus is not reachable otherwise... Do you really want to support both of user bus == session bus and user bus != session bus? With my D-Bus upstream hat on, I doubt we want the complexity (and message-ordering-guarantee-breaking) of having parallel per-XDG_RUNTIME_DIR and per-login-session buses, and everyone having to decide which one their application ought to be on; I predict that having the additional oddity of they are logically distinct, but might really be the same bus, or not is going to cause bugs. If you're determined that a per-user bus is a good thing to have, then I think I'd prefer DBUS_SESSION_BUS_ADDRESS points to the per-XDG_RUNTIME_DIR bus if there is one, or the per-login-session bus otherwise, with the two mutually-exclusive (with the former situation being mainly a new systemd thing, and the latter situation being what you get on current Linux systems). It wouldn't be the first time that systemd has declared these semantics are what we support, nothing else really worked anyway... There's a D-Bus bug where I proposed patches for a new 'xdg-runtime:' transport which looks for a Unix socket in XDG_RUNTIME_DIR, with the intention that the libdbus default could eventually change to xdg-runtime:;autolaunch:, i.e., look in XDG_RUNTIME_DIR first; or if there isn't a socket there, it must be a non-systemd system, so use the traditional X11 autolaunching. Or, if you really really want both user and login-session buses, xdg-runtime: could be the default address for the user bus. The thread on per-user vs. per-login-session buses on the dbus list a couple of years ago raised various concerns, but never really came to any conclusion, unfortunately. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: user session lifetimes vs. $DISPLAY
On Mon, 18.02.13 20:13, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 18/02/13 19:08, Kok, Auke-jan H wrote: On Mon, Feb 18, 2013 at 4:38 AM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: It looks as though the intention is [...] I have one XDG_RUNTIME_DIR, one 'systemd --user' instance (as per systemd's TODO: started by logind using user@.service, on behalf of pam_systemd) and one 'dbus-daemon --session' instance (presumably started by that 'systemd --user'). Ideally, we'd have one `systemd --user` survive throughout the entire sequence. I believe that the DBus bits are properly in place to have one single user bus per user session. To be completely clear: what exactly do you mean by per user session here? Is a user session a login1.Session, or a login1.User? If I upstream the dbus.service, dbus.socket from user-session-units into dbus, then we have exactly one `dbus-daemon --session` per `systemd --user`. If one `systemd --user` spans the whole lifetime of a login1.User, that's one `dbus-daemon --session` across one or more login sessions: My original idea would be to have one user dbus.service + dbus.socket for each user session that is run from the user systemd, and invokes dbus-daemon --user. Of course, dbus-daemon --user doesn't exist now... (see other mail). I'm not sure how much that would actually help. GDM and other display managers currently consider the lifetime of the session to be defined by the lifetime of a process (which, for GNOME, is gnome-session). In principle it would be possible to make that process be start gnome-session@:0.service on the user systemd, and when it exits, exit, but I'm not sure that really gains us anything over GDM just running gnome-session! It seems more useful to get session D-Bus services systemd-activated, then use those whenever possible (so that systemd --user can run them on-demand, perhaps starting as soon as the PAM session opens). My general suggestion is that applications should generally die if their display goes away (libX11 already enforces this...). Having a gnome-session.service BTW sounds like a stop-gap though. My intention is to move the service management bit of gnome-session into systemd (or a generator for it), and then move the rest of it into gnome-settings-daemon, and gnome-session would cease to exist, but I am a bit speaking out of my ass here, since I didn't actually look in detail what gnome-session currently consists of in detail. The next step might be to have a way for XDG applications (.desktop files) - or at least those that are one-at-a-time-per-user - to be systemd-activated, so that application launching happens through the user systemd. Yeah, I would like to see an generator in systemd that converts XDG .desktop files into systemd units. This should probably be a written in GLib, to get the GNOME .desktop file parser into place. Genreally we are a bit careful with glib code in PID 1 (due to OOM), but the nice thing here is that generators are run out-of-process, so this should be fine. Having a `systemd --user` survive across multiple sessions does conflict with user-session-units' current assumptions: it would imply that default.target (or whatever target user@.service runs) cannot usefully depend on anything that's a GUI. xorg.target would also have to change (cope with an X11 display being passed in from outside the session, or be instanced, or something), but that's true for GDM anyway. Not following here.. No, you're right, it's one per (uid, seat) pair. So for multi-seat setups there'd certainly have to be some concept of best X11 display (most recently started?) in the environment of new activations. I'd suggest not to support this. In GNOME I would simply not allow multiple local graphical logins of the same user. Instead, the user should get a nice box that he is already logged in elsewhere. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Python wrappers for the DBus API
Hi David, On Mar 5, 2013, at 9:52 PM, David Strauss da...@davidstrauss.net wrote: On Mon, Mar 4, 2013 at 11:16 PM, Holger Winkelmann h...@travelping.com wrote: Or is there a special journal socket to write to? Yes, and the Python module's use of the C library wraps all of that. Auke is also correct that you can write to stderr/stdout from a service running in systemd. That does not support structured logging, though. Thats what I expected anyway, so for our logging purposes I would like to have structured logging… So thanks for the Info, I'll wait for the Documentation of the raw format (or we check the C implementation) for the time being we use the C-Lib. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] -- Holger Winkelmann Managing Director email: h...@travelping.com phone: +49-391-819099-223 mobil: +49-171-5594745 (DE) -- managed broadband access -- Travelping GmbH phone: +49-391-8190990 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: i...@travelping.com GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: user session lifetimes vs. $DISPLAY
On Tue, 05.03.13 21:19, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Tue, Mar 05, 2013 at 09:11:28PM +0100, Lennart Poettering wrote: From the GNOME perspective I am pretty sure multiple-sessions-per-local-user is out of scope. That would be really sad. The multi-session stuff is really cool, and the whole stack should support logging in more than once. Well, but the simple fact is that much of GNOME is not written that way, heck you cannot even run firefox that way. It's a very nichey usecase, and broken in almost any program we have, except the most trivial... So, disabling this officialy in GNOME is just an act of honesty, and doesn't technically change too much... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Python wrappers for the DBus API
2013/3/5 Holger Winkelmann h...@travelping.com Hi David, On Mar 5, 2013, at 9:52 PM, David Strauss da...@davidstrauss.net wrote: On Mon, Mar 4, 2013 at 11:16 PM, Holger Winkelmann h...@travelping.com wrote: Or is there a special journal socket to write to? Yes, and the Python module's use of the C library wraps all of that. Auke is also correct that you can write to stderr/stdout from a service running in systemd. That does not support structured logging, though. Thats what I expected anyway, so for our logging purposes I would like to have structured logging… So thanks for the Info, I'll wait for the Documentation of the raw format (or we check the C implementation) for the time being we use the C-Lib. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] -- Holger Winkelmann Managing Director Out of curiosity, what are your reasons to avoid the C library? And I personally don't ever expect the raw format to be documented - I see it as an implementation detail, not part of any kind of API Mirco ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: user session lifetimes vs. $DISPLAY
On Tue, 05.03.13 21:01, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 05/03/13 20:10, Lennart Poettering wrote: Well, D-Bus would need to learn about this new [user] bus, and determine the socket in $XDG_RUNTIME_DIR automatically, and also fallback from the session to the user bus if the session bus is not reachable otherwise... Do you really want to support both of user bus == session bus and user bus != session bus? Well, that's a good question actually. Kay actually wants to get rid of the session bus entirely. My own idea was to use it only for gdm to support the multi-seat case, where the same gdm user might need to run multiple gdm sessions in parallel, one for each display. However, that idea is definitely flawed, and it might be better to fix this for good and do dynamic user ids or so for this case, so that the gdm sessions are actually properly isolated from each other... With my D-Bus upstream hat on, I doubt we want the complexity (and message-ordering-guarantee-breaking) of having parallel per-XDG_RUNTIME_DIR and per-login-session buses, and everyone having to decide which one their application ought to be on; I predict that having the additional oddity of they are logically distinct, but might really be the same bus, or not is going to cause bugs. Well, our idea was that if people ask for the session bus, they'd actually get the user bus. That would mean only for the gdm case people would actually have to think whether they really want the session or the user bus, since for all other cases requesting either would actually get you on the very same bus... If you're determined that a per-user bus is a good thing to have, then I think I'd prefer DBUS_SESSION_BUS_ADDRESS points to the per-XDG_RUNTIME_DIR bus if there is one, or the per-login-session bus otherwise, with the two mutually-exclusive (with the former situation being mainly a new systemd thing, and the latter situation being what you get on current Linux systems). It wouldn't be the first time that systemd has declared these semantics are what we support, nothing else really worked anyway... Yeah, this is an option. I mean, to make this clear: one of the reasons I so far never finished this in detail, was that we were a bit unsure about hte best approach here. I kinda hoped that revisiting this after a year would magically have solved this, and we'd know now what way to got, but as it turns out I am still unsure. There's a D-Bus bug where I proposed patches for a new 'xdg-runtime:' transport which looks for a Unix socket in XDG_RUNTIME_DIR, with the intention that the libdbus default could eventually change to xdg-runtime:;autolaunch:, i.e., look in XDG_RUNTIME_DIR first; or if there isn't a socket there, it must be a non-systemd system, so use the traditional X11 autolaunching. Or, if you really really want both user and login-session buses, xdg-runtime: could be the default address for the user bus. This sounds very useful. The thread on per-user vs. per-login-session buses on the dbus list a couple of years ago raised various concerns, but never really came to any conclusion, unfortunately. Yeah, we really should figure out what we want here. I mean, I am happy with breaking some setups, but so far, our case isn't fully sound yet. Anyway, let's try to summarize our status quo: a) systemd knows only --user, i.e. a per-user instance. b) D-Bus knows only a --session, i.e. a per-session instance. And here are our options: 1) Drop systemd --user, and go back to dbus --session. 2) Add dbus --user, and keep it separate from --session, i.e. thus confusing developers with three distinct busses. 3) Same as 2) but do actually keep it separate only for the gdm case, otherwise redirect --session to --user. 4) Introduce --user, and always redirect --session to it. This way --user would be pretty much identical to --sessin, except for where the socket is stored and how it is communicated. Approach 4 is the arguably the cleanest one, but current gdm is incompatible with it. I really don't wan to go back to 1), or do 2). So in my eyes the choice is between 3) and 4). Or are there other ideas, anyone? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: user session lifetimes vs. $DISPLAY
On 05/03/13 21:03, Lennart Poettering wrote: My general suggestion is that applications should generally die if their display goes away (libX11 already enforces this...). Right, but that only happens for GUI applications. One of the original rationales for D-Bus was that it was a way to avoid having stuff like gconfd still hanging around after the login session had finished (admittedly, logind's optional cgroup-killing makes that unnecessary, and is more thorough). Having a gnome-session.service BTW sounds like a stop-gap though. My intention is to move the service management bit of gnome-session into systemd (or a generator for it), and then move the rest of it into gnome-settings-daemon, and gnome-session would cease to exist What would the program whose lifetime defines the GNOME session be, in this world? At the moment things like gdm and startx work like this: register the new login session in PAM/logind/etc. run gnome-session (or startkde or ~/.xsession or whatever) wait for it to exit unregister the login session in PAM/logind/etc. clean up: put the greeter back up (gdm), terminate the X server (startx), or whatever Having a `systemd --user` survive across multiple sessions does conflict with user-session-units' current assumptions: it would imply that default.target (or whatever target user@.service runs) cannot usefully depend on anything that's a GUI. Not following here.. Not sure which bit you weren't following, so I'll try to reword both. The intended design (the one I prototyped) appears to be that logind runs systemd --user for the lifetime of the XDG_RUNTIME_DIR. If this lifetime includes any non-graphical login sessions (ssh, tty), then any session services that are a GUI are just not going to work: log in via ssh PAM registers a login session logind runs my systemd --user [--target default.target] default.target wants gnome-shell.desktop.service ... not going to work very well. xorg.target would also have to change (cope with an X11 display being passed in from outside the session, or be instanced, or something), but that's true for GDM anyway. user-session-units contains a session service which starts Xorg. Under gdm, a $DISPLAY pointing to an existing Xorg instance is passed in from outside (and this is what the logind PAM module expects, in fact), so that session service is somewhere between useless and harmful. Similarly, running that service for a ssh login would be rather undesirable! No, you're right, it's one per (uid, seat) pair. So for multi-seat setups there'd certainly have to be some concept of best X11 display (most recently started?) in the environment of new activations. I'd suggest not to support this. In GNOME I would simply not allow multiple local graphical logins of the same user. Instead, the user should get a nice box that he is already logged in elsewhere. gdm currently limits to one login per user *per seat* - I can't Switch User (VT-switching) and log in a second time as myself, but if I had a USB display/keyboard widget providing a second seat, I'd be able to log in on the main screen and on that at the same time. The idea is that each seat behaves like a separate computer in terms of input and output devices. Are you saying that you don't think it should be possible for a user to be logged-in on both seats? (Whenever there's more than one local X11 display, gdm itself certainly needs to be able to put a small GNOME session on behalf of the special-purpose 'gdm' user on each of them, in order to have the login screen present, with accessibility and stuff - but maybe it's OK to have a special case for system users.) S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Python wrappers for the DBus API
On Mar 5, 2013, at 10:21 PM, Mirco Tischler mt...@gmx.de wrote: 2013/3/5 Holger Winkelmann h...@travelping.com Hi David, On Mar 5, 2013, at 9:52 PM, David Strauss da...@davidstrauss.net wrote: On Mon, Mar 4, 2013 at 11:16 PM, Holger Winkelmann h...@travelping.com wrote: Or is there a special journal socket to write to? Yes, and the Python module's use of the C library wraps all of that. Auke is also correct that you can write to stderr/stdout from a service running in systemd. That does not support structured logging, though. Thats what I expected anyway, so for our logging purposes I would like to have structured logging… So thanks for the Info, I'll wait for the Documentation of the raw format (or we check the C implementation) for the time being we use the C-Lib. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] -- Holger Winkelmann Managing Director Out of curiosity, what are your reasons to avoid the C library? And I personally don't ever expect the raw format to be documented - I see it as an implementation detail, not part of any kind of API Depends how you see an API, We have a messaging passing background (we are Erlang programmer here) and for us the message over the socket is seen as the API. and the C-lib wraps this for the C Language. To use the C-API we need to write a NIF function for Erlang where the c part needs to be cross compiled for all different architectures. Writing the format native to the socket will avoid this. Another example: Just recently we had a project partner being in Java-Land was not allowed by management to use any Native Library. Holger Mirco -- Holger Winkelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Python wrappers for the DBus API
2013/3/5 Holger Winkelmann h...@travelping.com On Mar 5, 2013, at 10:21 PM, Mirco Tischler mt...@gmx.de wrote: 2013/3/5 Holger Winkelmann h...@travelping.com Hi David, On Mar 5, 2013, at 9:52 PM, David Strauss da...@davidstrauss.net wrote: On Mon, Mar 4, 2013 at 11:16 PM, Holger Winkelmann h...@travelping.com wrote: Or is there a special journal socket to write to? Yes, and the Python module's use of the C library wraps all of that. Auke is also correct that you can write to stderr/stdout from a service running in systemd. That does not support structured logging, though. Thats what I expected anyway, so for our logging purposes I would like to have structured logging… So thanks for the Info, I'll wait for the Documentation of the raw format (or we check the C implementation) for the time being we use the C-Lib. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] -- Holger Winkelmann Managing Director Out of curiosity, what are your reasons to avoid the C library? And I personally don't ever expect the raw format to be documented - I see it as an implementation detail, not part of any kind of API Depends how you see an API, We have a messaging passing background (we are Erlang programmer here) and for us the message over the socket is seen as the API. and the C-lib wraps this for the C Language. To use the C-API we need to write a NIF function for Erlang where the c part needs to be cross compiled for all different architectures. Writing the format native to the socket will avoid this. Another example: Just recently we had a project partner being in Java-Land was not allowed by management to use any Native Library. Thanks, that makes more sense. I stupidly assumed you were talking about python ;-) Holger Mirco -- Holger Winkelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] mount and initialize Smack
SMACK is the Simple Mandatory Access Control Kernel, a minimal
approach to Access Control implemented as a kernel LSM.
The kernel exposes the smackfs filesystem API through which access
rules can be loaded. At boot time, we want to load the access rules
as early as possible to ensure all early boot steps are checked by Smack.
This patch mounts smackfs at the new location at /sys/fs/smackfs for
kernels 3.8 and above, and attempts to try /smack in case it fails.
You will need to create the /smack mountpoint manually if needed.
After mounting smackfs, rules are loaded from the usual location.
For more information about Smack see:
http://www.kernel.org/doc/Documentation/security/Smack.txt
---
Makefile.am| 2 +
src/core/main.c| 3 ++
src/core/mount-setup.c | 4 +-
src/core/smack-setup.c | 100 +
src/core/smack-setup.h | 26 +
5 files changed, 134 insertions(+), 1 deletion(-)
create mode 100644 src/core/smack-setup.c
create mode 100644 src/core/smack-setup.h
diff --git a/Makefile.am b/Makefile.am
index 2108abe..b8bac5f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -832,6 +832,8 @@ libsystemd_core_la_SOURCES = \
src/core/selinux-access.h \
src/core/selinux-setup.c \
src/core/selinux-setup.h \
+ src/core/smack-setup.c \
+ src/core/smack-setup.h \
src/core/ima-setup.c \
src/core/ima-setup.h \
src/core/locale-setup.h \
diff --git a/src/core/main.c b/src/core/main.c
index 71e0a6c..71e7124 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -67,6 +67,7 @@
#include selinux-setup.h
#include ima-setup.h
#include fileio.h
+#include smack-setup.h
static enum {
ACTION_RUN,
@@ -1350,6 +1351,8 @@ int main(int argc, char *argv[]) {
goto finish;
if (ima_setup() 0)
goto finish;
+ if (smack_setup() 0)
+ goto finish;
}
if (label_init(NULL) 0)
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index dab3601..0917fbe 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -66,7 +66,7 @@ typedef struct MountPoint {
/* The first three entries we might need before SELinux is up. The
* fourth (securityfs) is needed by IMA to load a custom policy. The
* other ones we can delay until SELinux and IMA are loaded. */
-#define N_EARLY_MOUNT 4
+#define N_EARLY_MOUNT 5
static const MountPoint mount_table[] = {
{ proc, /proc, proc, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,
@@ -77,6 +77,8 @@ static const MountPoint mount_table[] = {
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ securityfs, /sys/kernel/security, securityfs, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,
NULL, MNT_NONE },
+{ smackfs,/sys/fs/smackfs, smackfs,
smackfsdef=*, MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
+ NULL, MNT_NONE},
{ tmpfs, /dev/shm, tmpfs,
mode=1777, MS_NOSUID|MS_NODEV|MS_STRICTATIME,
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ devpts, /dev/pts, devpts,
mode=620,gid= STRINGIFY(TTY_GID), MS_NOSUID|MS_NOEXEC,
diff --git a/src/core/smack-setup.c b/src/core/smack-setup.c
new file mode 100644
index 000..38ce471
--- /dev/null
+++ b/src/core/smack-setup.c
@@ -0,0 +1,100 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+ This file is part of systemd.
+
+ Copyright (C) 2013 Intel Corporation
+ Authors:
+ Nathaniel Chen nathaniel.c...@intel.com
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as published
+ by the Free Software Foundation; either version 2.1 of the License,
+ or (at your option) any later version.
+
+ systemd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include stdio.h
+#include errno.h
+#include string.h
+#include unistd.h
+#include stdlib.h
+#include sys/vfs.h
+#include fcntl.h
+#include sys/types.h
+#include dirent.h
+#include sys/mount.h
+#include stdint.h
+
+#include smack-setup.h
+#include mount-setup.h
+#include util.h
+#include log.h
+#include label.h
+#include macro.h
+
+#define ACCESSES_D_PATH /etc/smack/accesses.d/
+
+int smack_setup(void) {
+
+ FILE *smack;
+ FILE *policy;
+ int m = -1;
+ DIR *dir;
+ struct dirent *entry;
+ char pol[PATH_MAX];
+ char buf[NAME_MAX];
+
+ /*
Re: [systemd-devel] [PATCH] mount and initialize Smack
On Tue, Mar 05, 2013 at 03:24:27PM -0800, Nathaniel Chen wrote:
SMACK is the Simple Mandatory Access Control Kernel, a minimal
approach to Access Control implemented as a kernel LSM.
The kernel exposes the smackfs filesystem API through which access
rules can be loaded. At boot time, we want to load the access rules
as early as possible to ensure all early boot steps are checked by Smack.
This patch mounts smackfs at the new location at /sys/fs/smackfs for
kernels 3.8 and above, and attempts to try /smack in case it fails.
You will need to create the /smack mountpoint manually if needed.
After mounting smackfs, rules are loaded from the usual location.
For more information about Smack see:
http://www.kernel.org/doc/Documentation/security/Smack.txt
Hi,
looks nice and clean in general. Some comments below.
---
Makefile.am| 2 +
src/core/main.c| 3 ++
src/core/mount-setup.c | 4 +-
src/core/smack-setup.c | 100
+
src/core/smack-setup.h | 26 +
5 files changed, 134 insertions(+), 1 deletion(-)
create mode 100644 src/core/smack-setup.c
create mode 100644 src/core/smack-setup.h
diff --git a/Makefile.am b/Makefile.am
index 2108abe..b8bac5f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -832,6 +832,8 @@ libsystemd_core_la_SOURCES = \
src/core/selinux-access.h \
src/core/selinux-setup.c \
src/core/selinux-setup.h \
+ src/core/smack-setup.c \
+ src/core/smack-setup.h \
src/core/ima-setup.c \
src/core/ima-setup.h \
src/core/locale-setup.h \
diff --git a/src/core/main.c b/src/core/main.c
index 71e0a6c..71e7124 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -67,6 +67,7 @@
#include selinux-setup.h
#include ima-setup.h
#include fileio.h
+#include smack-setup.h
static enum {
ACTION_RUN,
@@ -1350,6 +1351,8 @@ int main(int argc, char *argv[]) {
goto finish;
if (ima_setup() 0)
goto finish;
+ if (smack_setup() 0)
+ goto finish;
As you can see from indentation here, something is askew: and indeed,
we only use spaces for indenation, while you add tabs.
}
if (label_init(NULL) 0)
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index dab3601..0917fbe 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -66,7 +66,7 @@ typedef struct MountPoint {
/* The first three entries we might need before SELinux is up. The
* fourth (securityfs) is needed by IMA to load a custom policy. The
* other ones we can delay until SELinux and IMA are loaded. */
-#define N_EARLY_MOUNT 4
+#define N_EARLY_MOUNT 5
static const MountPoint mount_table[] = {
{ proc, /proc, proc, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,
@@ -77,6 +77,8 @@ static const MountPoint mount_table[] = {
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ securityfs, /sys/kernel/security, securityfs, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,
NULL, MNT_NONE },
+{ smackfs,/sys/fs/smackfs, smackfs,
smackfsdef=*, MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
+ NULL, MNT_NONE},
{ tmpfs, /dev/shm, tmpfs,
mode=1777, MS_NOSUID|MS_NODEV|MS_STRICTATIME,
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ devpts, /dev/pts, devpts,
mode=620,gid= STRINGIFY(TTY_GID), MS_NOSUID|MS_NOEXEC,
diff --git a/src/core/smack-setup.c b/src/core/smack-setup.c
new file mode 100644
index 000..38ce471
--- /dev/null
+++ b/src/core/smack-setup.c
@@ -0,0 +1,100 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+ This file is part of systemd.
+
+ Copyright (C) 2013 Intel Corporation
+ Authors:
+ Nathaniel Chen nathaniel.c...@intel.com
+
+ systemd is free software; you can redistribute it and/or modify it
+ under the terms of the GNU Lesser General Public License as published
+ by the Free Software Foundation; either version 2.1 of the License,
+ or (at your option) any later version.
+
+ systemd is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public License
+ along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include stdio.h
+#include errno.h
+#include string.h
+#include unistd.h
+#include stdlib.h
+#include sys/vfs.h
+#include fcntl.h
+#include sys/types.h
+#include dirent.h
+#include sys/mount.h
+#include stdint.h
+
+#include
[systemd-devel] Adding journal support to GNOME's Log Viewer
Log Viewer (gnome-system-log) is a basic, graphical log file viewer bundled with GNOME desktops and useful for anyone with GTK+. Is there any interest in adding (optional) journal support to this program? Are there other up-and-coming log viewers that would be better to focus on? The application is almost entirely C- and Autotools-based, so it should be a breeze to link to journal libraries: https://github.com/GNOME/gnome-system-log Unless we also add remote connection capability (using the journal gateway or SSH), I'm not personally motivated to take this on. Yet, it's a big missing piece for systemd desktop users. It seems like we should have similar effort go into the Qt side, too. Python bindings are also sufficiently far along that it would be possible to build such viewers without C. -- 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
[systemd-devel] syslog CEE support for the journal
Has CEE seen any widespread deployment? It would be straightforward to add the following to the journal: * Optional conversion of non-binary fields to CEE for forwarding to syslog * Conversion of CEE to journal fields within the systemd syslog server * Conversion of CEE to journal fields when a service logs messages with syslog-style priority line prefixes I proposed something similar to the third during the journal hackfest in San Francisco, but my initial work looked for JSON. It would be cleaner to support CEE and extend our existing support for stdout/stderr being syslog-formatted when detected as such. I'm bringing this up because of some remarks [1] I posted on systemd's journal versus syslog. [1] https://plus.google.com/116504510413299636245/posts/V4X3AfcRyMe -- 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] Adding journal support to GNOME's Log Viewer
2013/3/6 David Strauss da...@davidstrauss.net: Log Viewer (gnome-system-log) is a basic, graphical log file viewer bundled with GNOME desktops and useful for anyone with GTK+. Is there any interest in adding (optional) journal support to this program? Are there other up-and-coming log viewers that would be better to focus on? Seeing that https://live.gnome.org/Design/Apps/SystemLog already has links to journal related ressources I guess there are already ideas to do just. I vaguely seem to remember a discussion about this, but can find the link anymore. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Google Summer of Code
Are there any plans to propose projects for GSoC 2013? I've mentored before on behalf of Drupal. -- 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
