Re: [systemd-devel] Fedora 16 and upstart
On Sat, May 4, 2013 at 3:14 AM, Mirco Tischler mt...@gmx.de wrote: No this won't work. Systemd is not a shell. Simply write a bash script where you do all your stuff and then put that as the ExecStart line. Many shell built-ins have real execuables, too. Just run which on them. -- 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] Fedora NFS systemd units
Hi, Just trying to work out a few problems on our (Mageia's) NFS packages. As with a lot of things we often take the units from Fedora (we will soon have a nicer way to share units I hope - need to get release out the way before I can help and put my bit of the work into this tho'). However I'm a bit confused by the latest units. nfs-server.service:[Unit] nfs-server.service:Description=NFS Server nfs-server.service:Requires=proc-fs-nfsd.mount var-lib-nfs-rpc_pipefs.mount rpcbind.service nfs-server.service:Requires=nfs-idmap.service nfs-mountd.service nfs-rquotad.service nfs-server.service:After=network.target named.service nfs-server.service:[Service] nfs-server.service:Type=oneshot nfs-server.service:RemainAfterExit=yes nfs-server.service:StandardError=syslog+console nfs-server.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-server.service:ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-server.preconfig nfs-server.service:ExecStartPre=/usr/sbin/exportfs -r nfs-server.service:ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT nfs-server.service:ExecStartPost=-/usr/lib/nfs-utils/scripts/nfs-server.postconfig nfs-server.service:ExecStop=/usr/sbin/rpc.nfsd 0 nfs-server.service:ExecStopPost=/usr/sbin/exportfs -f nfs-server.service:[Install] nfs-server.service:WantedBy=multi-user.target This is the main server unit. It requires the idmap, mountd and rquotad services. It has After=named.service. Should this not be After=nss-lookup.target instead? Bind/named might not be the only thing that does name lookups after all and nss-lookup.target is meant to encapsulate this does it not? (e.g. ldap could factor in here). nfs-idmap.service:[Unit] nfs-idmap.service:Description=NFSv4 ID-name mapping daemon nfs-idmap.service:BindTo=nfs-server.service nfs-idmap.service:After=nfs-server.service nfs-idmap.service:[Service] nfs-idmap.service:Type=forking nfs-idmap.service:StandardError=syslog+console nfs-idmap.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-idmap.service:ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS nfs-idmap.service:[Install] nfs-idmap.service:WantedBy=nfs.target This unit is bound to nfs-server so it will follow it's start/stop cycle. Yet it is also wanted by nfs.target. What purpose does nfs.target actually serve here? Ditto for the mountd and rquotad units which are similarly structured. Also, It is my understanding (and feel free to correct me here) but nfs-idmap is often needed on client systems also? I'm sure I had to configure a client in the past to ensure idmap was running in order to avoid permissions problems and users getting mapped to the 65k uid that means nobody. I had to force this by setting NEEDS_IDMAP=yes in the old sysconfig file /etc/sysconfig/nfs-common (I'm pretty sure we had the same sysvinit setup as Fedora in the past). This being the case should idmap be enablable as an independent unit for client systems (same as nfs-lock.service). Again, feel free to correct me here if I'm wrong. If this is the case the BindTo would have to be dropped, but the Require could still be kept. The install rule would have to be made independant of nfs.target. To aid sysadmin clarity, it would make sense to have the nfs-server.service's [Install] section to have an Also= directive so that the relevant unit's enabled/disabled status's are shown more clearly to sysadmins. If mountd and rquotad make no sense to run separately then they should just have their [Install] sections nuked (more comments about rquoatad below tho'). nfs.target:[Unit] nfs.target:Description=Network File System Server nfs.target:Requires=var-lib-nfs-rpc_pipefs.mount proc-fs-nfsd.mount rpcbind.service nfs.target:After=network.target named.service nfs.target:[Install] nfs.target:WantedBy=multi-user.target If nfs.target is Network File Systemd Server, and the units are already set to be BindTo AND Require, then I really don't grok what nfs.target is for. It's not like it provides any additional level of isolation or configurability. In fact, enabling/disabling idmap, mountd and rquotad services will have no effect anyway due to them being requires/bound to nfs-server.service. Should this target just be dropped? nfs-rquotad.service:[Unit] nfs-rquotad.service:Description=NFS Remote Quota Server nfs-rquotad.service:BindTo=nfs-server.service nfs-rquotad.service:After=nfs-server.service nfs-rquotad.service:[Service] nfs-rquotad.service:Type=forking nfs-rquotad.service:StandardError=syslog+console nfs-rquotad.service:EnvironmentFile=-/etc/sysconfig/nfs nfs-rquotad.service:ExecStart=-/usr/sbin/rpc.rquotad $RPCRQUOTADOPTS nfs-rquotad.service:[Install] nfs-rquotad.service:WantedBy=nfs.target This package refers to a binary that is actually shipped in a different package (rpc.rquotad comes from the quota package). Shipping units in different packages to the binaries is pretty strange. Shouldn't this unit be renamed to rpc-rquotad.service and shipped instead in the quota
Re: [systemd-devel] [RFC PATCH] logs-show: print multiline messages
On Fri, 03.05.13 19:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Fri, May 03, 2013 at 06:51:35PM +0200, Lennart Poettering wrote: On Wed, 24.04.13 10:30, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: [0.019862] fedora kernel: CPU0: Thermal monitoring enabled (TM1) [0.019900] fedora kernel: Last level iTLB entries: 4KB 512, 2MB 0, 4MB 0 Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32 tlb_flushall_shift: 5 [0.020118] fedora kernel: Freeing SMP alternatives: 24k freed --- A beginning of support for multiline messages. Is this the right approach? (Not all formats are updated). Hmm, maybe a simpler approach regarding the expansion of \n would be to extend strip_tab_ansi() to take an additional string param for what to expand \n to? I think that would be a much simpler patch, no? We want to align fields, so it is necessary to split them on '\n'. Otherwise it'd look like [0.019862] fedora kernel: CPU0: Thermal monitoring enabled (TM1) [0.019900] fedora kernel: Last level iTLB entries: 4KB 512, 2MB 0, 4MB 0 Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32 tlb_flushall_shift: 5 [0.020118] fedora kernel: Freeing SMP alternatives: 24k freed which is definitely not pretty. Well, that's why I suggested to add a second param that specifies what \n shall be expanded to. In your example above you'd hence say that \n should be expanded to \n and you should be good? 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] systemd-delta: add support for drop-in snippets
---
TODO | 3 -
man/systemd-delta.xml | 7 +++
src/delta/delta.c | 170 ++
3 files changed, 164 insertions(+), 16 deletions(-)
diff --git a/TODO b/TODO
index 84ede8c..eab5f87 100644
--- a/TODO
+++ b/TODO
@@ -74,9 +74,6 @@ Features:
kmod static-nodes
call kmod as an early service, and drop CAP_MKNOD from udevd.service
-* systemd-delta needs to be made aware of *.d/*.conf drop-in files for
- units.
-
* seems that when we follow symlinks to units we prefer the symlink
destination path over /etc and /usr. We shouldn't do that. Instead
/etc should always override /run+/usr and also any symlink
diff --git a/man/systemd-delta.xml b/man/systemd-delta.xml
index 9293c9b..0c7a54a 100644
--- a/man/systemd-delta.xml
+++ b/man/systemd-delta.xml
@@ -141,6 +141,13 @@
/varlistentry
varlistentry
+
termvarnameextended/varname/term
+
+listitemparaShow
*.conf files in drop-in
+directories for
units./para/listitem
+/varlistentry
+
+varlistentry
termvarnameunchanged/varname/term
listitemparaShow
unmodified
diff --git a/src/delta/delta.c b/src/delta/delta.c
index aec3dc8..49cfc00 100644
--- a/src/delta/delta.c
+++ b/src/delta/delta.c
@@ -31,6 +31,7 @@
#include log.h
#include pager.h
#include build.h
+#include strv.h
static bool arg_no_pager = false;
static int arg_diff = -1;
@@ -41,9 +42,10 @@ static enum {
SHOW_REDIRECTED = 1 2,
SHOW_OVERRIDDEN = 1 3,
SHOW_UNCHANGED = 1 4,
+SHOW_EXTENDED = 1 5,
SHOW_DEFAULTS =
-(SHOW_MASKED | SHOW_EQUIVALENT | SHOW_REDIRECTED | SHOW_OVERRIDDEN)
+(SHOW_MASKED | SHOW_EQUIVALENT | SHOW_REDIRECTED | SHOW_OVERRIDDEN |
SHOW_EXTENDED)
} arg_flags = 0;
static int equivalent(const char *a, const char *b) {
@@ -92,6 +94,14 @@ static int notify_override_overridden(const char *top, const
char *bottom) {
return 1;
}
+static int notify_override_extended(const char *top, const char *bottom) {
+if (!(arg_flags SHOW_EXTENDED))
+ return 0;
+
+printf(ANSI_HIGHLIGHT_ON [EXTENDED] ANSI_HIGHLIGHT_OFF%s →
%s\n, top, bottom);
+return 1;
+}
+
static int notify_override_unchanged(const char *f) {
if (!(arg_flags SHOW_UNCHANGED))
return 0;
@@ -148,11 +158,114 @@ static int found_override(const char *top, const char
*bottom) {
return 0;
}
-static int enumerate_dir(Hashmap *top, Hashmap *bottom, const char *path) {
+static int enumerate_dir_d(Hashmap *top, Hashmap *bottom, Hashmap *drops,
const char *toppath, const char *drop) {
+_cleanup_free_ char *conf = NULL;
+_cleanup_free_ char *path = NULL;
+_cleanup_strv_free_ char **list = NULL;
+char **file;
+char *c;
+int r;
+
+path = strjoin(toppath, /, drop, NULL);
+if (!path)
+return -ENOMEM;
+
+path_kill_slashes(path);
+
+conf = strdup(drop);
+if (!conf)
+return -ENOMEM;
+
+c = strrchr(conf, '.');
+if(!c)
+return -EINVAL;
+*c = 0;
+
+r = get_files_in_directory(path, list);
+if (r 0){
+log_error(Failed to enumerate %s: %s, path, strerror(-r));
+return r;
+}
+
+STRV_FOREACH(file, list) {
+Hashmap *h;
+int k;
+char *p;
+char *d;
+
+if (!endswith(*file, .conf))
+continue;
+
+p = strjoin(path, /, *file, NULL);
+if (!p)
+return -ENOMEM;
+
+path_kill_slashes(p);
+
+d = strrchr(p, '/');
+if (!d || d == p) {
+free(p);
+return -EINVAL;
+}
+d --;
+d = strrchr(p, '/');
+
+if (!d || d == p) {
+free(p);
+return -EINVAL;
+}
+
+k = hashmap_put(top, d, p);
+if (k = 0) {
+p = strdup(p);
+if (!p)
+return -ENOMEM;
+d = strrchr(p, '/');
+d --;
+d = strrchr(p, '/');
+} else if (k != -EEXIST) {
+free(p);
+return k;
+
Re: [systemd-devel] Fedora NFS systemd units
On 05/06/2013 09:27 AM, Colin Guthrie wrote: Hi, Just trying to work out a few problems on our (Mageia's) NFS packages. As with a lot of things we often take the units from Fedora (we will soon have a nicer way to share units I hope - need to get release out the way before I can help and put my bit of the work into this tho'). However I'm a bit confused by the latest units. Steve did not pull in all the units a while back [1] ( which I had broken into special nfs target ) so I honestly expect nfs implemenation to be utterly broken ( as it used to be ) in Fedora + the units need to be rewritten and necessary changes done to dracut for root on nfs4 to work ( which I did not test or have in mind when creating them ). JBG 1. https://bugzilla.redhat.com/show_bug.cgi?id=769879 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Masking systemd-journal-flush and setting journal storage to persistent
Hi, I have masked the systemd-journal-flush.service and set the Storage=persistent in journald.conf. Then I have removed the /var/log/journal folder. My expectation on next boot was to see the journal files in /var/log/journal but they have stayed in /run/log/journal. According to man journald, it shouldn't be necessary to send the SIGUSR1 as systemd-journal-flush.service does. It was my expectation that systemd would eventually carry journal to /var/. I have tried this on systemd 202. The reason why I am fiddling with systemd-journal-flush.service is this service is taking quarter of a second (embedded system) of cpuacct even in Storage=auto and I think quarter of a second is big just to do nothing (Storage=auto). The only option for me is masking this service. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Patch to show systemd generators
Hi, Would you be interested in a patch that shows Systemd + Generators or maybe only Generators? Sample is attached. Thanks[image: Inline image 1] image.png___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2 v2] systemd-sleep: add support for freeze and standby
On Sat, 04.05.13 11:38, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: A new config file /etc/systemd/sleep.conf is added. It is parsed by systemd-sleep and logind. The strings written to /sys/power/disk and /sys/power/state can be configured. This allows people to use different modes of suspend on systems with broken or special hardware. Configuration is shared between systemd-sleep and logind to enable logind to answer the question can the system be put to sleep as correctly as possible without actually invoking the action. If the user configured systemd-sleep to only use 'freeze', but current kernel does not support it, logind will properly report that the system cannot be put to sleep. Looks good! Please commit! 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/1] RFC: Set the Default OOM Score from configuration file
On Sun, 05.05.13 18:08, Umut Tezduyar (u...@tezduyar.com) wrote: On Fri, May 3, 2013 at 4:58 PM, Lennart Poettering lenn...@poettering.netwrote: On Sun, 28.04.13 20:37, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, Should DefaultOOMScore= and DefaultLimit***= be really under [Manager]? Wouldn't it be better to have an [Exec] section. Or even have [Service], [Mount],.. sections that can give separate configuration per exec unit. Hmm, the fields without Default prefix are applied to PID1 itself, too, hence they definitely belong into [Manager] I'd say. For the ones prefix with Default, we could probably move them to a new section [Units] or so. But we'd probably have to do that in a compatible way, so this doesn't break existing systems. And that's not too nice. Not sure whether it is worth that effort? Also, there are many configuration options per exec units that are not in the system.conf. Are we open taking patches on completing missing configuration options? Actually, the last time I checked them there were only very few where a default in system.conf really makes sense I think. Which ones do you have in mind? Umut: I use ControlGroupPersistent= on one shot unit files to measure their cpuacct. I have a generator that adds ControlGroupPersistent dropins for oneshot service files when I want to measure the cpuacct. Maybe it would be nice to have a DefaultControlGroupPersistent=yes in .conf. I'd be very careful with that... This would mean that all cgroups created by instantiated services would stay around, for example those for each ssh connection. That would be very undesirable, as for each incoming connection you'd add more left-over cgroups. 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 to show systemd generators
On Mon, 06.05.13 14:00, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, Would you be interested in a patch that shows Systemd + Generators or maybe only Generators? Well, I guess it makes sense to show how much time is spent in the generators and how much time is spent in systemd's own unit file loading (especially given that the latter isn't particularly optimized yet...) 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 to show systemd generators
On Mon, May 6, 2013 at 2:51 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 06.05.13 14:00, Umut Tezduyar (u...@tezduyar.com) wrote: Would you be interested in a patch that shows Systemd + Generators or maybe only Generators? Well, I guess it makes sense to show how much time is spent in the generators and how much time is spent in systemd's own unit file loading (especially given that the latter isn't particularly optimized yet...) Maybe also split out the SELinux loading as that seems to take a lot of time? -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] kernel-install: add default 50-depmod.install script
On 04/30/2013 06:04 PM, har...@redhat.com wrote: From: Harald Hoyer har...@redhat.com Do the depmod in the kernel-install hooks, so hooks can produce/install kernel modules and be part of the depmod. --- Makefile.am | 7 --- src/kernel-install/50-depmod.install | 8 2 files changed, 12 insertions(+), 3 deletions(-) create mode 100644 src/kernel-install/50-depmod.install diff --git a/Makefile.am b/Makefile.am index ff70223..7fbec77 100644 pushed, including more changes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: fix typos in systemd.special
--- man/systemd.special.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/systemd.special.xml b/man/systemd.special.xml index 61d45ff..7164b1e 100644 --- a/man/systemd.special.xml +++ b/man/systemd.special.xml @@ -784,7 +784,7 @@ available at boot./para paraThis may be used to pull -in printer management +in smartcard management daemons dynamically when smartcard hardware is found./para @@ -801,7 +801,7 @@ paraThis may be used to pull in audio management daemons -dynamically when printer +dynamically when audio hardware is found./para /listitem /varlistentry -- 1.8.2.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] configure.ac: check if AM_PATH_LIBGCRYPT is a defined macro
Say Lennart prepares a new upstream release and forgot to install
libgcrypt-devel, then he silently produces a dist tarball which will
be broken.
I'm not sure I like that behaviour.
Michael
2013/5/6 Elia Pinto gitter.spi...@gmail.com:
To search the libgcrypt support the developer are advised
to use the automake macro AM_PATH_LIBGCRYPT. But if libgcrypt-devel
is not installed the macro does not exist yet and so
configure goes wrong. This patch test first whether the macro is defined,
and if not it set have_lgcrypt to false.
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
configure.ac | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 285fc44..688e393 100644
--- a/configure.ac
+++ b/configure.ac
@@ -454,12 +454,13 @@ AC_ARG_ENABLE([gcrypt],
[have_gcrypt=auto])
if test x${have_gcrypt} != xno ; then
-AM_PATH_LIBGCRYPT(
-[1.4.5],
-[have_gcrypt=yes],
-[if test x$have_gcrypt = xyes ; then
+m4_ifdef([AM_PATH_LIBGCRYPT],
+ [AM_PATH_LIBGCRYPT(
+ [1.4.5],
+ [have_gcrypt=yes],
+ [if test x$have_gcrypt = xyes ; then
AC_MSG_ERROR([*** GCRYPT headers not found.])
-fi])
+ fi]],[have_gcrypt=no])
if test x$have_gcrypt = xyes ; then
GCRYPT_LIBS=$LIBGCRYPT_LIBS
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
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
Re: [systemd-devel] [PATCH] configure.ac: check if AM_PATH_LIBGCRYPT is a defined macro
On Mon, May 06, 2013 at 07:35:18PM +0200, Michael Biebl wrote: Say Lennart prepares a new upstream release and forgot to install libgcrypt-devel, then he silently produces a dist tarball which will be broken. I'm not sure I like that behaviour. It would be better to fix gcrypt to support pkg-config. We really don't want to special-case each and every library. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Question regarding Also= in [Install]
From the man page: Additional units to install when this unit is installed. If the user requests installation of a unit with this option configured, systemctl enable will automatically install units listed in this option as well. What also happens however is that it if systemctl disable is called it will also disable those units (certainly in my 195+patches build tho' I can't see anything obvious in git what would fix this). The docs imply it is one way and to actually be useful it's also sensible to have this one way (as otherwise you may as well uses BindTo and skip the whole [Install] section in one of the units). Any thoughts? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] configure.ac: check if AM_PATH_LIBGCRYPT is a defined macro
On Mon, 06.05.13 09:46, Elia Pinto (gitter.spi...@gmail.com) wrote: To search the libgcrypt support the developer are advised to use the automake macro AM_PATH_LIBGCRYPT. But if libgcrypt-devel is not installed the macro does not exist yet and so configure goes wrong. This patch test first whether the macro is defined, and if not it set have_lgcrypt to false. This is only relevant for git builds. For git builds there are a number of tools we don't explicitly check for such as autoconf itself for example. The autoconf checks otoh are only relevant for builds from tarballs. It is expected that you need more tools installed when building from git, and that you know which ones. That said, libgcrypt really shouldn't use their own macros for this, and rather just use pkg-config 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] configure.ac: check if AM_PATH_LIBGCRYPT is a defined macro
To search the libgcrypt support the developer are advised
to use the automake macro AM_PATH_LIBGCRYPT. But if libgcrypt-devel
is not installed the macro does not exist yet and so
configure goes wrong. This patch test first whether the macro is defined,
and if not it set have_lgcrypt to false.
Signed-off-by: Elia Pinto gitter.spi...@gmail.com
---
configure.ac | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 285fc44..688e393 100644
--- a/configure.ac
+++ b/configure.ac
@@ -454,12 +454,13 @@ AC_ARG_ENABLE([gcrypt],
[have_gcrypt=auto])
if test x${have_gcrypt} != xno ; then
-AM_PATH_LIBGCRYPT(
-[1.4.5],
-[have_gcrypt=yes],
-[if test x$have_gcrypt = xyes ; then
+m4_ifdef([AM_PATH_LIBGCRYPT],
+ [AM_PATH_LIBGCRYPT(
+ [1.4.5],
+ [have_gcrypt=yes],
+ [if test x$have_gcrypt = xyes ; then
AC_MSG_ERROR([*** GCRYPT headers not found.])
-fi])
+ fi]],[have_gcrypt=no])
if test x$have_gcrypt = xyes ; then
GCRYPT_LIBS=$LIBGCRYPT_LIBS
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fedora NFS systemd units
Le 06/05/2013 11:27, Colin Guthrie a écrit : Also, It is my understanding (and feel free to correct me here) but nfs-idmap is often needed on client systems also? I'm sure I had to configure a client in the past to ensure idmap was running in order to avoid permissions problems and users getting mapped to the 65k uid that means nobody. I had to force this by setting NEEDS_IDMAP=yes in the old sysconfig file /etc/sysconfig/nfs-common (I'm pretty sure we had the same sysvinit setup as Fedora in the past). We didn't :) I stole the nfs-common sysvinit script from Debian, to hide the complexity of the gazillion different daemons needed. AFAIK, Fedora always used single-executable-services. And indeed idmapd is needed both sides for NFSv4. -- Guillaume ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Masking systemd-journal-flush and setting journal storage to persistent
On Mon, 06.05.13 12:41, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, I have masked the systemd-journal-flush.service and set the Storage=persistent in journald.conf. Then I have removed the /var/log/journal folder. My expectation on next boot was to see the journal files in /var/log/journal but they have stayed in /run/log/journal. systemd-journal-flush.service will tell journald that /var is now available+writable and that it can now flush all data from /run to /var. If you mask that then of course nothing will be written to /var, because things are kept in /run for good. According to man journald, it shouldn't be necessary to send the SIGUSR1 as systemd-journal-flush.service does. It was my expectation that systemd would eventually carry journal to /var/. The man page is actually incorrect here. We changed that a while back from the implicit flush to an explicit flush to get rid of some races. 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] Masking systemd-journal-flush and setting journal storage to persistent
On Mon, 06.05.13 22:39, Lennart Poettering (lenn...@poettering.net) wrote: According to man journald, it shouldn't be necessary to send the SIGUSR1 as systemd-journal-flush.service does. It was my expectation that systemd would eventually carry journal to /var/. The man page is actually incorrect here. We changed that a while back from the implicit flush to an explicit flush to get rid of some races. I have fixed the man page now. Sorry for the confusion. 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] Question regarding Also= in [Install]
On Mon, 06.05.13 19:29, Colin Guthrie (gm...@colin.guthr.ie) wrote: From the man page: Additional units to install when this unit is installed. If the user requests installation of a unit with this option configured, systemctl enable will automatically install units listed in this option as well. What also happens however is that it if systemctl disable is called it will also disable those units (certainly in my 195+patches build tho' I can't see anything obvious in git what would fix this). The docs imply it is one way and to actually be useful it's also sensible to have this one way (as otherwise you may as well uses BindTo and skip the whole [Install] section in one of the units). enable and disable are supposed to be roughly symmetric. Or at least disable should always be able to undo what enable did (though might do a little bit more in some cases). This behaviour is absolutely crucial for package managers I am pretty sure. [Install] sections are about default installation suggestions, nothing else. With Also= the vendor can hence change what the default installation is, but the admin can ignore this entirely and choose with a few symlinks of his own what precisely he wants to enable and what not. BindTo= and suchlike are much stricter than this, since they are harder to override: the user actually has to copy the unit file and edit it for that... So, I am pretty sure we shouldn't alter the current behaviour of this. That said, I'd be open to merging a patch that makes interpretation of Also optional, for example via a --skip-also switch or so... 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: fix typos in systemd.special
On Mon, 06.05.13 15:32, Ross Lagerwall (rosslagerw...@gmail.com) wrote: Applied! Thanks! --- man/systemd.special.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/systemd.special.xml b/man/systemd.special.xml index 61d45ff..7164b1e 100644 --- a/man/systemd.special.xml +++ b/man/systemd.special.xml @@ -784,7 +784,7 @@ available at boot./para paraThis may be used to pull -in printer management +in smartcard management daemons dynamically when smartcard hardware is found./para @@ -801,7 +801,7 @@ paraThis may be used to pull in audio management daemons -dynamically when printer +dynamically when audio hardware is found./para /listitem /varlistentry 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] zsh_completion: complete only pids for systemd-coredumpctl
On Sun, 05.05.13 18:09, Daniel Wallace (danielwall...@gtmanfred.com) wrote: Instead of completing the whole line, which doesn't work, only complete the pid, but still show the whole line so the user can see which command was which. Thanks! Applied! 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 2/2 v2] systemd-sleep: add support for freeze and standby
On Mon, 06.05.13 14:26, Lennart Poettering (lenn...@poettering.net) wrote: On Sat, 04.05.13 11:38, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: A new config file /etc/systemd/sleep.conf is added. It is parsed by systemd-sleep and logind. The strings written to /sys/power/disk and /sys/power/state can be configured. This allows people to use different modes of suspend on systems with broken or special hardware. Configuration is shared between systemd-sleep and logind to enable logind to answer the question can the system be put to sleep as correctly as possible without actually invoking the action. If the user configured systemd-sleep to only use 'freeze', but current kernel does not support it, logind will properly report that the system cannot be put to sleep. Looks good! Please commit! Commited both! Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] util-linux logger vs systemd-cat
On Tue, 23.04.13 10:35, Colin Walters (walt...@verbum.org) wrote: I found myself in a situation recently where I wanted to log a message from a shell script that included MESSAGE_ID. As far as I can tell there's no utility binary for this. True. systemd ships systemd-cat which connects to the journal, but it doesn't have support for structured logging; it's just a way to conveniently stream textual output to the journal. But that's not useful to me in this context because in current GNOME-OSTree we already have gdm set up to log the session to the journal; what I want is the ability to output structured messages. util-linux has included a tool logger for a log time; it wraps syslog; better, it's more oriented for logging a single message, which is convenient for shell script as in this case. It certainly seems like it could make sense to add a command line switch like --struct=MESSAGE_ID=0ce153587afa4095832d233c17a88001 to logger. The transport used by systemd-cat doesn't really support structured messages. It opens a stream socket to journald, and actually passes the resulting fd as STDIN/STDOUT to the executed program, without staying around itself. systemd-cat foobar is hence much more efficient than foobar | logger... journald then takes the output it gets from there and simply splits it up on line-breaks and adds hostname/timestamp/yadda yadda to it... Or is there an existing tool for this I'm missing? Should systemd-cat support structured logging? I guess the fact that systemd-cat currently doesn't use the structured logging protocol is an implementation detail. And yeah, i guess it would make a ton of sense to extend it to send full structured 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] [RFC][PATCH] Escape unit name from udev
On Tue, 23.04.13 13:34, MUNEDA Takahiro (muneda.takah...@jp.fujitsu.com) wrote:
This patch escapes a unit name which was derived from udev.
Please imagine following udev rule.
ACTION==online|offline, TAG+=systemd,
ENV{SYSTEMD_WANTS}=muneda@%p.service
ACTION==online|offline, TAG+=systemd,
ENV{SYSTEMD_WANTS}=muneda@%r.service
ACTION==online|offline, TAG+=systemd,
ENV{SYSTEMD_WANTS}=muneda@%S.service
When unit name is derived from udev via
udev_device_get_property_value(), the name may contains '/' if
ENV{SYSTEMD_WANTS} has the udev options $devpath(%p), $root(%r), or
$sys(%S). However, '/' is a invalid char for unit name so processing
of this rule fails as Invalid argument with following message.
Apr 22 13:21:37 localhost systemd[1]: Failed to load device unit: Invalid
argument
Apr 22 13:21:37 localhost systemd[1]: Failed to process udev device event:
Invalid argument
This patch escapes those invalid chars in a unit name.
Tested with 202, and confirmed to apply cleanly on top of commit 195f8e36.
The patch looks OK I guess. I merged it now. I am not entirely sure
though that using the devpath as instance name is actually the best
choice... Kay?
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] wake from sleep on systemd timer
Hey list, Are there any plans to enable waking the system from sleep upon some timer events defined in systemd units? By no means it should wake up on every timer. But it should be able to wake the system for specially labelled timer units and after finishing them put the system back to sleep (except some user activity has been detected). My curiosity comes from the idea to have, for example, a backup job running each night. As an alternative I'd like systemd to catch up missed timers upon boot if they are labelled with some sort of importance and have not been run since the last successful schedule. Is that already possible? I know anachron has such capabilities, but since systemd has cron-like capabilities I'd rather like to completely move away from any sort of cron. As a rough idea, maybe that could be implemented by some sort of Type=dontmiss Type=catchup or similar... Thanks, Kai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] Escape unit name from udev
On Mon, May 6, 2013 at 11:12 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Tue, 23.04.13 13:34, MUNEDA Takahiro (muneda.takah...@jp.fujitsu.com)
wrote:
This patch escapes a unit name which was derived from udev.
Please imagine following udev rule.
ACTION==online|offline, TAG+=systemd,
ENV{SYSTEMD_WANTS}=muneda@%p.service
ACTION==online|offline, TAG+=systemd,
ENV{SYSTEMD_WANTS}=muneda@%r.service
ACTION==online|offline, TAG+=systemd,
ENV{SYSTEMD_WANTS}=muneda@%S.service
When unit name is derived from udev via
udev_device_get_property_value(), the name may contains '/' if
ENV{SYSTEMD_WANTS} has the udev options $devpath(%p), $root(%r), or
$sys(%S). However, '/' is a invalid char for unit name so processing
of this rule fails as Invalid argument with following message.
Apr 22 13:21:37 localhost systemd[1]: Failed to load device unit: Invalid
argument
Apr 22 13:21:37 localhost systemd[1]: Failed to process udev device event:
Invalid argument
This patch escapes those invalid chars in a unit name.
Tested with 202, and confirmed to apply cleanly on top of commit 195f8e36.
The patch looks OK I guess. I merged it now. I am not entirely sure
though that using the devpath as instance name is actually the best
choice... Kay?
Some devices can move around during runtime, the device number (dev_t,
ifindex) or the subsytem:devname is usually the better choice. A
bit like this:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/base/core.c#n1918
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd user instance
Hey list, I've built a server with systemd and it really worked out well. Fast booting (that means shorter maintenance times) and most important: Reliable service teardown and auto-restarts of crashed services. And yeah, I love the journal. I'm logging everything there. But now I want to (and need to) give some users cron-like abilities. I discovered that systemd supports user instances - perfect! So I enabled a session service for one user (actually, that's me): # sudo systemctl enable user@kakra.service But I cannot start it, and the user can neither. Starting it states in the journal: # sudo systemctl start user@kakra.service May 06 23:35:00 vweb002.jugendinfo.de systemd[1]: Starting User Manager for root... -- Subject: Unit user@kakra.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit user@kakra.service has begun starting up. May 06 23:35:00 vweb002.jugendinfo.de systemd[4438]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted -- Subject: Process /usr/lib/systemd/systemd could not be executed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/641257651c1b4ec9a8624d7a40a9e1e7 -- -- The process /usr/lib/systemd/systemd could not be executed and failed. -- -- The error number returned while executing this process is 1. May 06 23:35:00 vweb002.xx.de systemd[1]: Started User Manager for root. -- Subject: Unit user@kakra.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit user@kakra.service has finished starting up. -- -- The start-up result is done. Why does it say Starting user manager for root (and not my username) and why does it fail with pam? If I start systemd --user , then I can enable and run the user services defined in .config/systemd. The server is running Gentoo with systemd-201. Here's the systemd unit: kakra@vweb002 ~ $ cat /etc/systemd/system/user\@kakra.service # This file is part of systemd. # # 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. [Unit] Description=User Manager for %u After=systemd-user-sessions.service [Service] User=%I PAMName=systemd-shared # in order to allow MEM_CG features to work, add memory:/ here ControlGroup=%R/user/%u/shared cpu:/ ControlGroupModify=yes Type=notify ExecStart=-/usr/lib/systemd/systemd --user Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%U/dbus/user_bus_socket [Install] Alias=user@%i.service # as user: # systemctl start user@kakra.service Failed to issue method call: Access denied kakra@vweb002 ~ $ cat /etc/pam.d/system-auth authrequiredpam_env.so authrequiredpam_unix.so try_first_pass likeauth nullok authoptionalpam_permit.so account requiredpam_unix.so account optionalpam_permit.so passwordrequiredpam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 passwordrequiredpam_unix.so try_first_pass use_authtok nullok sha512 shadow passwordoptionalpam_permit.so session requiredpam_limits.so session requiredpam_env.so session requiredpam_unix.so session optionalpam_permit.so session optionalpam_loginuid.so session optionalpam_systemd.so Regards, Kai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user instance
On 05/06/2013 09:44 PM, Kai Krakow wrote: But now I want to (and need to) give some users cron-like abilities. I discovered that systemd supports user instances - perfect! Then install cronie... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] wake from sleep on systemd timer
Lennart Poettering lenn...@poettering.net schrieb: Are there any plans to enable waking the system from sleep upon some timer events defined in systemd units? By no means it should wake up on every timer. But it should be able to wake the system for specially labelled timer units and after finishing them put the system back to sleep (except some user activity has been detected). [...] We currently lack both features, but both of them are high up on our TODO list! Wow, cool, you guys really rock. I'm the first to test it. :-) Meanwhile, where's a good place to contribute my systemd unit files I created for different services that not yet seem to be covered by the systemd distribution? They could also need some review maybe... Regards, Kai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user instance
Jóhann B. Guðmundsson johan...@gmail.com schrieb: But now I want to (and need to) give some users cron-like abilities. I discovered that systemd supports user instances - perfect! Then install cronie... That's the obvious solution but a little bit counter-productive with respect to my question... Anyway, one has to take that route if everything else fails. Regards, Kai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd 203
Heya,
http://www.freedesktop.org/software/systemd/systemd-203.tar.xz
This is probably a good release to synchronize a distribution on. For
example, it is our goal that this is the version we will include in
Fedora 19, more or less. d systemd git otoh will probably receive more
invasive changes again in the next weeks, as we reopen major feature
development again. For example, I'd like to port over systemd from
libdbus1 to libsystemd-bus in the next weeks.
CHANGES WITH 203:
* systemd-nspawn will now create /etc/resolv.conf if
necessary, before bind-mounting the host's file onto it.
* systemd-nspawn will now store meta information about a
container on the container's cgroup as extended attribute
fields, including the root directory.
* The cgroup hierarchy has been reworked in many ways. All
objects any of the components systemd creates in the cgroup
tree are now suffixed. More specifically, user sessions are
now placed in cgroups suffixed with .session, users in
cgroups suffixed with .user, and nspawn containers in
cgroups suffixed with .nspawn. Furthermore, all cgroup
names are now escaped in a simple scheme to avoid collision
of userspace object names with kernel filenames. This work
is preparation for making these objects relocatable in the
cgroup tree, in order to allow easy resource partitioning of
these objects without causing naming conflicts.
* systemctl list-dependencies gained the new switches
--plain, --reverse, --after and --before.
* systemd-inhibit now shows the process name of processes that
have taken an inhibitor lock.
* nss-myhostname will now also resolve localhost
implicitly. This makes /etc/hosts an optional file and
nicely handles that on IPv6 ::1 maps to both localhost and
the local hostname.
* libsystemd-logind.so gained a new call
sd_get_machine_names() to enumerate running containers and
VMs (currently only supported by very new libvirt and
nspawn). sd_login_monitor can now be used to watch
VMs/containers coming and going.
* .include is not allowed recursively anymore, and only in
unit files. Usually it is better to use drop-in snippets in
.d/*.conf anyway, as introduced with systemd 198.
* systemd-analyze gained a new critical-chain command that
determines the slowest chain of units run during system
boot-up. It is very useful for tracking down where
optimizing boot time is the most beneficial.
* systemd will no longer allow manipulating service paths in
the name=systemd:/system cgroup tree using ControlGroup= in
units. (But is still fine with it in all other dirs.)
* There's a new systemd-nspawn@.service service file that may
be used to easily run nspawn containers as system
services. With the container's root directory in
/var/lib/container/foobar it is now sufficient to run
systemctl start systemd-nspawn@foobar.service to boot it.
* systemd-cgls gained a new parameter --machine to list only
the processes within a certain container.
* ConditionSecurity= now can check for apparmor. We still
are lacking checks for SMACK and IMA for this condition
check though. Patches welcome!
* A new configuration file /etc/systemd/sleep.conf has been
added that may be used to configure which kernel operation
systemd is supposed to execute when suspend, hibernate
or hybrid-sleep is requested. This makes the new kernel
freeze state accessible to the user.
* ENV{SYSTEMD_WANTS} in udev rules will now implicitly escape
the passed argument if applicable.
Contributions from: Auke Kok, Colin Guthrie, Colin Walters,
Cristian Rodríguez, Daniel Buch, Daniel Wallace, Dave Reisner,
Evangelos Foutras, Greg Kroah-Hartman, Harald Hoyer, Josh
Triplett, Kay Sievers, Lennart Poettering, Lukas Nykryn,
MUNEDA Takahiro, Mantas Mikulėnas, Mirco Tischler, Nathaniel
Chen, Nirbheek Chauhan, Ronny Chevalier, Ross Lagerwall, Tom
Gundersen, Umut Tezduyar, Ville Skyttä, Zbigniew
Jędrzejewski-Szmek
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] journalctl v202, loop endlessly
El 05/05/13 13:17, Sébastien Luttringer escribió: Hello, journcalctl --no-pager or journalctl | cat produce enless content by looping accross journal entries. The date in lines restart from the beginning when the end is reached. We have reports about this behaviour in openSUSE as well, the problem is that I cannot reproduce it, even with your sample journal files.. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user instance
I don't recommend spawning user instances of systemd just for their timer units to run. Each instance comes with a few MB of overhead, and you'll have no fun trying to spawn sessions in a way isolated from (but somehow integrated with) the PAM session initialization process. On Mon, May 6, 2013 at 3:14 PM, Kai Krakow hurikha...@gmail.com wrote: Jóhann B. Guðmundsson johan...@gmail.com schrieb: But now I want to (and need to) give some users cron-like abilities. I discovered that systemd supports user instances - perfect! Then install cronie... That's the obvious solution but a little bit counter-productive with respect to my question... Anyway, one has to take that route if everything else fails. Regards, Kai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd user instance
On Mon, May 6, 2013 at 2:44 PM, Kai Krakow hurikha...@gmail.com wrote: Hey list, I've built a server with systemd and it really worked out well. Fast booting (that means shorter maintenance times) and most important: Reliable service teardown and auto-restarts of crashed services. And yeah, I love the journal. I'm logging everything there. But now I want to (and need to) give some users cron-like abilities. I discovered that systemd supports user instances - perfect! So I enabled a session service for one user (actually, that's me): # sudo systemctl enable user@kakra.service But I cannot start it, and the user can neither. Starting it states in the journal: # sudo systemctl start user@kakra.service May 06 23:35:00 vweb002.jugendinfo.de systemd[1]: Starting User Manager for root... -- Subject: Unit user@kakra.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit user@kakra.service has begun starting up. May 06 23:35:00 vweb002.jugendinfo.de systemd[4438]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted -- Subject: Process /usr/lib/systemd/systemd could not be executed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/641257651c1b4ec9a8624d7a40a9e1e7 -- -- The process /usr/lib/systemd/systemd could not be executed and failed. -- -- The error number returned while executing this process is 1. May 06 23:35:00 vweb002.xx.de systemd[1]: Started User Manager for root. -- Subject: Unit user@kakra.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit user@kakra.service has finished starting up. -- -- The start-up result is done. Why does it say Starting user manager for root (and not my username) and why does it fail with pam? If I start systemd --user , then I can enable and run the user services defined in .config/systemd. The server is running Gentoo with systemd-201. Here's the systemd unit: kakra@vweb002 ~ $ cat /etc/systemd/system/user\@kakra.service # This file is part of systemd. # # 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. [Unit] Description=User Manager for %u After=systemd-user-sessions.service [Service] User=%I PAMName=systemd-shared ^^ this line is the cause of your problems, as the /etc/pam.d/systemd-shared file does not exist. # in order to allow MEM_CG features to work, add memory:/ here ControlGroup=%R/user/%u/shared cpu:/ ControlGroupModify=yes Type=notify ExecStart=-/usr/lib/systemd/systemd --user Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%U/dbus/user_bus_socket [Install] Alias=user@%i.service # as user: # systemctl start user@kakra.service Failed to issue method call: Access denied kakra@vweb002 ~ $ cat /etc/pam.d/system-auth authrequiredpam_env.so authrequiredpam_unix.so try_first_pass likeauth nullok authoptionalpam_permit.so account requiredpam_unix.so account optionalpam_permit.so passwordrequiredpam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 passwordrequiredpam_unix.so try_first_pass use_authtok nullok sha512 shadow passwordoptionalpam_permit.so session requiredpam_limits.so session requiredpam_env.so session requiredpam_unix.so session optionalpam_permit.so session optionalpam_loginuid.so session optionalpam_systemd.so You can copy /etc/pam.d/login to /etc/pam.d/systemd-shared, and then things should somewhat work. Additionally, you may want to copy the dbus user session service files from github.com/sofar/user-session-units to get user based dbus services working. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
