Re: [systemd-devel] [PATCH] cgroups: chown user slices
(Note that this means systemd --user will only work when run from user@.service, as access to the cgroup tree is *not* granted for normal sessions directly.) So, how sessions should work now? Before that I started systemd --user as main session process, and when it exited, session exited too. How should I wait for session end now? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroups: chown user slices
Ok. I trying to use current git. Nothing works for me. I.e. systemd --user starts, but I couldn't connect to it, because it doesn't connect to d-bus (because dbus socket doesn't exists and systemd doesn't start dbus.socket probably). systemd starts X services, but they couldn't establish X connection. Generally I couldn't get the idea behind recent changes. How that supposed to work at all? How that 1) will interract with login managers (i.e. waits for systemd --user exits, selects proper starting unit or so) 2) will setup environment from user profile 3) will setup temporary files for user temporary folder (dbus folder, for example) 4) will work with different login paths (ssh, local VT login, X login) Now i have lightdm that explicity starts systemd --user as session process. With Marc-Antoine patch that still works ok, so I will fall back to it and wait for some clarifications ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no installed machine-id vs systemd-in-initramfs
On 07/10/2013 05:26 PM, Colin Walters wrote:
The gnome-ostree build system generates disk images that can be
downloaded directly; there is no installer.
In the old model of dracut shell script + systemd, systemd's main.c
has:
if (arg_running_as == SYSTEMD_SYSTEM ...) {
...
machine_id_setup();
...
}
So after mounting the rootfs, we'd end up writing one to /etc (at least
in gnome-ostree which comes with a writable copy of /etc), and it would
persist across reboots, and all would be well with the world.
In the new systemd-in-initramfs model, journald is now launched in the
initramfs. Dracut will copy the host's machine id into the initramfs
if it exists, but in the gnome-ostree case (or more generally
pre-canned OS case), there isn't one. journald will attempt to start,
and fail.
One thought I had is to say: If there's no /etc/machine-id in the
initramfs, write one to /run/machine-id. After mounting the rootfs,
persist that to /etc.
Err, if there is no machine-id in the initramfs, systemd and journald should do
just fine.
It was this way in F18, F17.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no installed machine-id vs systemd-in-initramfs
On Thu, Jul 11, 2013 at 11:55 AM, Harald Hoyer harald.ho...@gmail.com wrote:
On 07/10/2013 05:26 PM, Colin Walters wrote:
The gnome-ostree build system generates disk images that can be
downloaded directly; there is no installer.
In the old model of dracut shell script + systemd, systemd's main.c
has:
if (arg_running_as == SYSTEMD_SYSTEM ...) {
...
machine_id_setup();
...
}
So after mounting the rootfs, we'd end up writing one to /etc (at least
in gnome-ostree which comes with a writable copy of /etc), and it would
persist across reboots, and all would be well with the world.
In the new systemd-in-initramfs model, journald is now launched in the
initramfs. Dracut will copy the host's machine id into the initramfs
if it exists, but in the gnome-ostree case (or more generally
pre-canned OS case), there isn't one. journald will attempt to start,
and fail.
One thought I had is to say: If there's no /etc/machine-id in the
initramfs, write one to /run/machine-id. After mounting the rootfs,
persist that to /etc.
Err, if there is no machine-id in the initramfs, systemd and journald should
do
just fine.
It was this way in F18, F17.
Didn't it always need an empty file to over-mount it with a temporary
and randomly created one?
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no installed machine-id vs systemd-in-initramfs
On 07/11/2013 12:04 PM, Kay Sievers wrote:
On Thu, Jul 11, 2013 at 11:55 AM, Harald Hoyer harald.ho...@gmail.com wrote:
On 07/10/2013 05:26 PM, Colin Walters wrote:
The gnome-ostree build system generates disk images that can be
downloaded directly; there is no installer.
In the old model of dracut shell script + systemd, systemd's main.c
has:
if (arg_running_as == SYSTEMD_SYSTEM ...) {
...
machine_id_setup();
...
}
So after mounting the rootfs, we'd end up writing one to /etc (at least
in gnome-ostree which comes with a writable copy of /etc), and it would
persist across reboots, and all would be well with the world.
In the new systemd-in-initramfs model, journald is now launched in the
initramfs. Dracut will copy the host's machine id into the initramfs
if it exists, but in the gnome-ostree case (or more generally
pre-canned OS case), there isn't one. journald will attempt to start,
and fail.
One thought I had is to say: If there's no /etc/machine-id in the
initramfs, write one to /run/machine-id. After mounting the rootfs,
persist that to /etc.
Err, if there is no machine-id in the initramfs, systemd and journald should
do
just fine.
It was this way in F18, F17.
Didn't it always need an empty file to over-mount it with a temporary
and randomly created one?
Kay
To quote from the dracut install script:
if [[ $hostonly ]]; then
dracut_install -o \
/etc/machine-id
else
if ! [[ -e $initdir/etc/machine-id ]]; then
$initdir/etc/machine-id
fi
fi
Yes, you are right. In the hostonly case, there is no empty machine-id created,
if it is missing on the running machine.
Will fix.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help getting serial console working again after upgrade to systemd?
It was 2013-07-10 śro 20:26, when Dmt Ops wrote: Hey all, I'm starting upgrades to old production servers to newer 64-bit Linux that runs systemd = v195. Serial consoles are always my 1st step. Before upgrade it worked great. After upgrade, with the new systemd-based config, I'm not having much luck so far. I configured the grub conf: serial --unit=0 --speed=57600 --word=8 --parity=no --stop=1 terminal --timeout=3 serial console title PRODUCTION root (hd0,0) kernel /vmlinuz root=/dev/sd1a noresume showopts x11failsafe vga=0x31a console=tty0 console=com1,vga initrd /initrd According to kernel-parameters.txt[1] (it's for 3.10 but I assume there hasn't been any changes in this area for quite some time) you have to use ttyS0 instead of com1. Neither serial-console.txt[2] mentions com[1-4] to be a proper name for a serial port. [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-parameters.txt?id=v3.10#n560 [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/serial-console.txt?id=v3.10 -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroups: chown user slices
On Wed, 10.07.13 20:07, Kok, Auke-jan H (auke-jan.h@intel.com) wrote: +r = cg_path_get_owner_uid(path, uid); +if (r 0 r != -ENOENT) +return r; + +if (uid != (uid_t) -1) +chown(fs, uid, (gid_t) -1); + systemd in git will now grant access to the cgroup subtree in user@.service to the specific user. That should solve the issue. (Note that this means systemd --user will only work when run from user@.service, as access to the cgroup tree is *not* granted for normal sessions directly.) can you elaborate what normal sessions are? Are we talking about `PAMName=systemd-shared` being the part that distinguishes them? So, when somebody logs in now, let's say via ssh, then ssh goes through PAM to register the new session. pam_systemd talks to logind as part of that to make sure it is tracked by it. logind then does three things: if this is the first login by the user, it will create a slice unit for him, and instantiate user@1000.service for him inside that slice. It will then create a scope unit for the PAM client, and return. After the SSH login there will hence be three units for the user: a scope (for the actual session), a service (for the user systemd instance) and a slice (wrapping it all). When the user then logs in a second time, he will get another scope within the existing slice, and no additional user@.service will be created. After the user logs out fully (i.e. the last of his scopes is gone) the slice and user@.service instance is removed too. If a user has lingering enabled then the slice and user@.service are instantiated at boot time already, i.e. they are not reference counted by the session scopes. Now, since we cannot run user code without having set up PAM for it first user@.service will also go through PAM, however, it will be shortcut in pam_systemd, so that it does not create a logic loop in logind. And yeah, this instance is recognized by the pam service name as set with PAMName=. Only user@.service will get write access to its own cgroup subtree. This is a good thing, since that way we can be sure that only systemd' own code gets write access to the cgroupfs tree, and no other code. Makes some sense I hope? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroups: chown user slices
On Thu, 11.07.13 07:41, Oleksii Shevchuk (alx...@gmail.com) wrote: (Note that this means systemd --user will only work when run from user@.service, as access to the cgroup tree is *not* granted for normal sessions directly.) So, how sessions should work now? Before that I started systemd --user as main session process, and when it exited, session exited too. How should I wait for session end now? The idea was always that there would be one systemd instance *per user* rather than *per session*, that's why the switch is called --user rather than --session. You probably want your session to exist as long as the display it manages is around. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroups: chown user slices
On Thu, 11.07.13 09:40, Oleksii Shevchuk (alx...@gmail.com) wrote: Ok. I trying to use current git. Nothing works for me. I.e. systemd --user starts, but I couldn't connect to it, because it doesn't connect to d-bus (because dbus socket doesn't exists and systemd doesn't start dbus.socket probably). systemd starts X services, but they couldn't establish X connection. Yeah, you need to set some env vars currently. The idea however is that the X/dbus libraries learn to look into XDG_RUNTIME_DIR on their own. Generally I couldn't get the idea behind recent changes. How that supposed to work at all? How that 1) will interract with login managers (i.e. waits for systemd --user exits, selects proper starting unit or so) Nobody needs to wait for systemd --user exits. It will just exist in the background as long as the user is logged in and will go away as soon as he logs out entirely. It is refernce counted by the login sessions. 2) will setup environment from user profile 3) will setup temporary files for user temporary folder (dbus folder, for example) 4) will work with different login paths (ssh, local VT login, X login) Now i have lightdm that explicity starts systemd --user as session process. With Marc-Antoine patch that still works ok, so I will fall back to it and wait for some clarifications Yeah, starting it directly in the session is not really how we intended it to be used, and it's problematic due to access to the cgroupfs. You can make it work by manually granting yourself write access to the cgroupfs subtree, but that's a hack for debugging purposes only. 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] [RFC PATCH] condition: add ConditionFileContains=
Add ability to test if given file contains specified value.
File and expected value are given as one argument separated
by colon (:), i.e.
ConditionFileContains=/sys/module/sn/parameters/enabled:1
---
As above example suggests we use it to conditionally
start service based on kernel module parameter value.
This can be (ab)used for other/regular files too.
RFC
Thanks!
---
man/systemd.unit.xml |8
src/core/condition.c | 34 +
src/core/condition.h |1 +
src/core/load-fragment-gperf.gperf.m4 |1 +
4 files changed, 44 insertions(+)
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index 4f0bd64..d26bd23 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -841,6 +841,7 @@
termvarnameConditionDirectoryNotEmpty=/varname/term
termvarnameConditionFileNotEmpty=/varname/term
termvarnameConditionFileIsExecutable=/varname/term
+
termvarnameConditionFileContains=/varname/term
termvarnameConditionKernelCommandLine=/varname/term
termvarnameConditionVirtualization=/varname/term
termvarnameConditionSecurity=/varname/term
@@ -932,6 +933,13 @@
exists, is a regular file and marked
executable./para
+paravarnameConditionFileContains=/varname
+may be used to check whether a given
+file contains specified value. The
+argument consists of file path to be
+tested, separator (:), and the
+expected value./para
+
paraSimilar,
varnameConditionKernelCommandLine=/varname
may be used to check whether a
diff --git a/src/core/condition.c b/src/core/condition.c
index 427aa08..7c62d11 100644
--- a/src/core/condition.c
+++ b/src/core/condition.c
@@ -124,6 +124,36 @@ static bool test_kernel_command_line(const char
*parameter) {
return found;
}
+static bool test_file_contains(const char *parameter) {
+int r;
+char *p;
+_cleanup_free_ char *path = NULL;
+_cleanup_free_ char *line = NULL;
+
+assert(parameter);
+
+path = strdup(parameter);
+if (!path) {
+log_oom();
+return false;
+}
+
+p = strchr(path, ':');
+if (!p)
+return false;
+
+*(p++) = '\0';
+
+r = read_one_line_file(path, line);
+
+if (r 0) {
+log_warning(Failed to read %s, ignoring: %s, path,
strerror(-r));
+return false;
+}
+
+return !!streq(line, p);
+}
+
static bool test_virtualization(const char *parameter) {
int b;
Virtualization v;
@@ -307,6 +337,9 @@ bool condition_test(Condition *c) {
return (S_ISREG(st.st_mode) (st.st_mode 0111)) ==
!c-negate;
}
+case CONDITION_FILE_CONTAINS:
+return test_file_contains(c-parameter) == !c-negate;
+
case CONDITION_KERNEL_COMMAND_LINE:
return test_kernel_command_line(c-parameter) == !c-negate;
@@ -392,6 +425,7 @@ static const char* const
condition_type_table[_CONDITION_TYPE_MAX] = {
[CONDITION_DIRECTORY_NOT_EMPTY] = ConditionDirectoryNotEmpty,
[CONDITION_FILE_NOT_EMPTY] = ConditionFileNotEmpty,
[CONDITION_FILE_IS_EXECUTABLE] = ConditionFileIsExecutable,
+[CONDITION_FILE_CONTAINS] = ConditionFileContains,
[CONDITION_KERNEL_COMMAND_LINE] = ConditionKernelCommandLine,
[CONDITION_VIRTUALIZATION] = ConditionVirtualization,
[CONDITION_SECURITY] = ConditionSecurity,
diff --git a/src/core/condition.h b/src/core/condition.h
index 50ed955..2bf26bd 100644
--- a/src/core/condition.h
+++ b/src/core/condition.h
@@ -35,6 +35,7 @@ typedef enum ConditionType {
CONDITION_DIRECTORY_NOT_EMPTY,
CONDITION_FILE_NOT_EMPTY,
CONDITION_FILE_IS_EXECUTABLE,
+CONDITION_FILE_CONTAINS,
CONDITION_KERNEL_COMMAND_LINE,
CONDITION_VIRTUALIZATION,
CONDITION_SECURITY,
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index 2325d6a..310e1c5 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -134,6 +134,7 @@ Unit.ConditionPathIsReadWrite,
config_parse_unit_condition_path, CONDITION_P
Unit.ConditionDirectoryNotEmpty, config_parse_unit_condition_path,
CONDITION_DIRECTORY_NOT_EMPTY, 0
Unit.ConditionFileNotEmpty,
Re: [systemd-devel] [RFC PATCH] condition: add ConditionFileContains=
On Thu, Jul 11, 2013 at 07:18:35PM +0200, Karol Lewandowski wrote:
Add ability to test if given file contains specified value.
File and expected value are given as one argument separated
by colon (:), i.e.
ConditionFileContains=/sys/module/sn/parameters/enabled:1
---
As above example suggests we use it to conditionally
start service based on kernel module parameter value.
This can be (ab)used for other/regular files too.
RFC
Thanks!
---
man/systemd.unit.xml |8
src/core/condition.c | 34
+
src/core/condition.h |1 +
src/core/load-fragment-gperf.gperf.m4 |1 +
4 files changed, 44 insertions(+)
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index 4f0bd64..d26bd23 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -841,6 +841,7 @@
termvarnameConditionDirectoryNotEmpty=/varname/term
termvarnameConditionFileNotEmpty=/varname/term
termvarnameConditionFileIsExecutable=/varname/term
+
termvarnameConditionFileContains=/varname/term
termvarnameConditionKernelCommandLine=/varname/term
termvarnameConditionVirtualization=/varname/term
termvarnameConditionSecurity=/varname/term
@@ -932,6 +933,13 @@
exists, is a regular file and marked
executable./para
+
paravarnameConditionFileContains=/varname
+may be used to check whether a given
+file contains specified value. The
+argument consists of file path to be
+tested, separator (:), and the
+expected value./para
+
paraSimilar,
varnameConditionKernelCommandLine=/varname
may be used to check whether a
diff --git a/src/core/condition.c b/src/core/condition.c
index 427aa08..7c62d11 100644
--- a/src/core/condition.c
+++ b/src/core/condition.c
@@ -124,6 +124,36 @@ static bool test_kernel_command_line(const char
*parameter) {
return found;
}
+static bool test_file_contains(const char *parameter) {
+int r;
+char *p;
+_cleanup_free_ char *path = NULL;
+_cleanup_free_ char *line = NULL;
+
+assert(parameter);
+
+path = strdup(parameter);
+if (!path) {
+log_oom();
+return false;
+}
+
+p = strchr(path, ':');
This is going to fail for a file:value pair such as /foo:/bar/baz:value.
You could use strrchr(), but then you have to be concerned about
matching values with a colon.
+if (!p)
+return false;
+
+*(p++) = '\0';
+
+r = read_one_line_file(path, line);
+
+if (r 0) {
+log_warning(Failed to read %s, ignoring: %s, path,
strerror(-r));
+return false;
+}
+
+return !!streq(line, p);
+}
+
static bool test_virtualization(const char *parameter) {
int b;
Virtualization v;
@@ -307,6 +337,9 @@ bool condition_test(Condition *c) {
return (S_ISREG(st.st_mode) (st.st_mode 0111)) ==
!c-negate;
}
+case CONDITION_FILE_CONTAINS:
+return test_file_contains(c-parameter) == !c-negate;
+
case CONDITION_KERNEL_COMMAND_LINE:
return test_kernel_command_line(c-parameter) == !c-negate;
@@ -392,6 +425,7 @@ static const char* const
condition_type_table[_CONDITION_TYPE_MAX] = {
[CONDITION_DIRECTORY_NOT_EMPTY] = ConditionDirectoryNotEmpty,
[CONDITION_FILE_NOT_EMPTY] = ConditionFileNotEmpty,
[CONDITION_FILE_IS_EXECUTABLE] = ConditionFileIsExecutable,
+[CONDITION_FILE_CONTAINS] = ConditionFileContains,
[CONDITION_KERNEL_COMMAND_LINE] = ConditionKernelCommandLine,
[CONDITION_VIRTUALIZATION] = ConditionVirtualization,
[CONDITION_SECURITY] = ConditionSecurity,
diff --git a/src/core/condition.h b/src/core/condition.h
index 50ed955..2bf26bd 100644
--- a/src/core/condition.h
+++ b/src/core/condition.h
@@ -35,6 +35,7 @@ typedef enum ConditionType {
CONDITION_DIRECTORY_NOT_EMPTY,
CONDITION_FILE_NOT_EMPTY,
CONDITION_FILE_IS_EXECUTABLE,
+CONDITION_FILE_CONTAINS,
CONDITION_KERNEL_COMMAND_LINE,
CONDITION_VIRTUALIZATION,
CONDITION_SECURITY,
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index
[systemd-devel] My last post went as unprocessed
My last post went as unprocessed. I checked my membership and it is current ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] My last post went as unprocessed
OK this post went through, so I am replying with the original text that was unprocessed: On my Angstrom distribution the sshd service is controlled by the file /lib/systemd/system/sshd@.service. What is the significance of the @ in the service name? This may be buried in documentation, but is very difficult to search for. My apologies if it is obvious. Best regards, Dave. Sorry for any confusion, but I am confused ;) On 13-07-11 02:46 PM, David Lambert wrote: My last post went as unprocessed. I checked my membership and it is current ___ 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
[systemd-devel] fstab Mounts Not Getting Waken Up
I'd understood that if a mount is in fstab, that it should be re-established when the system wakes. But that's not happening. Meaning two sshfs mounts as so: sshfs#carl@droog:/ /media/droog fuse user,auto,_netdev,gid=6,umask=007,cache=no,ServerAliveInterval=15,allow_other,comment=sshfs 0 0 Why would this be? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroups: chown user slices
Yeah, you need to set some env vars currently. The idea however is that the X/dbus libraries learn to look into XDG_RUNTIME_DIR on their own. I tried to make it work without success -- result is unusable. So, one of the issues - pam_systemd doesn't forward environment to child process. Without that things like pam_gnome_keyring (probably) can work only with awfull workarounds. Nobody needs to wait for systemd --user exits. It will just exist in the background as long as the user is logged in and will go away as soon as he logs out entirely. It is refernce counted by the login sessions. Second one is absence of following mode or so. So here is the problem: login manager forks Xsession initialization and terminates the greeter (and session) when it exits. If daemon running in background, some waiting mechainsm should be invented. And again, new environment should be propagated to shared instance (and if session stops, should be deinitialized). So, to migrate, either some new daemon should be written to do all that stuff, or dm managers should be reworked. Do we really need such complexity? Maybe old behavior can be offered as the option for those of us, who really uses user session, at least till the moment, when mainstream will be ready for migration? // Btw, there are some minor issues with proper deinitialization|stopping -- PID 1 rests in timeouts while shutdown.. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] My last post went as unprocessed
Thanks for your quick reply. I also notice a - preceding the target for ExecStart target. How does this work and where is it documented. Again very difficult to search :-[ Dave. [Unit] Description=OpenSSH Per-Connection Daemon After=sshdgenkeys.service [Service] ExecStart=-/usr/sbin/sshd -i ExecReload=/bin/kill -HUP $MAINPID StandardInput=socket StandardError=syslog On 13-07-11 03:08 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Jul 11, 2013 at 02:58:26PM -0500, David Lambert wrote: On my Angstrom distribution the sshd service is controlled by the file /lib/systemd/system/sshd@.service. What is the significance of the @ in the service name? @ means that it's a template unit. A separate instance of the sshd@.service unit will be created for each connections, called sshd@connection-1-details.service, sshd@connection-2-details.service, etc. Zbyszek This may be buried in documentation, but is very difficult to search for. My apologies if it is obvious. It's described in systemd.unit(5), but not very verbosely. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroups: chown user slices
On Thu, 11.07.13 23:20, Oleksii Shevchuk (alx...@gmail.com) wrote: Yeah, you need to set some env vars currently. The idea however is that the X/dbus libraries learn to look into XDG_RUNTIME_DIR on their own. I tried to make it work without success -- result is unusable. So, one of the issues - pam_systemd doesn't forward environment to child process. Without that things like pam_gnome_keyring (probably) can work only with awfull workarounds. pam_gnome_keyring needs to be in the pam stack for systemd-shared of course. (BTW, I figure we should rename the PAM service before this gets widely adopted. systemd-shared is not helpful...) Nobody needs to wait for systemd --user exits. It will just exist in the background as long as the user is logged in and will go away as soon as he logs out entirely. It is refernce counted by the login sessions. Second one is absence of following mode or so. So here is the problem: login manager forks Xsession initialization and terminates the greeter (and session) when it exits. If daemon running in background, some waiting mechainsm should be invented. And again, new environment should be propagated to shared instance (and if session stops, should be deinitialized). So, to migrate, either some new daemon should be written to do all that stuff, or dm managers should be reworked. Which environment would that be? For sockets and suchlike relying on $XDG_RUNTIME_PATH should be sufficient. Do we really need such complexity? Maybe old behavior can be offered as the option for those of us, who really uses user session, at least till the moment, when mainstream will be ready for migration? Well, you can still run systemd --user from inside the session if you chown the cgroupfs subtree first. // Btw, there are some minor issues with proper deinitialization|stopping -- PID 1 rests in timeouts while shutdown.. Can you elaborate? Where exactly does it hang? 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] My last post went as unprocessed
Am 11.07.2013 22:36, schrieb David Lambert: Thanks for your quick reply. I also notice a - preceding the target for ExecStart target. How does this work and where is it documented. Again very difficult to search :-[ the command is allowed to fail without failing the service it's common for EnvironemntFiles which are used if present and ignored if not in case of sshdgenkeys.service the way to go because the kyes must be generated at the first start but *must not* be overwritten at any later time [Unit] Description=OpenSSH Per-Connection Daemon After=sshdgenkeys.service [Service] ExecStart=-/usr/sbin/sshd -i ExecReload=/bin/kill -HUP $MAINPID StandardInput=socket StandardError=syslog 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] My last post went as unprocessed
On Thu, Jul 11, 2013 at 10:59:41PM +0200, Reindl Harald wrote: Am 11.07.2013 22:36, schrieb David Lambert: Thanks for your quick reply. I also notice a - preceding the target for ExecStart target. How does this work and where is it documented. Again very difficult to search :-[ See http://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStart= . the command is allowed to fail without failing the service it's common for EnvironemntFiles which are used if present and ignored if not Exactly. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cgroups: chown user slices
On Thu, 11.07.13 23:56, Oleksii Shevchuk (alx...@gmail.com) wrote: pam_gnome_keyring needs to be in the pam stack for systemd-shared of course. pam_gnome_keyring needs authinfo to unlock login keychain. Will that be passed to new systemd instance? Well, hmm, I am not sure how pam_gnome_keyring works exactly, but it shoudln#t be too hard for it to store the auth token somewhere so that it is accessible for all sessions of the same user. I'd recommend using the kernel keyring for these things btw. Which environment would that be? When systemd fully runs session, than that will be full profile environment + environment setted by login manager. For example, DM should setup DISPLAY variable. The X11 display is passed into the PAM session as parameter. logind knows that, and will managed a symlink in $XDG_RUNTIME_DIR to the display. What's missing though is that libx11 can actually deal with that. Can you elaborate? Where exactly does it hang? Some kind of debugging environment should be setted up before that. With shared user instance user@.service hangs alot. Sometimes session scopes rests in timeouts, when user session terminated without systemctl --user exit. Looks like logind/pam_systemd doesn't kill something. Hmm, Can you enable debug-shell.service, and then check from there what exactly is hanging, i.e. what the output of systemctl list-jobs is? I have some units in user session with KillMode=process. Maybe that matters So, my suspicion is that it might be bash that is hanging. It ignores SIGTERM and only dies on SIGHUP which the current scope code doesn't send. 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 PATCH] condition: add ConditionFileContains=
On Thu, 11.07.13 19:18, Karol Lewandowski (k.lewando...@samsung.com) wrote:
Add ability to test if given file contains specified value.
File and expected value are given as one argument separated
by colon (:), i.e.
ConditionFileContains=/sys/module/sn/parameters/enabled:1
Hmm, I don't like the naming. If this is called Contains I'd always
assume that it does substring matching or so?
Maybe ConditionFileContentsIs= or so?
I don#t really like the : as separator. Either = or a space sounds better.
+path = strdup(parameter);
+if (!path) {
+log_oom();
+return false;
+}
+
+p = strchr(path, ':');
+if (!p)
+return false;
+
+*(p++) = '\0';
I'd prefer if we'd have a path_is_absolute() check here, and immeidately
fail with a warning if the path isn't absolute.
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 PATCH] condition: add ConditionFileContains=
On Thu, 11.07.13 13:37, Dave Reisner (d...@falconindy.com) wrote: +p = strchr(path, ':'); This is going to fail for a file:value pair such as /foo:/bar/baz:value. You could use strrchr(), but then you have to be concerned about matching values with a colon. This might become a problem, but then again, I think it is OK if some files cannot be checked with this. I'd prefer using a space or = as separator as a better choice though, as that's probably less frequent than : in the names of files one would check with this condition setting. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: document the slice unit
On Thu, 11.07.13 04:47, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Thu, Jul 11, 2013 at 03:02:44AM +0200, Lennart Poettering wrote: On Wed, 10.07.13 02:23, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: --- Does this description fit the masterplan? What about units that systemd will expose for CPU and BlockIO shares, will they still be 1024 and 1000 based? Yes, they will. Thanks, this clarifies things. I think we could introduce additional syntax using %: CPUShares=15% But what do you do if the percentages don't add up to 100%? We'll probably have another setting CPUBudget= where you can specify a floating point value that specifies the maximum number of CPUs a cgroup can get as hard ceiling. i.e. you could specify CPUBudget=0.33 to grant a cgroup only 1/3 of one CPU at max. Or CPUBudget=3 to grant a cgroup access to full 3 CPUs of CPU time. 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] Forward systemd's sleep.target to a systemd user session
On Wed, 10.07.13 21:04, Jörg Thalheim (jo...@higgsboson.tk) wrote: How I can trigger sleep.target in systemd --user session? What precisely are you trying to do with this? Can I use systemctl --user only at a login shell and not in a systemd unit? Because using systemd --user from tty works great. You need access to the same bus socket. I am note sure how you set up dbus for your session. My use case is to logout my jabber client before suspend (I hope this does not sounds to trivial compared to your serious problems, but you might come up with other use cases). It's probably a better idea to patch the client to use a delay inhibitor for this: http://www.freedesktop.org/wiki/Software/systemd/inhibit/ This cannot be done in a normal .service file, because it does require a connection to the current dbus session. Well, systemctl --user needs that too, so you gain nothing... 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] Help getting serial console working again after upgrade to systemd?
On Wed, 10.07.13 11:26, Dmt Ops (ops...@gmail.com) wrote: Hey all, I'm starting upgrades to old production servers to newer 64-bit Linux that runs systemd = v195. Serial consoles are always my 1st step. Before upgrade it worked great. After upgrade, with the new systemd-based config, I'm not having much luck so far. Note that systemd will actually automatically spawn a serial getty on the serial port kernel logging is directed to. Normally you should not need to do anything. I configured the grub conf: serial --unit=0 --speed=57600 --word=8 --parity=no --stop=1 terminal --timeout=3 serial console title PRODUCTION root (hd0,0) kernel /vmlinuz root=/dev/sd1a noresume showopts x11failsafe vga=0x31a console=tty0 console=com1,vga That doesn't look right. With that setup I get nothing out the serial port. I probably have the grub cmd line wrong for using with systemd. I could use some help getting this untangled. Maybe the baud rate isn't right? Note that serial-getty@.service will try to reuse whatever was initialized by the kernel, hence make sure to configure the right parameters on the kernel console and you should be fine. 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] no installed machine-id vs systemd-in-initramfs
On Wed, 10.07.13 11:26, Colin Walters (walt...@verbum.org) wrote:
The gnome-ostree build system generates disk images that can be
downloaded directly; there is no installer.
In the old model of dracut shell script + systemd, systemd's main.c
has:
if (arg_running_as == SYSTEMD_SYSTEM ...) {
...
machine_id_setup();
...
}
machine_id_setup() will:
a) do nothing if /etc/machine-id is already valid
b) if it doesn't exist or is empty and the disk is writable, it will
create a new randomized one
c) if it exists but is empty and the disk is read-only it will mount the
file over with a randomized one from /run.
d) otherwise it will whine.
So after mounting the rootfs, we'd end up writing one to /etc (at least
in gnome-ostree which comes with a writable copy of /etc), and it would
persist across reboots, and all would be well with the world.
In the new systemd-in-initramfs model, journald is now launched in the
initramfs. Dracut will copy the host's machine id into the initramfs
if it exists, but in the gnome-ostree case (or more generally
pre-canned OS case), there isn't one. journald will attempt to start,
and fail.
I am pretty sure you should make use of c), i.e. create an empty stub
file in your initrd image and let systemd do its thing.
One thought I had is to say: If there's no /etc/machine-id in the
initramfs, write one to /run/machine-id. After mounting the rootfs,
persist that to /etc.
there's no need to use the same one really. It's good to use the same,
but we are OK if they aren't, after all they are sufficiently distinct
systems with a different file system tree and so on.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journal and /run/systemd/journal/syslog
On Wed, 10.07.13 12:30, Umut Tezduyar (u...@tezduyar.com) wrote: We though about just bumping this globally via sysctl, but we feared that might not sit well with some folks, as we shouldn't change a global setting just because one user of it would benefit, especially given that we don't know the effect this might have on others... I want to go this route and I think it is not possible at the moment due to undetermined start order between syslog.socket and systemd-sysctl.service. Can we change that? Hmm, are you saying that changing the sysctl value too late will have no effect on the sockets that already exist at that time? You could do this on your system: # mkdir /etc/systemd/system/syslog.socket.d/ # echo [Unit] After=systemd-sysctl.service /etc/systemd/system/syslog.socket.d/after-sysctl.conf Then, make the sysctl setting, and things should work? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] unit: check correct variable after strdup
On Tue, 09.07.13 15:45, Lukas Nykryn (lnyk...@redhat.com) wrote:
Applied all three! Thanks!
---
src/core/unit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/unit.c b/src/core/unit.c
index 447f201..b3f9832 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -2302,7 +2302,7 @@ int unit_deserialize(Unit *u, FILE *f, FDSet *fds) {
char *s;
s = strdup(v);
-if (!v)
+if (!s)
return -ENOMEM;
free(u-cgroup_path);
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 PATCH] condition: add ConditionFileContains=
On Fri, Jul 12, 2013 at 7:43 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 11.07.13 13:37, Dave Reisner (d...@falconindy.com) wrote: +p = strchr(path, ':'); This is going to fail for a file:value pair such as /foo:/bar/baz:value. You could use strrchr(), but then you have to be concerned about matching values with a colon. This might become a problem, but then again, I think it is OK if some files cannot be checked with this. I'd prefer using a space or = as separator as a better choice though, as that's probably less frequent than : in the names of files one would check with this condition setting. Lennart It's another question. the main goal of this patch is that supports conditional execution If some services are executed with given condition, it should check some conditions and execute different flow. if [ condition is 1 ]; then launch A service else if [ condition is 2 ]; then launch B service else launch C service current systemd scheme we have to prepare three service file. so can we make it only one service with some unit extension? IOW multipul unit support? [Unit] ... ConditionBlahBlah=1 [Unit] ... ConditionBlahBlah=2 [Unit] ... ConditionBlahBlah=!1 !2 or empty line Thank you, Kyungmin Park ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
