[systemd-devel] [PATCH] Typo fix in systemd.preset manpage
According to SYNOPSIS (and implementation) the preset files shall be named *.preset. However, the 'PRESET FILE FORMAT' section of the manpage tells something different, which is incorrect. Vivenzio Pagliari (1): Typo fix in systemd.preset manpage man/systemd.preset.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.4.6 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Typo fix in systemd.preset manpage
--- man/systemd.preset.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml index 2f9add8..b716401 100644 --- a/man/systemd.preset.xml +++ b/man/systemd.preset.xml @@ -106,7 +106,7 @@ one takes precedence over all others./para paraEach preset file shall be named in the style of -filenamelt;prioritygt;-lt;programgt;.conf/filename. Files +filenamelt;prioritygt;-lt;policy-namegt;.preset/filename. Files in filename/etc//filename override files with the same name in filename/usr/lib//filename and filename/run//filename. Files in filename/run//filename override files with the same -- 2.4.6 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Typo fix in systemd.preset manpage
Patchset imported to github. To create a pull request, one of the main developers has to initiate one via: https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:1437135133-9646-2-git-send-email-vivenzio.pagliari%40nokia.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Confusing journal information - journal size
On 17/07/15 13:31, Mantas Mikulėnas wrote: On Fri, Jul 17, 2015 at 2:13 PM, David Sommerseth dav...@redhat.com mailto:dav...@redhat.com wrote: Hi, I'm looking through some journals now, and even though I've seen it a few times I haven't thought about it until now. systemd-journal[1151]: Runtime journal is using 8.0M (max allowed 4.0G, trying to leave 4.0G free of 63.7G available → current limit 4.0G). Could this line be cleaned up so you don't have to look up a man page to try to figure out what this really means? Here's my uneducated guess and confusion of this line: * Runtime journal is using 8.0M - Okay, so currently the journal uses 8MB of disk-space. No problem. * max allowed 4.0G - Okay, so the journal should not grow beyond 4GB, makes sense. No problem. * trying to leave 4.0G free of 63.7G available - Uhm, what!? So it will grow until there is 4GB left on the filesystem? Not so okay. It chooses the /smallest/ limit, not largest. (Common sense...) For example, if you had only 5 GB space available, the journal would not grow beyond 1 GB. * current limit 4.0G - Ehh ... okay ... so make up your mind, please! So will the journal grow until 4GB or 59.7GB. This *is* it making up its mind: min(limit 1, limit 2) → resulting limit But then I looked into /var/log/journal ... # du --si -s /var/log/journal/ 4.3G /var/log/journal/ I do see that both system,journal and user-UID.journal are both 8.4MB, and from that I can guess what the log entry tried to tell me with Runtime journal ... but how is /that/ information useful for me, from a sys-admin point of view? Runtime here means /run, as opposed to persistent in /var. They have separately configurable limits, since /run is in RAM and /var is usually on disk. (Though, I'm not entirely sure what purpose the runtime journal even serves, when /var is available.) Fair enough. But you are missing my point. How this information is presented do require some detail knowledge of the journal. Don't think like a developer who have poked at the journal code. Think like a sys-admin who looks through the logs looking for issues. Then you want to have the answer straight in your face, not needing to go elsewhere to read about these things. In fact most admins will probably have forgotten what they were going to look for when they move their eyes of the log data. If it is considered important information, fine. But present it in a far more understandable way for those who just uses the journal. Right now, I'm not surprised if most sys-admins read that line as useless gibberish - Yeah, yeah, journal will waste some space on my drive. -- kind regards, David Sommerseth ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reason for setting runqueue to IDLE priority and side effects if this is changed?
Up to v206, the behavior of systemd was the following one: -- - the starter sends out a start request of a bench of applications (he requests a sequence of unit starts) If you want to control order of execution yourself, why do you not wait for each unit to start before submitting next request? The synchronization point is not 'Unit started' but 'Job started'. I'm searching for a good solution to detect that. So long story in advance. I've now two questions: - Am I causing any critical side effects when I'm increasing the run queue priority so that it is higher than the one of the dbus handling (which is NORMAL)? First tests showed that I can get back exactly the behavior we had before with that. - Might it still happen that situations are happening where the jobs are reordered even though I'm increasing the priority? - Is there any other good solution ensuring the order of job execution? systemd never promised anything about relative order of execution unless there is explicit dependency between units. So good solution is to put dependency in unit definitions. submit the whole bunch at once and let systemd sort the order. Understood and agreed ;) Dependency is not an option because the synchronization point is not 'Unit Started' but 'Job kicked off' for the sequence. The sync point 'Unit Started' is need for real dependencies. However, has anyone an opinion on the first idea? (increasing the priority) I'd be interested in side effects caused by this modification. Thx, Marko ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container
I have been having quite some trouble getting nspawn give me a shell
with proper job control in a CentOS 6.6 guest. The problem appears to be
that the nodes representing the std{out,err,in} fds in /proc are
malformed,
$ sudo strace -f -obad systemd-nspawn -D$(realpath centos6.5-amd64)
Spawning container centos6.5-amd64 on /home/ben/vm/centos6.5-amd64.
Press ^] three times within 1s to kill container.
Failed to create directory /home/ben/vm/centos6.5-amd64/sys/fs/selinux:
Read-only file system
Failed to create directory /home/ben/vm/centos6.5-amd64/sys/fs/selinux:
Read-only file system
/etc/localtime is not a symlink, not updating container timezone.
-bash: cannot set terminal process group (-1): Inappropriate ioctl for
device
-bash: no job control in this shell
-bash-4.1# ls -lh /proc/self/fd
total 0
lrwx-- 1 root root 64 Jul 17 04:14 0 - /7
lrwx-- 1 root root 64 Jul 17 04:14 1 - /7
lrwx-- 1 root root 64 Jul 17 04:14 2 - /7
lr-x-- 1 root root 64 Jul 17 04:14 3 - /proc/13/fd
Note that fds 0, 1, and 2 all point to a non-existent /7 file. I believe
this should instead point to /dev/pts/7, although strangely this does
not exist either despite /dev/pts being mounted. I am running a very
recent (4.1) kernel.
Am I correct in assuming that this is not expected behavior? What am I
missing here?
Cheers,
- Ben
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to debug this strange issue about systemd?
On Fri, 2015-07-17 at 06:55 +0300, Andrei Borzenkov wrote: В Wed, 15 Jul 2015 23:03:02 +0800 sean x...@suse.com пишет: Hi All: I am trying to test the latest upstream kernel, But i encounter a strange issue about systemd. When the systemd extracted from initrd image mounts the real root file system hda.img on /sysroot and changes root to the new directory, it can not found /sbin/init and /bin/sh. In fact, These two files exist in the hda.img. How to debug this issue? Why does not it enter emergency mode? If enter emergency mode, maybe this issue become easy. You can stop in dracut just before switch root step and examine environment. At this point root should already be mounted. Thanks very much! How to stop the booting process before switch root? qemu command line: qemu-kvm -D /tmp/qemu-kvm-machine.log -m 1024M -append root=UUID=20059b62-2542-4a85-80cf-41da6e0c1137 rootflags=rw rootfstype=ext4 debug debug_objects console=ttyS0,115200n8 console=tty0 rd.debug rd.shell=1 log_buf_len=1M systemd.unit=emergency.target systemd.log_level=debug systemd.log_target=console -kernel ./qemu_platform/bzImage -hda ./qemu_platform/hda.img -initrd ./qemu_platform/initrd-4.1.0-rc2-7-desktop+ -device e1000,netdev=network0 -netdev user,id=network0 -serial file:/home/sean/work/source/upstream/kernel.org/ttys0.txt ... sean@linux-dunz:~/work/source/upstream/kernel.org/qemu_platform sudo mount -o loop ./hda.img ./hda sean@linux-dunz:~/work/source/upstream/kernel.org/qemu_platform ls -l ./hda/sbin/init lrwxrwxrwx 1 sean users 26 Jul 14 22:49 ./hda/sbin/init - ../usr/lib/systemd/systemd Do you have separate /usr? No, Only one disk partition. sean@linux-dunz:~/work/source/upstream/kernel.org/qemu_platform ls -l ./hda/bin/sh lrwxrwxrwx 1 sean users 4 Oct 26 2014 ./hda/bin/sh - bash sean@linux-dunz:~/work/source/upstream/kernel.org/qemu_platform lsinitrd ./initrd-4.1.0-rc2-7-desktop+ |grep sbin\/init -rwxr-xr-x 1 root root 1223 Nov 27 2014 sbin/initqueue lrwxrwxrwx 1 root root 26 Jul 14 21:00 sbin/init - ../usr/lib/systemd/systemd sean@linux-dunz:~/work/source/upstream/kernel.org/qemu_platform lsinitrd ./initrd-4.1.0-rc2-7-desktop+ |grep bin\/sh lrwxrwxrwx 1 root root4 Jul 14 21:00 bin/sh - bash -- Sean. XinRong Fu Dedicate System Engineer SUSE x...@suse.com (P)+86 18566229618 line SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to debug this strange issue about systemd?
sean wrote on 17/07/15 09:33: On Fri, 2015-07-17 at 06:55 +0300, Andrei Borzenkov wrote: В Wed, 15 Jul 2015 23:03:02 +0800 sean x...@suse.com пишет: Hi All: I am trying to test the latest upstream kernel, But i encounter a strange issue about systemd. When the systemd extracted from initrd image mounts the real root file system hda.img on /sysroot and changes root to the new directory, it can not found /sbin/init and /bin/sh. In fact, These two files exist in the hda.img. How to debug this issue? Why does not it enter emergency mode? If enter emergency mode, maybe this issue become easy. You can stop in dracut just before switch root step and examine environment. At this point root should already be mounted. Thanks very much! How to stop the booting process before switch root? See man dracut and the Debugging dracut section. Also see man dracut.cmdline and the rd.break bits. HTHs Col -- Colin Guthrie colin(at)mageia.org 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] How to debug this strange issue about systemd?
On Fri, Jul 17, 2015 at 12:18 PM, Colin Guthrie co...@mageia.org wrote: sean wrote on 17/07/15 09:33: On Fri, 2015-07-17 at 06:55 +0300, Andrei Borzenkov wrote: В Wed, 15 Jul 2015 23:03:02 +0800 sean x...@suse.com пишет: Hi All: I am trying to test the latest upstream kernel, But i encounter a strange issue about systemd. When the systemd extracted from initrd image mounts the real root file system hda.img on /sysroot and changes root to the new directory, it can not found /sbin/init and /bin/sh. In fact, These two files exist in the hda.img. How to debug this issue? Why does not it enter emergency mode? If enter emergency mode, maybe this issue become easy. You can stop in dracut just before switch root step and examine environment. At this point root should already be mounted. Thanks very much! How to stop the booting process before switch root? See man dracut and the Debugging dracut section. Also see man dracut.cmdline and the rd.break bits. Was it not man dracut.kernel? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container
Note that devpts also supports multiple instances – the host /dev/pts is
not the same as the guest /dev/pts'en. So my guess is that your stdio is
attached to a pty from the *host*.
Not really sure how that breaks job control though.
Also, the fd symlinks are slightly magical; they can be followed and opened
even if readlink returns garbage. (For example, a socket fd or a pipe fd
wouldn't even *have* a path to return, yet the /proc symlink can be
opened.) So that again shouldn't cause problems.
On Fri, Jul 17, 2015, 11:27 Ben Gamari b...@smart-cactus.org wrote:
I have been having quite some trouble getting nspawn give me a shell
with proper job control in a CentOS 6.6 guest. The problem appears to be
that the nodes representing the std{out,err,in} fds in /proc are
malformed,
$ sudo strace -f -obad systemd-nspawn -D$(realpath centos6.5-amd64)
Spawning container centos6.5-amd64 on /home/ben/vm/centos6.5-amd64.
Press ^] three times within 1s to kill container.
Failed to create directory /home/ben/vm/centos6.5-amd64/sys/fs/selinux:
Read-only file system
Failed to create directory /home/ben/vm/centos6.5-amd64/sys/fs/selinux:
Read-only file system
/etc/localtime is not a symlink, not updating container timezone.
-bash: cannot set terminal process group (-1): Inappropriate ioctl for
device
-bash: no job control in this shell
-bash-4.1# ls -lh /proc/self/fd
total 0
lrwx-- 1 root root 64 Jul 17 04:14 0 - /7
lrwx-- 1 root root 64 Jul 17 04:14 1 - /7
lrwx-- 1 root root 64 Jul 17 04:14 2 - /7
lr-x-- 1 root root 64 Jul 17 04:14 3 - /proc/13/fd
Note that fds 0, 1, and 2 all point to a non-existent /7 file. I believe
this should instead point to /dev/pts/7, although strangely this does
not exist either despite /dev/pts being mounted. I am running a very
recent (4.1) kernel.
Am I correct in assuming that this is not expected behavior? What am I
missing here?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Odd /proc/$pid/fd symlinks in nspawn container
Mantas Mikulėnas graw...@gmail.com writes:
Note that devpts also supports multiple instances – the host /dev/pts is
not the same as the guest /dev/pts'en. So my guess is that your stdio is
attached to a pty from the *host*.
Not really sure how that breaks job control though.
Also, the fd symlinks are slightly magical; they can be followed and opened
even if readlink returns garbage. (For example, a socket fd or a pipe fd
wouldn't even *have* a path to return, yet the /proc symlink can be
opened.) So that again shouldn't cause problems.
Fair enough. In that case perhaps the lack of job control is due to,
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
Indeed looking at jobs.c, it seems that bash tries to move the fd for
its tty to a high number (255 in this case) and will then try using it
to set the terminal process group. I see this pretty clearly in the
strace output,
$ sudo systemd-nspawn -D$(realpath centos6.5-amd64) /usr/bin/strace -f --
bash -i
...
19617 dup2(3, 255) = 255
19617 close(3) = 0
19617 ioctl(255, TIOCGPGRP, [32695])= -1 ENOTTY (Inappropriate ioctl
for device)
19617 ioctl(255, TIOCGPGRP, [32695])= -1 ENOTTY (Inappropriate ioctl
for device)
19617 fstat(2, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 7), ...}) = 0
19617 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fb741b8c000
19617 write(2, bash: cannot set terminal proces..., 77) = 77
Note how both of the ioctls failed with ENOTTY, which according to the
tcgetpgrp manpage means,
The calling process does not have a controlling terminal, or it has one
but it is not described by fd, or, for tcsetpgrp(), this controlling
terminal is no longer associated with the session of the calling
process.
Why might this be the case? Does nspawn prevent the process from getting
a controlling tty?
Cheers,
- Ben
[1]
http://stackoverflow.com/questions/11821378/what-does-bashno-job-control-in-this-shell-mean
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Confusing journal information - journal size
Hi, I'm looking through some journals now, and even though I've seen it a few times I haven't thought about it until now. systemd-journal[1151]: Runtime journal is using 8.0M (max allowed 4.0G, trying to leave 4.0G free of 63.7G available → current limit 4.0G). Could this line be cleaned up so you don't have to look up a man page to try to figure out what this really means? Here's my uneducated guess and confusion of this line: * Runtime journal is using 8.0M - Okay, so currently the journal uses 8MB of disk-space. No problem. * max allowed 4.0G - Okay, so the journal should not grow beyond 4GB, makes sense. No problem. * trying to leave 4.0G free of 63.7G available - Uhm, what!? So it will grow until there is 4GB left on the filesystem? Not so okay. * current limit 4.0G - Ehh ... okay ... so make up your mind, please! So will the journal grow until 4GB or 59.7GB. But then I looked into /var/log/journal ... # du --si -s /var/log/journal/ 4.3G /var/log/journal/ I do see that both system,journal and user-UID.journal are both 8.4MB, and from that I can guess what the log entry tried to tell me with Runtime journal ... but how is /that/ information useful for me, from a sys-admin point of view? My point is ... you're providing too much information and you need to understand more underlying things about the journal. Simply state how much disk-space the journal uses now and how much it will grow. Period. Don't do any we can grow until size X, but decided to grow to Y instead information. And yes, I deliberately didn't look into any man pages or code this time. Because this is what I believe most sys-admins will do: guess. -- kind regards, David Sommerseth ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to debug this strange issue about systemd?
Andrei Borzenkov wrote on 17/07/15 10:22: On Fri, Jul 17, 2015 at 12:18 PM, Colin Guthrie co...@mageia.org wrote: sean wrote on 17/07/15 09:33: On Fri, 2015-07-17 at 06:55 +0300, Andrei Borzenkov wrote: В Wed, 15 Jul 2015 23:03:02 +0800 sean x...@suse.com пишет: Hi All: I am trying to test the latest upstream kernel, But i encounter a strange issue about systemd. When the systemd extracted from initrd image mounts the real root file system hda.img on /sysroot and changes root to the new directory, it can not found /sbin/init and /bin/sh. In fact, These two files exist in the hda.img. How to debug this issue? Why does not it enter emergency mode? If enter emergency mode, maybe this issue become easy. You can stop in dracut just before switch root step and examine environment. At this point root should already be mounted. Thanks very much! How to stop the booting process before switch root? See man dracut and the Debugging dracut section. Also see man dracut.cmdline and the rd.break bits. Was it not man dracut.kernel? dracut.kernel == dracut.cmdline here (the latter seems to be the preferred name as it's the title in the manpage) and indeed: lrwxrwxrwx 1 root root 19 Jun 5 17:11 /usr/share/man/man7/dracut.kernel.7.xz - dracut.cmdline.7.xz :) Col -- Colin Guthrie colin(at)mageia.org 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] Confusing journal information - journal size
On Fri, Jul 17, 2015 at 2:13 PM, David Sommerseth dav...@redhat.com wrote: Hi, I'm looking through some journals now, and even though I've seen it a few times I haven't thought about it until now. systemd-journal[1151]: Runtime journal is using 8.0M (max allowed 4.0G, trying to leave 4.0G free of 63.7G available → current limit 4.0G). Could this line be cleaned up so you don't have to look up a man page to try to figure out what this really means? Here's my uneducated guess and confusion of this line: * Runtime journal is using 8.0M - Okay, so currently the journal uses 8MB of disk-space. No problem. * max allowed 4.0G - Okay, so the journal should not grow beyond 4GB, makes sense. No problem. * trying to leave 4.0G free of 63.7G available - Uhm, what!? So it will grow until there is 4GB left on the filesystem? Not so okay. It chooses the /smallest/ limit, not largest. (Common sense...) For example, if you had only 5 GB space available, the journal would not grow beyond 1 GB. * current limit 4.0G - Ehh ... okay ... so make up your mind, please! So will the journal grow until 4GB or 59.7GB. This *is* it making up its mind: min(limit 1, limit 2) → resulting limit But then I looked into /var/log/journal ... # du --si -s /var/log/journal/ 4.3G /var/log/journal/ I do see that both system,journal and user-UID.journal are both 8.4MB, and from that I can guess what the log entry tried to tell me with Runtime journal ... but how is /that/ information useful for me, from a sys-admin point of view? Runtime here means /run, as opposed to persistent in /var. They have separately configurable limits, since /run is in RAM and /var is usually on disk. (Though, I'm not entirely sure what purpose the runtime journal even serves, when /var is available.) -- 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] Packaging systemd user-instance service files
Hi everyone, I'm currently transforming a network daemon to become a native ``Type=notify'' systemd service. This daemon uses native PulseAudio simple APIs for output. Due to the PulseAudio dependency, the service needs to run under the user session. Otherwise, all PulseAudio APIs [e.g. pa_simple_new()] returns a ``Connection Refused'' error. [1] Given the above, I've built the following service file: [Unit] Description=AirTunes Synchronous Audio Service [Service] Type=notify ExecStart=/usr/local/bin/shairport-sync [Install] WantedBy=default.target And the following snippet in the package Makefile.am: cp scripts/shairport-sync.service /usr/lib/systemd/user/ systemctl --user daemon-reload systemctl --user enable shairport-sync.service systemctl --user start shairport-sync.service As you can see, the service is properly installed under ``/usr/lib/systemd/user/'' to run under the systemd user instance. Now the problem is that the Makefile commands above run as root, and thus all the ``systemctl --user'' commands fail with: Failed to get D-Bus connection: Connection refused So, the question is, can I start ``systemctl --user daemon-reload'' and ``systemctl --user enable'' above in some form while the Makefile is run from root? Moreover, could the mechanism do so while also making the service available upon login for all current _and_ future machine users? Thanks a lot, Ahmed S. Darwish http://darwish.chasingpointers.com/ [1] https://github.com/mikebrady/shairport-sync/blob/master/audio_pulse.c ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Packaging systemd user-instance service files
On Fri, Jul 17, 2015 at 9:38 PM, Ahmed S. Darwish darwish...@gmail.com wrote: Hi everyone, I'm currently transforming a network daemon to become a native ``Type=notify'' systemd service. This daemon uses native PulseAudio simple APIs for output. Due to the PulseAudio dependency, the service needs to run under the user session. Otherwise, all PulseAudio APIs [e.g. pa_simple_new()] returns a ``Connection Refused'' error. [1] Given the above, I've built the following service file: [Unit] Description=AirTunes Synchronous Audio Service [Service] Type=notify ExecStart=/usr/local/bin/shairport-sync [Install] WantedBy=default.target And the following snippet in the package Makefile.am: cp scripts/shairport-sync.service /usr/lib/systemd/user/ systemctl --user daemon-reload systemctl --user enable shairport-sync.service systemctl --user start shairport-sync.service So the real problem is not that it *doesn't work*, but rather that it *shouldn't be done*. That makefile is mixing entirely separate things – installation (packaging), global configuration, and per-user configuration. (Not to mention the dangerous assumptions that 1) there's exactly one user logged in during installation, and 2) that they'll actually want to run the program right now...) As you can see, the service is properly installed under ``/usr/lib/systemd/user/'' to run under the systemd user instance. Now the problem is that the Makefile commands above run as root, and thus all the ``systemctl --user'' commands fail with: Failed to get D-Bus connection: Connection refused So, the question is, can I start ``systemctl --user daemon-reload'' and ``systemctl --user enable'' above in some form while the Makefile is run from root? No, but you don't need to. Just install the file to /usr/lib/systemd/user, and that's it. It'll be available to all users. If you want to forcefully enable the service for all users, then also symlink it into /usr/lib/systemd/user/default.target.wants/, which is almost exactly what `systemctl enable` does (except system-wide). That'll make it start on login for everyone. But the general rule is, do not start user-session processes from system tasks. -- 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] Packaging systemd user-instance service files
Hi Mantas, On Sat, Jul 18, 2015 at 12:17:51AM +0300, Mantas Mikulėnas wrote: On Fri, Jul 17, 2015 at 9:38 PM, Ahmed S. Darwish darwish...@gmail.com wrote: Hi everyone, I'm currently transforming a network daemon to become a native ``Type=notify'' systemd service. This daemon uses native PulseAudio simple APIs for output. Due to the PulseAudio dependency, the service needs to run under the user session. Otherwise, all PulseAudio APIs [e.g. pa_simple_new()] returns a ``Connection Refused'' error. [1] Given the above, I've built the following service file: [Unit] Description=AirTunes Synchronous Audio Service [Service] Type=notify ExecStart=/usr/local/bin/shairport-sync [Install] WantedBy=default.target And the following snippet in the package Makefile.am: cp scripts/shairport-sync.service /usr/lib/systemd/user/ systemctl --user daemon-reload systemctl --user enable shairport-sync.service systemctl --user start shairport-sync.service So the real problem is not that it *doesn't work*, but rather that it *shouldn't be done*. That makefile is mixing entirely separate things – installation (packaging), global configuration, and per-user configuration. This is a small github project, and you have to handle the standard `./confugre', `make' and `sudo make install' sequence out of the box. There's no fancy Debian or Fedora packages for it even yet. The per-use configuration part was forced upon us due to our dependency on native PulseAudio APIs; APIs which do not work except when our daemon is run from the same session PulseAudio is running from. (Not to mention the dangerous assumptions that 1) there's exactly one user logged in during installation, and 2) that they'll actually want to run the program right now...) Yes, `systemctl --user' is wrong and specific only to the current user, but that's why I was asking for an alernative, more generic, solution that will fit all users in the first place :-) As you can see, the service is properly installed under ``/usr/lib/systemd/user/'' to run under the systemd user instance. Now the problem is that the Makefile commands above run as root, and thus all the ``systemctl --user'' commands fail with: Failed to get D-Bus connection: Connection refused So, the question is, can I start ``systemctl --user daemon-reload'' and ``systemctl --user enable'' above in some form while the Makefile is run from root? No, but you don't need to. Just install the file to /usr/lib/systemd/user, and that's it. It'll be available to all users. If you want to forcefully enable the service for all users, then also symlink it into /usr/lib/systemd/user/default.target.wants/, which is almost exactly what `systemctl enable` does (except system-wide). That'll make it start on login for everyone. Excellent! `systemctl --user enable' always did the symbolic link under `$HOME/.config/systemd/user/'; I mistakenly thought that it must be done _only_ this way for each and every user. Now I understand; it seems it was done that way just not to affect other users of the system. It couldn't be done any other way due to the system permissions of /usr/lib/systemd/user But the general rule is, do not start user-session processes from system tasks. Having the service installed `per-user' was something that was unfortunately forced. I will still inspect what will happen when two logged-in users lead to two instances of the daemon running :-( Can we disable multiple instances of the daemon in a systemd-native way, even when the service is run per user? Yes, this question implies a possible problem in the design, but again, having the service per-user is the only choice we have so far. Thanks a lot Mantas for your help! Regards, Darwish ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
