[systemd-devel] [PATCH] units: user@.service: fix user bus path
--- units/u...@.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/units/u...@.service.in b/units/u...@.service.in index 3f8b59d..1deefb0 100644 --- a/units/u...@.service.in +++ b/units/u...@.service.in @@ -14,5 +14,5 @@ User=%I PAMName=systemd-user Type=notify ExecStart=-@rootlibexecdir@/systemd --user -Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket +Environment=DBUS_SESSION_BUS_ADDRESS=kernel:path=/dev/kdbus/%I-user/bus;unix:path=/run/user/%I/bus Slice=user-%i.slice -- 1.8.5.1.277.g0e0d235 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bus: PORTING-DBUS1: fix user bus path
--- src/libsystemd-bus/PORTING-DBUS1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libsystemd-bus/PORTING-DBUS1 b/src/libsystemd-bus/PORTING-DBUS1 index b8a6ff7..ca8f31c 100644 --- a/src/libsystemd-bus/PORTING-DBUS1 +++ b/src/libsystemd-bus/PORTING-DBUS1 @@ -516,7 +516,7 @@ connecting to the system bus: This will ensure that kdbus is preferred over the legacy AF_UNIX socket, but compatibility is kept. For the user bus use: - kernel:path=/dev/kdbus/$UID-system/bus;unix:path=$XDG_RUNTIME_DIR/bus + kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus With $UID replaced by the callers numer user ID, and $XDG_RUNTIME_DIR following the XDG basedir spec. -- 1.8.5.1.277.g0e0d235 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Code=exited, status=16 :: While Stopping
Hi, nbsp;nbsp;nbsp; I have written a systemd service script for one my daemons. The service is of Type=forking. When starting the service everything is working fine and I am getting status SUCCESS. But while I am stopping the service I am getting failed state error like code=exited, status=15. nbsp; nbsp; I read the man pages as well as googled for this code and status, but find any definitive explanation for this type of status. nbsp;nbsp; Could you please throw me some light on this why my service failing while stopping? Also please let me know where can I get some documentation on these status codes. Thanks in advance. Best regards, --Chinmay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Code=exited, status=16 :: While Stopping
On Fri, Dec 27, 2013 at 10:36 AM, Chinmay Mahata chinmay_mah...@rediffmail.com wrote: Hi, I have written a systemd service script for one my daemons. The service is of Type=forking. When starting the service everything is working fine and I am getting status SUCCESS. But while I am stopping the service I am getting failed state error like code=exited, status=15. I read the man pages as well as googled for this code and status, but find any definitive explanation for this type of status. Could you please throw me some light on this why my service failing while stopping? Also please let me know where can I get some documentation on these status codes. These status codes are returned by your daemon; they are not defined by systemd. My guess is that the daemon just does not know how to handle SIGTERM, and doesn't properly exit when receiving one. (This happens more often than you would think...) -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH RFC] namespace: make sure ReadWriteDirectories are actually writable
Currently adding directories to ReadWriteDirectories= only restores the
original mount flags. So e.g. setting ReadOnlyDirectories=/usr and
ReadWriteDirectories=/usr/local works as expected if the underlying file
system was writable. However, setting ReadWriteDirectories= has no effect
if the underlying file system is mounted read-only.
This patch changes that by explicitly remounting the bind mount.
---
Hi,
I'm no expert when it comes to mount flags or namespaces. In my use case
the rootfs is mounted read-only. I'd like to make it writeable for some
selected services. I can do this manually but it would be nicer to let
systemd do it for me. This works for me. I have no idea if there are better
ways to do this.
Regards,
Michael
src/core/namespace.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/core/namespace.c b/src/core/namespace.c
index 85147be..cc3ae51 100644
--- a/src/core/namespace.c
+++ b/src/core/namespace.c
@@ -188,6 +188,21 @@ static int make_read_only(BindMount *m) {
return 0;
}
+static int make_read_write(BindMount *m) {
+int r;
+
+assert(m);
+
+if (m-mode != READWRITE)
+return 0;
+
+r = mount(NULL, m-path, NULL, MS_REMOUNT|MS_REC, NULL);
+if (r 0 !(m-ignore errno == ENOENT))
+return -errno;
+
+return 0;
+}
+
int setup_namespace(
char** read_write_dirs,
char** read_only_dirs,
@@ -258,6 +273,9 @@ int setup_namespace(
r = make_read_only(m);
if (r 0)
goto fail;
+r = make_read_write(m);
+if (r 0)
+goto fail;
}
/* Remount / as the desired mode */
--
1.8.5.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] /etc/machine-id handling in a non-initrd / embedded environment ?!?!
Hi all, I'm using systemd for embedded devices. The kernel is compiled for the target and I don't need / use an initrd, as all device drivers are known beforehand and I like the faster boot speed. That means that / is mounted read-only when systemd starts. However, systemd (and also journald, as it uses machine_id_setup) has a handling of /etc/machine-id that doesn't fit here. In effect, systemd+journald won't run in a system where root is readonly at boot time and where no /run exists because no initrd did run. What happens currently? 1. It tries to open /etc/machine-id and fails, because at that point in time /etc isn't writable. 2. Then it tries to open /etc/machine-id readonly, but again fails, no machine-id there 3. Now it tries to generate a machine ID and tries to write it into /run/machine-id. Again this fails, because /run is still on the same partition as /, and it is still not writable. FAIL ! Wouldn't it be better to just generate the machine-id internally and pass it by environment/command-line/some-other-means to journald? And write it later, once root is writable? Sure, theoretically I could create the machine-id file beforehand. But when putting my image onto 50+ devices, I want to have one identical image that I deploy, that I can check via SHA1 ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix Type= reference
Thanks for the correction. -- Marcos 2013/12/27 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: On Fri, Dec 27, 2013 at 07:46:20AM +0200, Mantas Mikulėnas wrote: On Thu, Dec 26, 2013 at 11:01 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Dec 26, 2013 at 05:47:57PM -0200, Marcos Felipe Rasia de Mello wrote: Simple man page fix attached. Applied. It looks like the old version _was_ correct – the default value will be Type=dbus if the service has a BusName set. Suggested change: if neither Type= nor BusName= is specified True, fixed now. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/machine-id handling in a non-initrd / embedded environment ?!?!
I was in error about this:
3. Now it tries to generate a machine ID and tries to write it into
/run/machine-id. Again this fails, because /run is still on the same
partition as /, and it is still not writable. FAIL !
When there is no writable or readable /etc/machine-id, then it won't
even try to generate one, as this code here bails out with a return
-errno;:
fd = open(/etc/machine-id,
O_RDWR|O_CREAT|O_CLOEXEC|O_NOCTTY, 0444);
if (fd = 0)
writable = true;
else {
fd = open(/etc/machine-id,
O_RDONLY|O_CLOEXEC|O_NOCTTY);
if (fd 0) {
log_error(Cannot open /etc/machine-id: %m);
return -errno;
}
writable = false;
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/machine-id handling in a non-initrd / embedded environment ?!?!
On Fri, Dec 27, 2013 at 12:35 PM, Holger Schurig holgerschu...@gmail.com wrote: Hi all, I'm using systemd for embedded devices. The kernel is compiled for the target and I don't need / use an initrd, as all device drivers are known beforehand and I like the faster boot speed. That means that / is mounted read-only when systemd starts. However, systemd (and also journald, as it uses machine_id_setup) has a handling of /etc/machine-id that doesn't fit here. In effect, systemd+journald won't run in a system where root is readonly at boot time and where no /run exists because no initrd did run. What happens currently? 1. It tries to open /etc/machine-id and fails, because at that point in time /etc isn't writable. 2. Then it tries to open /etc/machine-id readonly, but again fails, no machine-id there The file can remain *empty*, but it should *exist*, because systemd will want to bind-mount /run/machine-id. 3. Now it tries to generate a machine ID and tries to write it into /run/machine-id. Again this fails, because /run is still on the same partition as /, and it is still not writable. FAIL ! No, the FAIL here – as you say – is that /run is not writable in the first place. The whole purpose of /run, AFAIK, is to be writable anytime even before root becomes writable, so a 'tmpfs' should be mounted there during early boot. If the initramfs doesn't do this, systemd itself will (as /run is listed in src/core/mount-setup.c). -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/machine-id handling in a non-initrd / embedded environment ?!?!
On Fri, Dec 27, 2013 at 11:35 AM, Holger Schurig holgerschu...@gmail.com wrote: I'm using systemd for embedded devices. The kernel is compiled for the target and I don't need / use an initrd, as all device drivers are known beforehand and I like the faster boot speed. That means that / is mounted read-only when systemd starts. However, systemd (and also journald, as it uses machine_id_setup) has a handling of /etc/machine-id that doesn't fit here. In effect, systemd+journald won't run in a system where root is readonly at boot time and where no /run exists because no initrd did run. What happens currently? 1. It tries to open /etc/machine-id and fails, because at that point in time /etc isn't writable. Just create it yourself when you compose your /. If that image is copied to more than one box and you want it randomized, place an empty file there. 2. Then it tries to open /etc/machine-id readonly, but again fails, no machine-id there Which is nothing we can fix in systemd code. It should be there. 3. Now it tries to generate a machine ID and tries to write it into /run/machine-id. Again this fails, because /run is still on the same partition as /, and it is still not writable. FAIL ! You should always mount a tmpfs as /run, it is not supposed to be the same as /. Omitting the /run tmpfs mount is not supported. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/machine-id handling in a non-initrd / embedded environment ?!?!
If I place an empty /etc/machine-id into the image, then /run/machine-id will be bind-mounted over it. But that file will be different whenever I boot. So obviously I want to save it, once my filesystem is fsck'd and mounted read-write. But if I do it like that ... umount /etc/machine-id cp /run/machine-id /etc/machine-id ... then and between step 1 and 2 some other process might fall on it's nose. I noticed that several systemd binaries directly access /etc/machine-id via sd_id128_get_machine(). That would mean a race condition, or? You should always mount a tmpfs as /run, it is not supposed to be the same as /. Omitting the /run tmpfs mount is not supported. Kay, you're replaying to my point 3. that I already have taken back :-) And no, I should *NOT* mount it --- how could I, without an initrd? I don't need to mount it, because systemd mounts it for me with one of the functions in src/core/mount-setup.c before calling machine_id_setup(). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Code=exited, status=16 :: While Stopping
On Fri, Dec 27, 2013 at 08:36:18AM -, Chinmay Mahata wrote: Hi, nbsp;nbsp;nbsp; I have written a systemd service script for one my daemons. The service is of Type=forking. When starting the service everything is working fine and I am getting status SUCCESS. But while I am stopping the service I am getting failed state error like code=exited, status=15. nbsp; nbsp; I read the man pages as well as googled for this code and status, but find any definitive explanation for this type of status. nbsp;nbsp; Could you please throw me some light on this why my service failing while stopping? Also please let me know where can I get some documentation on these status codes. Sounds like 15 is the status returned by you daemon. It should return 0 on sucess instead. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/machine-id handling in a non-initrd / embedded environment ?!?!
On Fri, Dec 27, 2013 at 1:44 PM, Holger Schurig holgerschu...@gmail.com wrote: If I place an empty /etc/machine-id into the image, then /run/machine-id will be bind-mounted over it. But that file will be different whenever I boot. So obviously I want to save it, once my filesystem is fsck'd and mounted read-write. But if I do it like that ... Yes, it's a privacy feature, it should do that: empty file -- random id. umount /etc/machine-id cp /run/machine-id /etc/machine-id ... then and between step 1 and 2 some other process might fall on it's nose. I noticed that several systemd binaries directly access /etc/machine-id via sd_id128_get_machine(). That would mean a race condition, or? Yes, you can mount the root block device to a different place a second time, and should be able to unlink the file and replace it, then umount the file on the real /, and all should be atomic. You should always mount a tmpfs as /run, it is not supposed to be the same as /. Omitting the /run tmpfs mount is not supported. Kay, you're replaying to my point 3. that I already have taken back :-) And no, I should *NOT* mount it --- how could I, without an initrd? I don't need to mount it, because systemd mounts it for me with one of the functions in src/core/mount-setup.c before calling machine_id_setup(). Yeah, I was replying to your /run is still on the same partition as / which sounded like you did something, what systemd itself makes sure would not happen. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/machine-id handling in a non-initrd / embedded environment ?!?!
On Fri, Dec 27, 2013 at 3:41 PM, Kay Sievers k...@vrfy.org wrote: Yes, you can mount the root block device to a different place a second time, and should be able to unlink the file and replace it, then umount the file on the real /, and all should be atomic. Nah, sorry, it probably fails with being busy when it's over-mounted. We would need to invent some other way to do this trickery when the system is already up and running. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/machine-id handling in a non-initrd / embedded environment ?!?!
Maybe sd_id128_get_machine() could try first to read /etc/machine-id and use that. If it doesn't exist, it could read /run/machine-id and use that. If that doesn't exist we're doomed *) That would allow some save-code like this (quick'n'dirty untested) [Unit] Description=Save machine-id After=systemd-remount-fs.service ConditionPathExists=!/etc/machine-id ConditionPathExists=/run/machine-id [Service] Type=oneshot RemainAfterExit=yes ExecStart=cp -a /run/machine-id /etc/machine-id *) Note that the systemd I use (v208) will not boot if /etc/machine-id (not even an empty one) doesn't exist. Or, maybe it boots, but because of huge timeouts takes 20 minutes or so. So probably /run/machine-id should always be written by machine_id_setup(), even when no empty /etc/machine-id exists. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/machine-id handling in a non-initrd / embedded environment ?!?!
On Fri, Dec 27, 2013 at 4:47 PM, Kay Sievers k...@vrfy.org wrote: On Fri, Dec 27, 2013 at 3:41 PM, Kay Sievers k...@vrfy.org wrote: Yes, you can mount the root block device to a different place a second time, and should be able to unlink the file and replace it, then umount the file on the real /, and all should be atomic. Nah, sorry, it probably fails with being busy when it's over-mounted. We would need to invent some other way to do this trickery when the system is already up and running. Bind mounts (`mount --bind /etc /mnt`) wouldn't fail, though. Or bind-mounting the old /etc/machine-id to /run/machine-id.real? -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] units: user@.service: fix user bus path
--- units/u...@.service.in | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/units/u...@.service.in b/units/u...@.service.in index 3f8b59d..7b7d52b 100644 --- a/units/u...@.service.in +++ b/units/u...@.service.in @@ -14,5 +14,9 @@ User=%I PAMName=systemd-user Type=notify ExecStart=-@rootlibexecdir@/systemd --user -Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket +m4_ifdef(`ENABLE_KDBUS', +Environment=DBUS_SESSION_BUS_ADDRESS=kernel:path=/dev/kdbus/%I-user/bus;unix:path=/run/user/%I/bus +,m4_dnl +Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/bus +)m4_dnl Slice=user-%i.slice -- 1.8.5.1.277.g0e0d235 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /etc/machine-id handling in a non-initrd / embedded environment ?!?!
On Fri, Dec 27, 2013 at 4:02 PM, Holger Schurig holgerschu...@gmail.com wrote: Maybe sd_id128_get_machine() could try first to read /etc/machine-id and use that. If it doesn't exist, it could read /run/machine-id and use that. If that doesn't exist we're doomed *) It's a simple defined 3rd party file API, not rules other than open() should be applied. This could work: - place an empty file in /etc/machine-id - systemd will create a random id and mount it over the empty file - you mount the root device a second time at /run/foo - you replace the *content* (not the inode) of /run/foo/etc/machine-id with the content of /etc/machine-id - with the next reboot, the content should be persistent and identical Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd.service(5): clarify behavior of SuccessExitStatus
The behavior of this is a little cryptic in that $MAINPID must exit as
a direct result of receiving a signal in order for a listed signal to
be considered a success condition.
---
man/systemd.service.xml | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 27f069f..c3a9307 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -737,7 +737,10 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}
constantSIGTERM/constant and
constantSIGPIPE/constant. Exit status
definitions can either be numeric exit
codes or termination signal names,
-separated by spaces. Example:
+separated by spaces. Signals will only
+be considered if the service does not implement
+a signal handler and exits as a direct result
+of receiving the signal. Example:
literalSuccessExitStatus=1 2 8
constantSIGKILL/constant/literal,
ensures that exit
codes 1, 2, 8 and the termination
--
1.8.5.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd.service(5): clarify behavior of SuccessExitStatus
On Fri, Dec 27, 2013 at 10:46:48AM -0500, Dave Reisner wrote:
The behavior of this is a little cryptic in that $MAINPID must exit as
a direct result of receiving a signal in order for a listed signal to
be considered a success condition.
---
man/systemd.service.xml | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 27f069f..c3a9307 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -737,7 +737,10 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}
constantSIGTERM/constant and
constantSIGPIPE/constant. Exit status
definitions can either be numeric exit
codes or termination signal names,
-separated by spaces. Example:
+separated by spaces. Signals will only
+be considered if the service does not
implement
+a signal handler and exits as a direct result
+of receiving the signal. Example:
literalSuccessExitStatus=1 2 8
constantSIGKILL/constant/literal,
ensures that exit
codes 1, 2, 8 and the termination
This is incorrect/misleading too. Normally you're supposed to have a
signal handler, do cleanup, uninstall the handler, and then signal
yourself again.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus: PORTING-DBUS1: fix user bus path
On Fri, 27.12.13 10:30, Mantas Mikulėnas (graw...@gmail.com) wrote: Applied this one. Thanks! --- src/libsystemd-bus/PORTING-DBUS1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libsystemd-bus/PORTING-DBUS1 b/src/libsystemd-bus/PORTING-DBUS1 index b8a6ff7..ca8f31c 100644 --- a/src/libsystemd-bus/PORTING-DBUS1 +++ b/src/libsystemd-bus/PORTING-DBUS1 @@ -516,7 +516,7 @@ connecting to the system bus: This will ensure that kdbus is preferred over the legacy AF_UNIX socket, but compatibility is kept. For the user bus use: - kernel:path=/dev/kdbus/$UID-system/bus;unix:path=$XDG_RUNTIME_DIR/bus + kernel:path=/dev/kdbus/$UID-user/bus;unix:path=$XDG_RUNTIME_DIR/bus With $UID replaced by the callers numer user ID, and $XDG_RUNTIME_DIR following the XDG basedir spec. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH RFC] namespace: make sure ReadWriteDirectories are actually writable
On Fri, Dec 27, 2013 at 10:18:30AM +0100, Michael Olbrich wrote: Currently adding directories to ReadWriteDirectories= only restores the original mount flags. So e.g. setting ReadOnlyDirectories=/usr and ReadWriteDirectories=/usr/local works as expected if the underlying file system was writable. However, setting ReadWriteDirectories= has no effect if the underlying file system is mounted read-only. This patch changes that by explicitly remounting the bind mount. This doesn't feel right. This means that running any service with ReadWriteDirectories set would mean mounting partitions rw. That would be a significant change of semantics for current users. I think you should have an fstab entry with the rw flag. You can use noauto and it won't be mounted by default, and systemd should mount it automatically for you if you start the service. It would be nice to mention the status quo in the documentation though. I'd be happy to take a patch for that. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] units: user@.service: fix user bus path
On Fri, 27.12.13 17:10, Mantas Mikulėnas (graw...@gmail.com) wrote: The service file needs to be turned into an m4 template first I figure. i.e. replaced by u...@.service.m4.in... Note that this in a way is a bit of an anachronism... In the long run everybody should just connect to the right address without needing an environment variable (except maybe XDG_RUNTIME_DIR as single entry point). However, I figure for the time being we will have to set this variable unconditionally, since libdbus won't find the bus otherwise. (And thinking about it I figure we might want to set it from pam_systemd, too, so that normal sessions get it too). --- units/u...@.service.in | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/units/u...@.service.in b/units/u...@.service.in index 3f8b59d..7b7d52b 100644 --- a/units/u...@.service.in +++ b/units/u...@.service.in @@ -14,5 +14,9 @@ User=%I PAMName=systemd-user Type=notify ExecStart=-@rootlibexecdir@/systemd --user -Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket +m4_ifdef(`ENABLE_KDBUS', +Environment=DBUS_SESSION_BUS_ADDRESS=kernel:path=/dev/kdbus/%I-user/bus;unix:path=/run/user/%I/bus +,m4_dnl +Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/bus +)m4_dnl Slice=user-%i.slice Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Control process
On Fri, 27.12.13 10:39, Marcos Felipe Rasia de Mello (marcos...@gmail.com) wrote: systemctl man page defines kill --kill-who=control as kill [..] the control process. What is this control process? ExecStartPre= processes? These are killed automatically before ExecStart= according to https://bugzilla.redhat.com/show_bug.cgi?id=818381 , right? control processes are the processes that systemd starts for a service that are not the main process. There can only be one control process and one main process at the same time at max. Control processes are basically all those mentioned in ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop=, ... In some cases also the one from ExecStart= if the daemon first has to double fork to become the main service process. kill --kill-who=control is particularly useful for ExecReload= or ExecStartPost= where you might have both a control and a main process running. It's even useful for ExecStartPre= since you might have started a process with that which forked a couple of times, and you explicitly just want to kill the original control process you forked, not the children. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] units: user@.service: fix user bus path
On Fri, Dec 27, 2013 at 06:02:37PM +0100, Lennart Poettering wrote: On Fri, 27.12.13 17:10, Mantas Mikulėnas (graw...@gmail.com) wrote: Applied. I guess that this wasn't even compile tested though :| The service file needs to be turned into an m4 template first I figure. i.e. replaced by u...@.service.m4.in... Done now. Note that this in a way is a bit of an anachronism... In the long run everybody should just connect to the right address without needing an environment variable (except maybe XDG_RUNTIME_DIR as single entry point). However, I figure for the time being we will have to set this variable unconditionally, since libdbus won't find the bus otherwise. (And thinking about it I figure we might want to set it from pam_systemd, too, so that normal sessions get it too). Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Control process
2013/12/27 Lennart Poettering lenn...@poettering.net: On Fri, 27.12.13 10:39, Marcos Felipe Rasia de Mello (marcos...@gmail.com) wrote: systemctl man page defines kill --kill-who=control as kill [..] the control process. What is this control process? ExecStartPre= processes? These are killed automatically before ExecStart= according to https://bugzilla.redhat.com/show_bug.cgi?id=818381 , right? control processes are the processes that systemd starts for a service that are not the main process. There can only be one control process and one main process at the same time at max. Control processes are basically all those mentioned in ExecStartPre=, ExecStartPost=, ExecReload=, ExecStop=, ... In some cases also the one from ExecStart= if the daemon first has to double fork to become the main service process. kill --kill-who=control is particularly useful for ExecReload= or ExecStartPost= where you might have both a control and a main process running. It's even useful for ExecStartPre= since you might have started a process with that which forked a couple of times, and you explicitly just want to kill the original control process you forked, not the children. Excellent. Thank you. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH RFC] namespace: make sure ReadWriteDirectories are actually writable
On Fri, Dec 27, 2013 at 05:52:16PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Dec 27, 2013 at 10:18:30AM +0100, Michael Olbrich wrote: Currently adding directories to ReadWriteDirectories= only restores the original mount flags. So e.g. setting ReadOnlyDirectories=/usr and ReadWriteDirectories=/usr/local works as expected if the underlying file system was writable. However, setting ReadWriteDirectories= has no effect if the underlying file system is mounted read-only. This patch changes that by explicitly remounting the bind mount. This doesn't feel right. This means that running any service with ReadWriteDirectories set would mean mounting partitions rw. That would be a significant change of semantics for current users. I think you should have an fstab entry with the rw flag. You can use noauto and it won't be mounted by default, and systemd should mount it automatically for you if you start the service. That doesn't help. I need it for the rootfs. This is for embedded systems. Most applications are not allowed to write to the rootfs. This can only be ensured if the rootfs is mounted read-only. If changing the semantics is not acceptable how about a new option like ForceReadWriteDirectories= or something like that? Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd.service(5): clarify behavior of SuccessExitStatus
On Fri, 27.12.13 17:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Fri, Dec 27, 2013 at 10:46:48AM -0500, Dave Reisner wrote:
The behavior of this is a little cryptic in that $MAINPID must exit as
a direct result of receiving a signal in order for a listed signal to
be considered a success condition.
---
man/systemd.service.xml | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 27f069f..c3a9307 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -737,7 +737,10 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}
constantSIGTERM/constant and
constantSIGPIPE/constant. Exit status
definitions can either be numeric exit
codes or termination signal names,
-separated by spaces. Example:
+separated by spaces. Signals will only
+be considered if the service does not
implement
+a signal handler and exits as a direct
result
+of receiving the signal. Example:
literalSuccessExitStatus=1 2 8
constantSIGKILL/constant/literal,
ensures that exit
codes 1, 2, 8 and the termination
This is incorrect/misleading too. Normally you're supposed to have a
signal handler, do cleanup, uninstall the handler, and then signal
yourself again.
We certainly don't do that in systemd... I never heard of that
suggestion, I must say. (Any link where this is suggested?) I must say
that Dave's addition sounded correct to me, even though you do have a
point that one can uninstall the signal handler and trigger the signal
again...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] autogen: add shortcut for running scan-build
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com scan-build is a static analyzer in llvm. As ususal static analyzers tend to mostly find theoretical bugs in software that has been in production for a while. For in-development code it can be useful to check if new issues is added as there is a chance to spot real problems before release. For systemd we are now down to 297 issues - the vast majority are false positives because the tool does not understand the cleanup attribute. Running clang's static analyzer scan-build is a bit messy. You have to run both configure and make inside the build-scan tool. To have an easy shortcut from autogen.sh I thus call both directly from it. This makes it different from the other options in autogen.sh. I chose 's' for static analysis. scan-build is in the package clang-analyzer on fedora. On fedora we also need to set --use-analyzer=/usr/bin/clang --- autogen.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/autogen.sh b/autogen.sh index 91df10a..b6d197d 100755 --- a/autogen.sh +++ b/autogen.sh @@ -65,6 +65,9 @@ elif [ x$1 = xa ]; then elif [ x$1 = xl ]; then ./configure CC=clang CFLAGS='-g -O0 -ftrapv -Wno-cast-align -Wno-gnu' --enable-kdbus $args make clean +elif [ x$1 = xs ]; then +scan-build --use-analyzer=/usr/bin/clang ./configure CFLAGS='-g -O0 -ftrapv' --enable-kdbus $args +scan-build --use-analyzer=/usr/bin/clang make else echo echo -- 1.8.4.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] autogen: add shortcut for building with clang
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com For a while I have been cleaning up warnings when building with clang. There are currently only two sources of warnings left: Wcast-align and Wgnu. I am not convinced that fixing up those up is feasible so I run with them disabled to spot regressions. E.g. clang is a bit more strict wrt to unused variables with the cleanup attribute and I have fixed a number of those since. Like the other options in autogen.sh I have a shortcut for clang as well. I use 'l' for llvm. --- autogen.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/autogen.sh b/autogen.sh index e6289b3..91df10a 100755 --- a/autogen.sh +++ b/autogen.sh @@ -62,6 +62,9 @@ elif [ x$1 = xg ]; then elif [ x$1 = xa ]; then ./configure CFLAGS='-g -O0 -Wsuggest-attribute=pure -Wsuggest-attribute=const -ftrapv' --enable-kdbus $args make clean +elif [ x$1 = xl ]; then +./configure CC=clang CFLAGS='-g -O0 -ftrapv -Wno-cast-align -Wno-gnu' --enable-kdbus $args +make clean else echo echo -- 1.8.4.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] libcap .pc file
Hi, Just a heads up that libcap now includes a pc file in version 2.23. https://git.kernel.org/cgit/linux/kernel/git/morgan/libcap.git/commit/?id=dfea7eba31e6d15e8a63f818bb4438340b70a8c9 (The commit message gives me way more credit than I deserve. Bryan Kadzban did all the work. I just herded cats) This makes the Minimal Builds page on the wiki out of date. It says: Note that the .pc file trick mentioned above currently doesn't work for libcap, since libcap doesn't provide a .pc file. We invite you to go ahead and post a patch to libcap upstream to get this corrected. We'll happily change our build system to look for that .pc file then. The page also says that dbus is a build time dependency which is of course not true any more. I guess it is too early to change both build system and wiki? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add SELinuxContext configuration item
From: Michael Scherer m...@zarb.org
This permit to let system administrators decide of the domain of a service.
This can be used with templated units to have each service in a différent
domain ( for example, a per customer database, using MLS or anything ),
or can be used to force a non selinux enabled system (jvm, erlang, etc)
to start in a different domain for each service.
---
man/systemd.exec.xml | 11 +++
src/core/dbus-execute.c | 1 +
src/core/execute.c| 27 +++
src/core/execute.h| 2 ++
src/core/load-fragment-gperf.gperf.m4 | 3 ++-
src/shared/exit-status.c | 3 +++
src/shared/exit-status.h | 3 ++-
7 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml
index 17748d4..d93de4c 100644
--- a/man/systemd.exec.xml
+++ b/man/systemd.exec.xml
@@ -931,6 +931,17 @@
/varlistentry
varlistentry
+termvarnameSELinuxContext=/varname/term
+
+listitemparaSet the SELinux context of the
+executed process. If set, this will override
the
+automated domain transition. However, the
policy
+still need to autorize the transition. See
+
citerefentryrefentrytitlesetexeccon/refentrytitlemanvolnum3/manvolnum/citerefentry
+for details./para/listitem
+/varlistentry
+
+varlistentry
termvarnameIgnoreSIGPIPE=/varname/term
listitemparaTakes a boolean
diff --git a/src/core/dbus-execute.c b/src/core/dbus-execute.c
index b79a456..d1b7c58 100644
--- a/src/core/dbus-execute.c
+++ b/src/core/dbus-execute.c
@@ -422,6 +422,7 @@ const sd_bus_vtable bus_exec_vtable[] = {
SD_BUS_PROPERTY(PrivateNetwork, b, bus_property_get_bool,
offsetof(ExecContext, private_network), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(SameProcessGroup, b, bus_property_get_bool,
offsetof(ExecContext, same_pgrp), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(UtmpIdentifier, s, NULL, offsetof(ExecContext,
utmp_id), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(SELinuxContext, s, NULL, offsetof(ExecContext,
selinux_context), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(IgnoreSIGPIPE, b, bus_property_get_bool,
offsetof(ExecContext, ignore_sigpipe), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(NoNewPrivileges, b, bus_property_get_bool,
offsetof(ExecContext, no_new_privileges), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(SystemCallFilter, au, property_get_syscall_filter,
0, SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/execute.c b/src/core/execute.c
index 6ae9a5e..2a6ceb4 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -47,6 +47,10 @@
#include security/pam_appl.h
#endif
+#ifdef HAVE_SELINUX
+#include selinux/selinux.h
+#endif
+
#include execute.h
#include strv.h
#include macro.h
@@ -1570,6 +1574,20 @@ int exec_spawn(ExecCommand *command,
goto fail_child;
}
}
+#ifdef HAVE_SELINUX
+if (context-selinux_context) {
+err =
security_check_context(context-selinux_context);
+if (err 0) {
+r = EXIT_SELINUX_CONTEXT;
+goto fail_child;
+}
+err = setexeccon(context-selinux_context);
+if (err 0) {
+r = EXIT_SELINUX_CONTEXT;
+goto fail_child;
+}
+}
+#endif
}
err = build_environment(context, n_fds, watchdog_usec, home,
username, shell, our_env);
@@ -1728,6 +1746,9 @@ void exec_context_done(ExecContext *c) {
free(c-utmp_id);
c-utmp_id = NULL;
+free(c-selinux_context);
+c-selinux_context = NULL;
+
free(c-syscall_filter);
c-syscall_filter = NULL;
}
@@ -2096,6 +2117,12 @@ void exec_context_dump(ExecContext *c, FILE* f, const
char *prefix) {
fprintf(f,
%sUtmpIdentifier: %s\n,
prefix, c-utmp_id);
+
+if (c-selinux_context)
+fprintf(f,
+%sSELinuxContext: %s\n,
+prefix, c-selinux_context);
+
}
void exec_status_start(ExecStatus *s, pid_t pid) {
diff --git a/src/core/execute.h b/src/core/execute.h
Re: [systemd-devel] [PATCH] systemd.service(5): clarify behavior of SuccessExitStatus
On Fri, Dec 27, 2013 at 09:09:21PM +0100, Lennart Poettering wrote:
On Fri, 27.12.13 17:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Fri, Dec 27, 2013 at 10:46:48AM -0500, Dave Reisner wrote:
The behavior of this is a little cryptic in that $MAINPID must exit as
a direct result of receiving a signal in order for a listed signal to
be considered a success condition.
---
man/systemd.service.xml | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 27f069f..c3a9307 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -737,7 +737,10 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}
constantSIGTERM/constant and
constantSIGPIPE/constant. Exit status
definitions can either be numeric exit
codes or termination signal names,
-separated by spaces. Example:
+separated by spaces. Signals will only
+be considered if the service does not
implement
+a signal handler and exits as a direct
result
+of receiving the signal. Example:
literalSuccessExitStatus=1 2 8
constantSIGKILL/constant/literal,
ensures that exit
codes 1, 2, 8 and the termination
This is incorrect/misleading too. Normally you're supposed to have a
signal handler, do cleanup, uninstall the handler, and then signal
yourself again.
We certainly don't do that in systemd... I never heard of that
suggestion, I must say. (Any link where this is suggested?) I must say
that Dave's addition sounded correct to me, even though you do have a
point that one can uninstall the signal handler and trigger the signal
again...
I suppose a9a305332b addresses both sides of this. Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/4] bus: driverd: don't remove twice a match from the list
match_free already does it
---
src/bus-driverd/bus-driverd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/bus-driverd/bus-driverd.c b/src/bus-driverd/bus-driverd.c
index 44172c4..b423420 100644
--- a/src/bus-driverd/bus-driverd.c
+++ b/src/bus-driverd/bus-driverd.c
@@ -129,10 +129,8 @@ static int match_new(Client *c, struct bus_match_component
*components, unsigned
first = hashmap_get(c-matches, m-match);
LIST_PREPEND(matches, first, m);
r = hashmap_replace(c-matches, m-match, first);
-if (r 0) {
-LIST_REMOVE(matches, first, m);
+if (r 0)
goto fail;
-}
m-client = c;
c-n_matches++;
--
1.8.5.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/4] bus: driverd: don't attempt to remove from empty list
---
src/bus-driverd/bus-driverd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/bus-driverd/bus-driverd.c b/src/bus-driverd/bus-driverd.c
index b423420..1fdea7e 100644
--- a/src/bus-driverd/bus-driverd.c
+++ b/src/bus-driverd/bus-driverd.c
@@ -90,10 +90,10 @@ static void match_free(Match *m) {
Match *first;
first = hashmap_get(m-client-matches, m-match);
-LIST_REMOVE(matches, first, m);
-if (first)
+if (first) {
+LIST_REMOVE(matches, first, m);
assert_se(hashmap_replace(m-client-matches,
m-match, first) = 0);
-else
+} else
hashmap_remove(m-client-matches, m-match);
m-client-n_matches--;
--
1.8.5.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
