Re: [systemd-devel] [PATCH 1/3] zsh-completion: add missing completions for machinectl
On Wed, 22.04.15 15:52, Lukas Rusak (loru...@gmail.com) wrote:
Appologies, I'm still getting used to this mailing list thing and using git
send-email
---
shell-completion/zsh/_machinectl | 84
+---
1 file changed, 70 insertions(+), 14 deletions(-)
diff --git a/shell-completion/zsh/_machinectl
b/shell-completion/zsh/_machinectl
index c666b7e..a81c5c7 100644
--- a/shell-completion/zsh/_machinectl
+++ b/shell-completion/zsh/_machinectl
@@ -1,5 +1,20 @@
#compdef machinectl
+__get_available_machines () {
+machinectl --no-legend list-images | awk '{print $1}' | {while read -r
a b; do echo $a; done;}
+}
+
+_available_machines() {
+local -a _machines
+_machines=(${(fo)$(__get_available_machines)})
+typeset -U _machines
+if [[ -n $_machines ]]; then
+_describe 'machines' _machines
+else
+ _message 'no machines'
+fi
+}
For this to be fully correct, you need to distuingish images and
machines.
Basically, machines are runtime objects, instances of containers
currently running. images are files or directories on disk. You can
run multiple machines off the same image (by use --read-only or
--ephemeral).
Other container/VM managers like libvirt-lxc also register their
running containers with machined as machines, even though the backing
images of those machines might not be visible to machined.
Usually you run a machine from an image that carries the same name as
the image, but that's not a requirement really.
Some of machinectl's commands operate on images, others on running
containers...
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 1/3] zsh-completion: add missing completions for machinectl
On Thu, Apr 23, 2015 at 04:44:01PM +0200, Lennart Poettering wrote:
On Thu, 23.04.15 13:06, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Wed, Apr 22, 2015 at 12:30:32PM -0700, Lukas Rusak wrote:
Ah, completely missed images. So perhaps something like this would be
better?
machinectl --full --no-legend --no-pager list-images | awk '{print $1}'
We usually try to avoid running external programs unless necessary. This
can be implemented in pure shell which should be slightly faster.
Well, it's not that easy, since machined actually searches multiple
directories, ignores certain hidden files, drops .raw suffixes and
suchlike. Of course, you can replicate all that in shell, or you can
avoid it...
I was only talking about using awk to seperate the first word!
I think you can ignore spaces for now. This is just tab completion after
all,
it doesn't have to be bullet proof, and using spaces in image names would be
fairly exotic.
We don't support that in machined anyway.
Perfect.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: document kill behavior after the main process exits
On Thu, 23.04.15 09:20, Daniel Drake (dr...@endlessm.com) wrote: -timeout, if the normal shutdown procedure left processes of -the service around. Takes a boolean value. Defaults to yes. +timeout, if the normal shutdown procedure didn't succeed in +shutting down the main process. Takes a boolean value. +Defaults to yes. I think this really should clarify that this is about leaving processes around. /para/listitem /varlistentry @@ -163,6 +164,31 @@ /refsect1 refsect1 +titleBeyond the main process/title + + paraThe varnameKillMode=/varname option primarily defines + behavior up until the point where the main process has gone away. + systemd expects that when killed with the signal specified by + varnameKillSignal=/varname, the main process will kill and + reap all the other processes in the control group before + exiting itself. Well, I don't think this is right. I mean, systemd doesn't really expect this. It's completely OK if daemons leave children around in this case. KillMode= is actually very much about the time after the main process died. If KillMode=process is specified systemd should not send any signal to anything but the main process, and that applies to both SIGTERm and the following SIGKILL: If that doesn't happen, and the main process + exits with other processes still running in the control group, + systemd gets a bit more heavy-handed:/para I'd prefer not using words like heavy-handed here. + + paraIf optionKillMode=control-group/option, systemd will + then send a second varnameKillSignal=/varname signal to the + remaining processes, which will then be followed by a + constantSIGKILL/constant if processes are still around, even + if optionSendSIGKILL=no/option./para Hmm, no? SendSIGKILL=no should have the effect of not sending any SIGKILL at all. Anything else would be a bug. + + paraOr, if optionKillMode=mixed/option, systemd will + directly send constantSIGKILL/constant to all remaining members + of the control group, regardless of the + varnameSendSIGKILL=/varname preference./para Hmm? No, not at all. If you use mixed, then SIGTERM is is sent to the main process of the daemon, and SIGKILL to *al* processes of the daemon if there are any left after the main process exited. 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] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
В Thu, 23 Apr 2015 16:57:09 +0200 Lennart Poettering lenn...@poettering.net пишет: On Thu, 23.04.15 06:41, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Thu, 23 Apr 2015 00:48:38 +0200 Lennart Poettering lenn...@poettering.net пишет: On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote: Sorry for the late review. What's the precise background of this? Can you elaborate? Is there some feature request for this? There are multiple bug reports that switching to dracut with integrated systemd breaks ability to auto-setup encrypted devices using keyfile on external USB stick. Hmm, but from Jan's mail I got the impression that this is a Dracut feature in the first place? Now I am confused? Which initrd implementations supported this scheme before? Dracut supported it. When it implemented native systemd in intird, it lost this feature. You can get it back building initrd without systemd dracut module. What does this actually do? Is the specified key file read from the specified device? It reads keyfile from filesystem on device identifed by keyfile_device. The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? keyfile is mandatory, keyfile_device is optional and can be omitted. I believe dracut looked at all existing devices then. This order makes it easier to omit optional parameter(s). Well, whether it is [device:]file or file[:device] is hardly any difference for the parser... Does it really matter? Is this specific to Dracut so far? Is this widely used, and something that we really want. I can say about dracut only but yes, it is used and it is serious regression when it is used comparing with pre-systemd version. Can you point me to documentation about the previous features in this regard? Which initrd implementations are you referring to? Sure, in dracut manual page: crypto LUKS - key on removable device support rd.luks.key=keypath:keydev:luksdev keypath is a path to key file to look for. It’s REQUIRED. When keypath ends with .gpg it’s considered to be key encrypted symmetrically with GPG. You will be prompted for password on boot. GPG support comes with crypt-gpg module which needs to be added explicitly. keydev is a device on which key file resides. It might be kernel name of devices (should start with /dev/), UUID (prefixed with UUID=) or label (prefix with LABEL=). You don’t have to specify full UUID. Just its beginning will suffice, even if its ambiguous. All matching devices will be probed. This parameter is recommended, but not required. If not present, all block devices will be probed, which may significantly increase boot time. If luksdev is given, the specified key will only be applied for that LUKS device. Possible values are the same as for keydev. Unless you have several LUKS devices, you don’t have to specify this parameter. The simplest usage is: Example. rd.luks.key=/foo/bar.key As you see, you can skip colons in such a case. First version of the patch that allows rd.luks.key to be specified almost the same way as dracut can read it. The solution creates a temporary mount unit mnt.mount that the generated cryptsetup service wants. The partition where the keyfile is then mounted to /mnt and the absolute path to the keyfile is changed so it points to this temporary mount instead. Well, I'd place this in /run somewhere. Maybe /run/systemd/cryptsetup/mount or so... I'm not sure if temporarily mounting something to /mnt in initrd is safe. If not, what would be a preffered way to do this? What does temporarily mean? When is this unmounted? To fetch keyfile dracut needs to mount USB stick. This mount is not normally needed after cryptomount setup is completed. Well, sure, I am just wondering what precisely shall be used as trigger to unmount it again. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 4/8] update TODO
On Fri, 20.02.15 14:31, Shawn Landden (sh...@churchofgit.com) wrote: --- TODO | 2 ++ 1 file changed, 2 insertions(+) diff --git a/TODO b/TODO index 52a32d3..bf66ba1 100644 --- a/TODO +++ b/TODO @@ -32,6 +32,8 @@ External: * When lz4 gets an API for lz4 command output, make use of it to compress coredumps in a way compatible with /usr/bin/lz4. +* Fix emacs for Lennart so we can get rid of the Makefile hack littering git Well, emacs or not, it's useful if you can just type make in any of the systemd dirs, and the right thing happens... 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] man: document kill behavior after the main process exits
On Thu, Apr 23, 2015 at 9:32 AM, Lennart Poettering lenn...@poettering.net wrote: +titleBeyond the main process/title + + paraThe varnameKillMode=/varname option primarily defines + behavior up until the point where the main process has gone away. + systemd expects that when killed with the signal specified by + varnameKillSignal=/varname, the main process will kill and + reap all the other processes in the control group before + exiting itself. Well, I don't think this is right. I mean, systemd doesn't really expect this. It's completely OK if daemons leave children around in this case. I could avoid the word expect but I think it's worth mentioning as those discarded children might not be designed to accept 2 SIGTERMs in normal conditions. For example, any child process that uses glib and exits the mainloop from the SIGTERM handler does not really respond well here - it drops the SIGTERM handler after the first one, so the second SIGTERM will cause an immediate/unclean shutdown, which is not completely OK from the view of the child. KillMode= is actually very much about the time after the main process died. If KillMode=process is specified systemd should not send any signal to anything but the main process, and that applies to both SIGTERm and the following SIGKILL: I agree, which is why I specifically only talk about the cgroup/mixed kill modes. + paraIf optionKillMode=control-group/option, systemd will + then send a second varnameKillSignal=/varname signal to the + remaining processes, which will then be followed by a + constantSIGKILL/constant if processes are still around, even + if optionSendSIGKILL=no/option./para Hmm, no? SendSIGKILL=no should have the effect of not sending any SIGKILL at all. Anything else would be a bug. Must be a bug then; I confirmed this is actually what happens by adding logging to the kill syscall implementation in the kernel. + paraOr, if optionKillMode=mixed/option, systemd will + directly send constantSIGKILL/constant to all remaining members + of the control group, regardless of the + varnameSendSIGKILL=/varname preference./para Hmm? No, not at all. If you use mixed, then SIGTERM is is sent to the main process of the daemon, and SIGKILL to *al* processes of the daemon if there are any left after the main process exited. That's exactly what I wrote - all of this falls under a paragraph explaining what happens when the main process has already gone. I guess I need to improve the wording. Thanks for your feedback Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sysusers: allow separate alternate roots for configs and modifications
On 2015-04-23 at 14:11 +0200, Lennart Poettering wrote: On Thu, 26.02.15 02:46, Ivan Shapovalov (intelfx...@gmail.com) wrote: This is useful, for example, to create system accounts on an initramfs using the host's configuration. Hmm, but you can already do this, by specifiying the config files on the command line, no? Actually, this means duplicating the logic of determining of the directory list (/usr/lib vs /lib, ...). -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] zsh-completion: add missing completions for machinectl
On Thu, 23.04.15 13:06, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Wed, Apr 22, 2015 at 12:30:32PM -0700, Lukas Rusak wrote:
Ah, completely missed images. So perhaps something like this would be
better?
machinectl --full --no-legend --no-pager list-images | awk '{print $1}'
We usually try to avoid running external programs unless necessary. This
can be implemented in pure shell which should be slightly faster.
Well, it's not that easy, since machined actually searches multiple
directories, ignores certain hidden files, drops .raw suffixes and
suchlike. Of course, you can replicate all that in shell, or you can
avoid it...
I think you can ignore spaces for now. This is just tab completion after all,
it doesn't have to be bullet proof, and using spaces in image names would be
fairly exotic.
We don't support that in machined anyway.
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] install Fedora systemd-nspawn container on btrfs
On Thu, 23.04.15 14:18, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: Pick one: a) download the raw image and use that, but it will be a loopback file with its own file system inside or: b) do the dnf/yum install root thing, and install it into a directory tree. I installed yum package on Arch but couldn't manage to do the install. # yum -y --releasever=22 --nogpg --installroot=/var/lib/machines/enl --disablerepo='*' --enablerepo=fedora install systemd passwd dnf fedora-release-server Error getting repository data for fedora, repository not found # yum repolist all repolist: 0 In fact, /etc/yum/repos.d is empty, so I am not surprised. Of course, you could use the .raw image, mount the extern btrfs volume into it via nspawn's --bind= switch, then use yum inside of that container to install into the btrfs volume. Then get rid of the .raw image again, and you still have the btrfs volume that should be bootable. A bit complex, but you almost were there already... ;-) 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] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
On Thu, 23.04.15 06:41, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Thu, 23 Apr 2015 00:48:38 +0200 Lennart Poettering lenn...@poettering.net пишет: On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote: Sorry for the late review. What's the precise background of this? Can you elaborate? Is there some feature request for this? There are multiple bug reports that switching to dracut with integrated systemd breaks ability to auto-setup encrypted devices using keyfile on external USB stick. Hmm, but from Jan's mail I got the impression that this is a Dracut feature in the first place? Now I am confused? Which initrd implementations supported this scheme before? What does this actually do? Is the specified key file read from the specified device? It reads keyfile from filesystem on device identifed by keyfile_device. The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? keyfile is mandatory, keyfile_device is optional and can be omitted. I believe dracut looked at all existing devices then. This order makes it easier to omit optional parameter(s). Well, whether it is [device:]file or file[:device] is hardly any difference for the parser... Is this specific to Dracut so far? Is this widely used, and something that we really want. I can say about dracut only but yes, it is used and it is serious regression when it is used comparing with pre-systemd version. Can you point me to documentation about the previous features in this regard? Which initrd implementations are you referring to? First version of the patch that allows rd.luks.key to be specified almost the same way as dracut can read it. The solution creates a temporary mount unit mnt.mount that the generated cryptsetup service wants. The partition where the keyfile is then mounted to /mnt and the absolute path to the keyfile is changed so it points to this temporary mount instead. Well, I'd place this in /run somewhere. Maybe /run/systemd/cryptsetup/mount or so... I'm not sure if temporarily mounting something to /mnt in initrd is safe. If not, what would be a preffered way to do this? What does temporarily mean? When is this unmounted? To fetch keyfile dracut needs to mount USB stick. This mount is not normally needed after cryptomount setup is completed. Well, sure, I am just wondering what precisely shall be used as trigger to unmount it again. 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 1/3] sysusers: allow separate alternate roots for configs and modifications
On 2015-04-23 at 16:48 +0200, Lennart Poettering wrote: On Thu, 23.04.15 17:46, Ivan Shapovalov (intelfx...@gmail.com) wrote: On 2015-04-23 at 14:11 +0200, Lennart Poettering wrote: On Thu, 26.02.15 02:46, Ivan Shapovalov (intelfx...@gmail.com) wrote: This is useful, for example, to create system accounts on an initramfs using the host's configuration. Hmm, but you can already do this, by specifiying the config files on the command line, no? Actually, this means duplicating the logic of determining of the directory list (/usr/lib vs /lib, ...). True, but it's not *that* complex in that case... Not really, because it is then also needed to do priority-overriding of the configuration snippets by hand. I would really like to avoid re -implementing this logic. There is an alternative to bind-mount all configuration directories into the destination root, but it's not atomic against killing of the process (if we get killed in between, stale bind mounts will remain). So I won't like to do this either. I'm sure that mkinitcpio maintainer in arch will not accept this solution as well. Any other options? -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How can I map PID between host and container?
On Thu, Apr 23, 2015 at 6:25 PM, Lennart Poettering lenn...@poettering.net
wrote:
The kernel doesn't have any nice userspace APIs to translate PIDs like
this, to my knowledge at least.
That said, one can implement something like this by using the fact
that the kernel will translate user credentials that are sent via
AF_UNIX SCM_CREDENTIALS that pass through a PID namespace
boundary. hence, let's say you have one pid $n that identifies the
namespace you care about, and a container pid $a you want to translate
to host pid $b, then you'd create an AF_UNIX/SOCK_SEQPACKET
socketpair(), fork(), run setns() in the child to join the namespace
of $n, and send a single datagram to the parent with sendmsg(), while
explicitly specifiying the SCM_CREDENTIALS auxiliary field with the $a
in it, and exit. In the parent you use recvmsg() to read that datagram
with its SCM_CREDENTIALS, and use the pid you see as $b. Vice versa,
if you want to translate the other way you would send the datagram the
other way.
nasty? absolutely! (also, only available for privileged processes, due
to the setns() call).
I am not aware of any nicer way.
I think /proc/pid/status in current linux.git has additional fields for
the process PIDs in all namespaces, so you could probably get the outer
PID by looking at the container's /proc.
--
Mantas Mikulėnas graw...@gmail.com
On Thu, Apr 23, 2015 at 6:25 PM, Lennart Poettering lenn...@poettering.net
wrote:
On Fri, 24.04.15 00:10, WaLyong Cho (walyong@samsung.com) wrote:
Hello,
I'm looking for a proper way what method to map PID between host and
container.
In case of systemctl, if I know pid in container(let's call this pid_c)
then I can find the pid in sight of host(let's call this pid_h) by using
systemctl -M {container} pid_c in host shell. But I can not find pid_c
when I know pid_h by using systemctl status pid_h.
The former seems possible by parsing machine cgroup.
In the latter case, can we also find the pid_c?
And is there any other method to map between those?
For example, when if I use lxc then how I find each pid? (lxc-ps?)
According to my search, namespace can give me some of hints about this.
I could not find more detail.
Is there any proper libs or tools for this?
The kernel doesn't have any nice userspace APIs to translate PIDs like
this, to my knowledge at least.
That said, one can implement something like this by using the fact
that the kernel will translate user credentials that are sent via
AF_UNIX SCM_CREDENTIALS that pass through a PID namespace
boundary. hence, let's say you have one pid $n that identifies the
namespace you care about, and a container pid $a you want to translate
to host pid $b, then you'd create an AF_UNIX/SOCK_SEQPACKET
socketpair(), fork(), run setns() in the child to join the namespace
of $n, and send a single datagram to the parent with sendmsg(), while
explicitly specifiying the SCM_CREDENTIALS auxiliary field with the $a
in it, and exit. In the parent you use recvmsg() to read that datagram
with its SCM_CREDENTIALS, and use the pid you see as $b. Vice versa,
if you want to translate the other way you would send the datagram the
other way.
nasty? absolutely! (also, only available for privileged processes, due
to the setns() call).
I am not aware of any nicer way.
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/8] power: refactor the three power management binaries to src/power
On Fri, 27.02.15 03:26, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I'm not sure we want this... Can you add some justification? Do they share code? I am pretty sure we don't want this. shutdown.c really belongs in src/core/. It's a binary that replaces PID 1 during shutdown, and becomes PID 1 itself. It gets some private data passed from the real systemd, and thus is more or less just an external component of it. It also has nothing to do with power management at all. shutdownd.c is also has nothing to do with power management. And if we want to change anything about it, then probably only to delete it from the tree. In fact, Daniel is working of getting rid of it and merging its feature set into logind. 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] man: document kill behavior after the main process exits
On Thu, 23.04.15 09:43, Daniel Drake (dr...@endlessm.com) wrote: On Thu, Apr 23, 2015 at 9:32 AM, Lennart Poettering lenn...@poettering.net wrote: +titleBeyond the main process/title + + paraThe varnameKillMode=/varname option primarily defines + behavior up until the point where the main process has gone away. + systemd expects that when killed with the signal specified by + varnameKillSignal=/varname, the main process will kill and + reap all the other processes in the control group before + exiting itself. Well, I don't think this is right. I mean, systemd doesn't really expect this. It's completely OK if daemons leave children around in this case. I could avoid the word expect but I think it's worth mentioning as those discarded children might not be designed to accept 2 SIGTERMs in normal conditions. Well, ideally we'd make KillMode=mixed the default these days, which avoids the confusion around this. However I doubt we should change this now. For example, any child process that uses glib and exits the mainloop from the SIGTERM handler does not really respond well here - it drops the SIGTERM handler after the first one, so the second SIGTERM will cause an immediate/unclean shutdown, which is not completely OK from the view of the child. Well, then mention this explicitly: say that if the main daemon process does leave child processes around and KillMode=control-group is set, that those child processes might get two SIGTERM in sequence. + paraIf optionKillMode=control-group/option, systemd will + then send a second varnameKillSignal=/varname signal to the + remaining processes, which will then be followed by a + constantSIGKILL/constant if processes are still around, even + if optionSendSIGKILL=no/option./para Hmm, no? SendSIGKILL=no should have the effect of not sending any SIGKILL at all. Anything else would be a bug. Must be a bug then; I confirmed this is actually what happens by adding logging to the kill syscall implementation in the kernel. would be happy to see this tracked down. SendSIGKILL=no should really do what it suggests it does! 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] Failure(s) Building Systemd with --enable-resolved
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote on 04/21/2015 01:51:29 PM: On Tue, Apr 21, 2015 at 08:39:35AM -0700, aaron_wri...@selinc.com wrote: I've been getting a few problems building systemd with --enable-resolved . Any help would be very welcomed. I don't have any problems when compiling with --disable-resolved. The first problem I got was this: CCLD libnss_resolve.la libsystemd_internal_la-bus-message.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters /tmp/cc03x1nN.ltrans6.ltrans.o: In function `bus_error_name_to_errno.4725 ': cc03x1nN.ltrans6.o:(.text+0x12bb): undefined reference to `__stop_BUS_ERROR_MAP' cc03x1nN.ltrans6.o:(.text+0x12c2): undefined reference to `__start_BUS_ERROR_MAP' collect2: ld returned 1 exit status I got around this be removing -flto from OUR_CFLAGS in the Makefile. How is that change going to impact systemd? Is there a better way to work around this problem? Afaik nobody has measured that. It will certainly make your compilation times much shorter :) So after some reading, LTO is an optimization flag; removing it would potentially slow down systemd a little bit, but it shouldn't change any behavior. I could live with that. But now I can't figure out how to get rid of -flto reliably. It's not mentioned in Makefile.am. It seems to be added by libtool automatically, but I can't figure out how to make it stop. I tried adding -fno-lto to libnss_resolve_la_LDFLAGS in Makefile.am, but libtool seems to strip that out. Presumably because it doesn't recognize it. After I got pass the first error, I now get this: CC src/resolve/resolved-dns-cache.o src/resolve/resolved-dns-scope.c: In function ?dns_scope_tcp_socket?: src/resolve/resolved-dns-scope.c:260:56: error: ?IP_UNICAST_IF? undeclared (first use in this function) src/resolve/resolved-dns-scope.c:260:56: note: each undeclared identifier is reported only once for each function it appears in It was in kernel 3.4. What kernel headers are you using? Zbyszek You're right. I'm using Kernel 3.10. I didn't have the right linux-libc-dev package installed. So now IP_UNICAST_IF is defined in /usr/include/linux/in.h, but that doesn't fix the compile errors. I can't include linux/in.h directly as that'll cause all sorts of redefinition errors with netinet/in.h. I'm not sure what is supposed to include linux/in.h for me. Including netinet/in.h doesn't fix it, as it doesn't define IP_UNICAST_IF. I ended up adding #define IP_UNICAST_IF 50 to the top of src/resolve/resolved-dns-scope.c and src/resolve/resolved-dns-stream.c, which is a little hackish, but at leasts gets it to compile. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sysusers: allow separate alternate roots for configs and modifications
On Thu, 23.04.15 18:09, Ivan Shapovalov (intelfx...@gmail.com) wrote: On 2015-04-23 at 16:48 +0200, Lennart Poettering wrote: On Thu, 23.04.15 17:46, Ivan Shapovalov (intelfx...@gmail.com) wrote: On 2015-04-23 at 14:11 +0200, Lennart Poettering wrote: On Thu, 26.02.15 02:46, Ivan Shapovalov (intelfx...@gmail.com) wrote: This is useful, for example, to create system accounts on an initramfs using the host's configuration. Hmm, but you can already do this, by specifiying the config files on the command line, no? Actually, this means duplicating the logic of determining of the directory list (/usr/lib vs /lib, ...). True, but it's not *that* complex in that case... Not really, because it is then also needed to do priority-overriding of the configuration snippets by hand. I would really like to avoid re -implementing this logic. There is an alternative to bind-mount all configuration directories into the destination root, but it's not atomic against killing of the process (if we get killed in between, stale bind mounts will remain). So I won't like to do this either. I'm sure that mkinitcpio maintainer in arch will not accept this solution as well. Any other options? Hmm, I don't really see the use for this I must say. That said, I figure I would accept a patch that adds a new switch --configuration-root= or so, similar to your original patch, but leaves --root= as it is right now, and really only adds a new --configuration-root= that if specified overrides the root directory otherwise specified for the reading of the configuration files. If you add this tmpfiles should probably get something similar, to make this match up nicely... 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] man: document kill behavior after the main process exits
While looking at the exact behavior of how systemd stops services, I encountered some behavior that wasn't clear from reading the man page. Specifically, if the main process exits before its children, the child processes will actually receive a second SIGTERM. If that doesn't kill them, they will later receive a SIGKILL too, even if SendSIGKILL=no. Add some notes about this. --- man/systemd.kill.xml | 30 -- 1 file changed, 28 insertions(+), 2 deletions(-) Thanks for helping me to get to the bottom of this in the thread: Zombie process still exists after stopping gdm.service unit_kill_context() has a comment which is relevant here: /* FIXME: For now, we will not wait for the * cgroup members to die, simply because * cgroup notification is unreliable. It * doesn't work at all in containers, and * outside of containers it can be confused * easily by leaving directories in the * cgroup. */ /* wait_for_exit = true; */ When this is fixed, assumed to happen soon, the precise behaviour seen in the discussion will change slightly (in terms of timing). So I have carefully written this documentation patch in a way that does not go into the timing details. The text changed below should therefore be true both before and after that FIXME is resolved. diff --git a/man/systemd.kill.xml b/man/systemd.kill.xml index e57f0e7..10232fb 100644 --- a/man/systemd.kill.xml +++ b/man/systemd.kill.xml @@ -154,8 +154,9 @@ termvarnameSendSIGKILL=/varname/term listitemparaSpecifies whether to send constantSIGKILL/constant to remaining processes after a -timeout, if the normal shutdown procedure left processes of -the service around. Takes a boolean value. Defaults to yes. +timeout, if the normal shutdown procedure didn't succeed in +shutting down the main process. Takes a boolean value. +Defaults to yes. /para/listitem /varlistentry @@ -163,6 +164,31 @@ /refsect1 refsect1 +titleBeyond the main process/title + + paraThe varnameKillMode=/varname option primarily defines + behavior up until the point where the main process has gone away. + systemd expects that when killed with the signal specified by + varnameKillSignal=/varname, the main process will kill and + reap all the other processes in the control group before + exiting itself. If that doesn't happen, and the main process + exits with other processes still running in the control group, + systemd gets a bit more heavy-handed:/para + + paraIf optionKillMode=control-group/option, systemd will + then send a second varnameKillSignal=/varname signal to the + remaining processes, which will then be followed by a + constantSIGKILL/constant if processes are still around, even + if optionSendSIGKILL=no/option./para + + paraOr, if optionKillMode=mixed/option, systemd will + directly send constantSIGKILL/constant to all remaining members + of the control group, regardless of the + varnameSendSIGKILL=/varname preference./para + + /refsect1 + + refsect1 titleSee Also/title para citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry, -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [v3 1/4] man: these binaries are internal APIs
On Sun, 15.03.15 17:59, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Fri, Feb 27, 2015 at 05:04:21PM -0800, Shawn Landden wrote: --- man/systemd-halt.service.xml | 1 - man/systemd-shutdownd.service.xml | 1 - man/systemd-suspend.service.xml | 1 - 3 files changed, 3 deletions(-) diff --git a/man/systemd-halt.service.xml b/man/systemd-halt.service.xml index c94e2a1..7e7f8f2 100644 --- a/man/systemd-halt.service.xml +++ b/man/systemd-halt.service.xml @@ -56,7 +56,6 @@ parafilenamesystemd-poweroff.service/filename/para parafilenamesystemd-reboot.service/filename/para parafilenamesystemd-kexec.service/filename/para -parafilename/usr/lib/systemd/systemd-shutdown/filename/para /refsynopsisdiv Hm, I was going back and forth on this patch... You are certainly right that the user should never call those binaries directly. But we do list other binaries in the documentation in similar circumstances. And I think we should continue to do so, for two reasons: 1. when trying to understand how everythig works it makes it easier to start with the documentation and see what binaries are used to do various things. 2. when looking for something related, it makes it easier to distinguish various commands with a similar name. (This systemd-sleep binary is not the binary you're looking for. :)) Maybe we should move the binary to FILES section and mention that it should not be called directly. But then this should be done also for systemd-journald and others which are never called directly. I am pretty sure we should document the binary paths, even if these binaries are nothing that normal users should ever invoke directly. The reason is simply that ps will show these binaries with these paths, and I think it's good to provide explanations in man pages for them hence. ps is about discovering what's running, and we should help with our documentation to make useful what it shows there. 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 1/3] sysusers: allow separate alternate roots for configs and modifications
On Thu, 23.04.15 17:46, Ivan Shapovalov (intelfx...@gmail.com) wrote: On 2015-04-23 at 14:11 +0200, Lennart Poettering wrote: On Thu, 26.02.15 02:46, Ivan Shapovalov (intelfx...@gmail.com) wrote: This is useful, for example, to create system accounts on an initramfs using the host's configuration. Hmm, but you can already do this, by specifiying the config files on the command line, no? Actually, this means duplicating the logic of determining of the directory list (/usr/lib vs /lib, ...). True, but it's not *that* complex in that case... 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] build-sys: Lookup for the location of agetty
On Mon, 16.02.15 12:42, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: May be in /sbin or /usr/sbin Hmm, who would place the getty in /usr/sbin and not link this up in /sbin? Anyway, I also see no reason not to merge something like this, but: --- a/units/getty@.service.m4 +++ b/units/getty@.service.m4 @@ -27,7 +27,7 @@ ConditionPathExists=/dev/tty0 [Service] # the VT is cleared by TTYVTDisallocate -ExecStart=-/sbin/agetty --noclear %I $TERM +ExecStart=-@AGETTY@ --noclear %I $TERM This cannot work. We don't pass this one through @@ expansion, only through m4. The @AGETTY@ will still be @AGETTY@ after the generation of the final service file. if you want this to work, then you need to also pass this through @@ expansion, and then through m4, like this is done for the other files. Or in other words: this would need to become a .m4.in file, not just a .in file. Type=idle Restart=always RestartSec=0 diff --git a/units/serial-getty@.service.m4 b/units/serial-getty@.service.m4 index 4522d0d..bafbbb2 100644 --- a/units/serial-getty@.service.m4 +++ b/units/serial-getty@.service.m4 Same for this one. 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] units: add ConditionKernelCommandLine=resume
On Tue, 17.02.15 01:33, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: If there is no resume= ..it is not possible to hubrid-sleep or hibernate To my knowledge the resume device can be discovered in different ways than just the kernel cmdline. On my machine here there is no resume= on the kernel cmdline, and hibernation works anyway. Also, even if: simply not running the sleep service, and skipping over it sounds like the wrong approach. It would just turn hibernation into a NOP, but it should properly fail. If this was really an issue, then the right fix would be to change can_sleep() in src/shared/sleep-config.c, to detect this properly. --- units/systemd-hibernate.service.in| 1 + units/systemd-hybrid-sleep.service.in | 1 + 2 files changed, 2 insertions(+) diff --git a/units/systemd-hibernate.service.in b/units/systemd-hibernate.service.in index 29d9b69..2a21cfc 100644 --- a/units/systemd-hibernate.service.in +++ b/units/systemd-hibernate.service.in @@ -11,6 +11,7 @@ Documentation=man:systemd-suspend.service(8) DefaultDependencies=no Requires=sleep.target After=sleep.target +ConditionKernelCommandLine=resume [Service] Type=oneshot diff --git a/units/systemd-hybrid-sleep.service.in b/units/systemd-hybrid-sleep.service.in index 914b686..b3039a0 100644 --- a/units/systemd-hybrid-sleep.service.in +++ b/units/systemd-hybrid-sleep.service.in @@ -11,6 +11,7 @@ Documentation=man:systemd-suspend.service(8) DefaultDependencies=no Requires=sleep.target After=sleep.target +ConditionKernelCommandLine=resume [Service] Type=oneshot -- 2.2.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How can I map PID between host and container?
Hello,
I'm looking for a proper way what method to map PID between host and
container.
In case of systemctl, if I know pid in container(let's call this pid_c)
then I can find the pid in sight of host(let's call this pid_h) by using
systemctl -M {container} pid_c in host shell. But I can not find pid_c
when I know pid_h by using systemctl status pid_h.
The former seems possible by parsing machine cgroup.
In the latter case, can we also find the pid_c?
And is there any other method to map between those?
For example, when if I use lxc then how I find each pid? (lxc-ps?)
According to my search, namespace can give me some of hints about this.
I could not find more detail.
Is there any proper libs or tools for this?
Thanks,
WaLyong
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failure(s) Building Systemd with --enable-resolved
Lennart Poettering lenn...@poettering.net wrote on 04/22/2015 04:29:18 PM: On Tue, 21.04.15 08:39, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: I've been getting a few problems building systemd with --enable-resolved . Any help would be very welcomed. I don't have any problems when compiling with --disable-resolved. The first problem I got was this: CCLD libnss_resolve.la libsystemd_internal_la-bus-message.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters /tmp/cc03x1nN.ltrans6.ltrans.o: In function `bus_error_name_to_errno.4725 ': cc03x1nN.ltrans6.o:(.text+0x12bb): undefined reference to `__stop_BUS_ERROR_MAP' cc03x1nN.ltrans6.o:(.text+0x12c2): undefined reference to `__start_BUS_ERROR_MAP' collect2: ld returned 1 exit status Kay made some changes to the build system for this. Can you check if this part works now for you? Lennart -- Lennart Poettering, Red Hat I cloned down the master branch yesterday and tried to build, but got: src/shared/random-util.c:26:22: fatal error: sys/auxv.h: No such file or directory Which is new. Apparently sys/auxv.h was added in eglibc 2.16, and I'm stuck with eglibc 2.15, so that's a new unrelated wrinkle. So, I attempted to merge the changes that seemed to make sense from Makefile.am on master to 219, which involved a lot of adding libsystemd-internal.la to different places, and ordering libsystemd-shared.la after it. Most of changes were in sections I'm not using, due to my configuration arguments, and libnss_resolve_la_LIBADD, the failing library, already had both libsystemd-internal.la and libsystemd-shared.la listed in libnss_resolve_la_LIBADD in the same order as everyone else. Am I missing something? Should I be looking in a different file, other than Makefile.am? So, I haven't found a solution to this yet. It seems my problem is that my build environment is too old for systemd. I won't be able to move to 220 because of eglibc 2.16 dependency, and I can't get libnss_resolve to compile due to a bug in my old gcc 4.6. My environment is Ubuntu Precise, which is a long term service edition. My configuration arguments if anyone is curious: --disable-chkconfig \ --disable-apparmor \ --disable-xz \ --disable-zlib \ --disable-bzip2 \ --disable-lz4 \ --disable-pam \ --disable-acl \ --disable-smack \ --disable-gcrypt \ --disable-audit \ --disable-elfutils \ --disable-libcryptsetup \ --disable-qrencode \ --disable-microhttpd \ --disable-gnutls \ --disable-libcurl \ --disable-libidn \ --disable-libiptc \ --disable-binfmt \ --disable-vconsole \ --disable-bootchart \ --disable-quotacheck \ --disable-backlight \ --disable-rfkill \ --disable-logind \ --disable-machined \ --disable-importd \ --disable-hostnamed \ --disable-timedated \ --disable-timesyncd \ --disable-localed \ --disable-coredump \ --disable-polkit \ --disable-networkd \ --disable-efi \ --disable-terminal \ --disable-kdbus \ --disable-gudev \ --disable-manpages \ --disable-hibernate \ --disable-ldconfig \ --disable-tests \ --disable-sysusers \ --disable-dbus \ \ --enable-selinux \ --enable-tmpfiles \ --enable-randomseed \ --enable-split-usr \ --enable-myhostname \ --enable-firstboot \ --enable-resolved \ \ --without-python \ \ --with-debug-shell= \ --with-debug-tty= \ --with-ntp-servers= \ --with-dns-servers= \ --with-telinit= \ --with-sysvinit-path= \ --with-sysvrcnd-path= \ --with-rc-local-script-path-start= \ --with-rc-local-script-path-stop= \ --with-bashcompletiondir= \ --with-zshcompletiondir= \ --with-pamlibdir= \ --with-pamconfdir= \ --with-dbuspolicydir= \ --with-dbussessionservicedir= \ --with-dbussystemservicedir=___ systemd-devel mailing list
Re: [systemd-devel] Failure(s) Building Systemd with --enable-resolved
On Thu, 23.04.15 09:43, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: I cloned down the master branch yesterday and tried to build, but got: src/shared/random-util.c:26:22: fatal error: sys/auxv.h: No such file or directory Which is new. Apparently sys/auxv.h was added in eglibc 2.16, and I'm stuck with eglibc 2.15, so that's a new unrelated wrinkle. See the README, we require 2.16. Please update your glibc first! 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] install Fedora systemd-nspawn container on btrfs
On Thu, Apr 23, 2015 at 7:36 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 19:29, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: When in /var/lib/machines/poppy: root@hortensia ➤➤ machines/poppy # btrfs subvolume list . ID 266 gen 98 top level 5 path rootvol ID 268 gen 100 top level 5 path var ID 269 gen 101 top level 5 path etc ID 271 gen 72 top level 266 path var/lib/machines ID 272 gen 77 top level 268 path var/tmp ID 273 gen 77 top level 268 path var/lib/machines Anyone from the Btrfs ML to help ? Note that systemd-tmpfiles will create /var/tmp, and /var/lib/machines as subvolumes these days, if they are missing and on btrfs. OK, I understand these new subvol Lennart -- Lennart Poettering, Red Hat -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] Partially revert patch 11689d2a which force the NOCOW attribute.
Hi, On 2015-04-22 13:33, Lennart Poettering wrote: On Sun, 12.04.15 20:30, Goffredo Baroncelli (kreij...@libero.it) wrote: From: Goffredo Baroncelli kreij...@inwind.it Partially revert patch 11689d2a, which force the NOCOW attribute for the journal files. This patch was introduced to allievate the perfomances problem that journald shows on the BTRFS filesystem. Because the NOCOW attribute is forced the user can't revert to the old behavior. However NOCOW attribute disables the btrfs checksums, which prevent BTRFS to rebuild a currupted file in an RAIDx filesystem. To continue to set the NOCOW attribute, use the h|H command of systemd-tmpfile. I have now commited a similar patch that replaces the patching of the attribute for new journal files with a warning if we notice the journal file is on btrfs and the flag is not set. I hope this settles the issue! Many thanks for working on that ! BR G.Baroncelli Thanks! Lennart -- gpg @keyserver.linux.it: Goffredo Baroncelli kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] install Fedora systemd-nspawn container on btrfs
On Thu, Apr 23, 2015 at 7:21 PM, arnaud gaboury arnaud.gabo...@gmail.com wrote: On Thu, Apr 23, 2015 at 7:12 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 19:00, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: On Thu, Apr 23, 2015 at 4:47 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 14:18, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: Pick one: a) download the raw image and use that, but it will be a loopback file with its own file system inside or: b) do the dnf/yum install root thing, and install it into a directory tree. I installed yum package on Arch but couldn't manage to do the install. # yum -y --releasever=22 --nogpg --installroot=/var/lib/machines/enl --disablerepo='*' --enablerepo=fedora install systemd passwd dnf fedora-release-server Error getting repository data for fedora, repository not found # yum repolist all repolist: 0 In fact, /etc/yum/repos.d is empty, so I am not surprised. Of course, you could use the .raw image, mount the extern btrfs volume into it via nspawn's --bind= switch, then use yum inside of that container to install into the btrfs volume. Then get rid of the .raw image again, and you still have the btrfs volume that should be bootable. A bit complex, but you almost were there already... ;-) Wunderbach # systemd-nspawn -M Fedora-Cloud-Base-22_Beta-20150415.x86_64.raw -- bind=/var/lib/machines/enl:/mnt [root@Fedora-Cloud-Base-22_Beta-20150415 ~]#dnf -y --releasever=22 --nogpg --installroot=/mnt --disablerepo='*' --enablerepo=fedora install systemd passwd dnf Complete! - $ ls /var/lib/machines/enl boot/ etc/ media/ opt/ root/ srv/ tmp/ var/ lib@sbin@ dev/ home/ mnt/proc/ run/ sys/ usr/ bin@ lib64@ - But now booting but hanging: #systemd-nspawn -bD /var/lib/machines/enl Spawning container enl on /var/lib/machines/enl. Press ^] three times within 1s to kill container. systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) Detected virtualization 'systemd-nspawn'. Detected architecture 'x86-64'. Running with unpopulated /etc. Welcome to Fedora 22 (Twenty Two)! Initializing machine ID from random generator. Populated /etc with preset unit settings. Unit etc.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Unit var.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. Startup finished in 51ms. Maybe my btrfs story ? Unit etc.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Unit var.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Will investigate. --bind was certainly the most easy trick once the raw image is downloaded. Hmm, my guess is that you somehow lost the /etc and /var directories half way, probably because of the weird mounting your are doing. --bind= should normally be recursive, but maybe this didn't work? root@hortensia ➤➤ lib/machines # ls poppy/etc lvm/systemd/ groupld.so.cache machine-id os-release@ resolv.conf pam.d/ udev/ gshadow localtime@ nsswitch.conf passwd shadow /etc seems correctly populated. Container boot but can't have login prompt. It hangs with no possibility to enter anything. Btrfs mess. When in /var/lib/machines/poppy: root@hortensia ➤➤ machines/poppy # btrfs subvolume list . ID 266 gen 98 top level 5 path rootvol ID 268 gen 100 top level 5 path var ID 269 gen 101 top level 5 path etc ID 271 gen 72 top level 266 path var/lib/machines ID 272 gen 77 top level 268 path var/tmp ID 273 gen 77 top level 268 path var/lib/machines Anyone from the Btrfs ML to help ? Lennart -- Lennart Poettering, Red Hat -- google.com/+arnaudgabourygabx -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failure(s) Building Systemd with --enable-resolved
On Thu, 23.04.15 10:16, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: Lennart Poettering lenn...@poettering.net wrote on 04/23/2015 09:59:38 AM: On Thu, 23.04.15 09:43, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: I cloned down the master branch yesterday and tried to build, but got: src/shared/random-util.c:26:22: fatal error: sys/auxv.h: No such file or directory Which is new. Apparently sys/auxv.h was added in eglibc 2.16, and I'm stuck with eglibc 2.15, so that's a new unrelated wrinkle. See the README, we require 2.16. Please update your glibc first! Well, yeah, now systemd requires 2.16, but 219 doesn't, unless that was an oversight. Yeah, it kinda was. See 3dd26f3e3aa7fa0696d304e14551362133dd281f. That said, if this is just about IP_UNICAST_IF, I'd be willing to merge a patch that adds this to missing.h 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] install Fedora systemd-nspawn container on btrfs
On Thu, 23.04.15 19:29, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: When in /var/lib/machines/poppy: root@hortensia ➤➤ machines/poppy # btrfs subvolume list . ID 266 gen 98 top level 5 path rootvol ID 268 gen 100 top level 5 path var ID 269 gen 101 top level 5 path etc ID 271 gen 72 top level 266 path var/lib/machines ID 272 gen 77 top level 268 path var/tmp ID 273 gen 77 top level 268 path var/lib/machines Anyone from the Btrfs ML to help ? Note that systemd-tmpfiles will create /var/tmp, and /var/lib/machines as subvolumes these days, if they are missing and on btrfs. 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] Failure(s) Building Systemd with --enable-resolved
On Thu, 23.04.15 09:21, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: After I got pass the first error, I now get this: CC src/resolve/resolved-dns-cache.o src/resolve/resolved-dns-scope.c: In function ?dns_scope_tcp_socket?: src/resolve/resolved-dns-scope.c:260:56: error: ?IP_UNICAST_IF? undeclared (first use in this function) src/resolve/resolved-dns-scope.c:260:56: note: each undeclared identifier is reported only once for each function it appears in It was in kernel 3.4. What kernel headers are you using? Zbyszek You're right. I'm using Kernel 3.10. I didn't have the right linux-libc-dev package installed. So now IP_UNICAST_IF is defined in /usr/include/linux/in.h, but that doesn't fix the compile errors. I can't include linux/in.h directly as that'll cause all sorts of redefinition errors with netinet/in.h. I'm not sure what is supposed to include linux/in.h for me. Including netinet/in.h doesn't fix it, as it doesn't define IP_UNICAST_IF. I ended up adding #define IP_UNICAST_IF 50 to the top of src/resolve/resolved-dns-scope.c and src/resolve/resolved-dns-stream.c, which is a little hackish, but at leasts gets it to compile. Which glibc version are you using? 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] Another attempt: Making dependencies properly overridable
On Sun, 19.04.15 09:29, Andrei Borzenkov (arvidj...@gmail.com) wrote: Unless I'm mistaken, the only real change is that Wants= will clear list, just like it does it for ExecStart=. This should be rather straightforward to implement I guess. Actually it's not that easy. You need to collect the deps created from unit configuration into a set of hashmaps of their own, and then add a final commit step that merges those into the real deps. And if we want to do this without needless copies and allocations this is actually not easy at all. 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] Another attempt: Making dependencies properly overridable
On Mon, 16.02.15 16:19, Christian Seiler (christ...@iwakd.de) wrote: Last time I talked about this here, there was a lot of confusion, so I didn't pursue it further. But I would really like to get this to work, but before I start with a patch, I'd like to explain what I'd like to do before working on it, to see if it works for you. The semantics I'd like to see would be the following: - anything in /etc named exactly the same as in /usr/lib overrides the latter, just as is already the case with units and drop-ins = allow masking of .wants/ and .requires/ with symlinks to /dev/null (I think you were in favor of that) Sounds good. I like. +1. Me gusta. - additionally, postpone processing of dependencies in unit files until the entire unit (and all drop-ins) have been read in For example, even without a drop-in: a.service: [Unit] Wants=b.service Wants= Wants=c.service After that, Wants should be set to c.service. Note that this should NOT affect dependencies set in other ways, i.e. via .wants/ directories or by dependencies of other services, this should JUST alter what was specified in the unit itself. I figure I can agree with this, too. The general principle would be: you can drop stuff at the same place it's defined. If it's defined as After= in a unit, override it in a drop-in for that unit, if it's defined as Before= in another unit, override it in a drop-in for the other unit, and if it's defined in the filesystem via .wants/ or .requires/, you can override it by masking it in the filesystem. Only in the end will all remaining dependencies be combined to make up the entire list of dependencies for that service. Actually I'd probably be more liberal here and even allow dropping deps created in the unit file with a .wants masking. The only thing i would not allow is masking out deps on a unit that are actually configure on another unit, as well as automatic deps. I mean, so far the deps we set are combined from: unit file (1) + dropins(2) + .wants/ + .requires/ symlinks (3) + automatic deps (4) + deps configured in other units (5) I'd allow unsetting deps configured in (1) from (1), (2) and (3). I'd allow unsetting deps configured in (2) from (2) and (3). I'd allow unsetting deps made in (3) from (3). I would not allow unsetting deps made in (1,2,3) with (4) or (5), or vice versa. 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] Another attempt: Making dependencies properly overridable
On Sun, 19.04.15 17:08, Andrei Borzenkov (arvidj...@gmail.com) wrote:
What about Wants-=e.service in dropin? Dropins are processed
after .{wants,requires}.d and has advantage that you can remove also
static dependency from unit definition file, not only mask another
directory.
This has been requested before, but I'd be very careful with this. I
really don't want to turn this into a complex language really, and
especially not in one that knows different kinds of assignments. I
mean, already we aren't simple .ini files anymore, since we allow
assigning the empty string for resets, and allow multiple assignments
that add things up. But I'd *really* like to avoid deviating even
further from the simplicity that ini files are.
Or let's say it like this: I am very keen on keeping the file
structure as simple as just a list of key-value pairs, possibly with
[sections] and comments, and that's it.
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] install Fedora systemd-nspawn container on btrfs
On Thu, Apr 23, 2015 at 4:47 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 14:18, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: Pick one: a) download the raw image and use that, but it will be a loopback file with its own file system inside or: b) do the dnf/yum install root thing, and install it into a directory tree. I installed yum package on Arch but couldn't manage to do the install. # yum -y --releasever=22 --nogpg --installroot=/var/lib/machines/enl --disablerepo='*' --enablerepo=fedora install systemd passwd dnf fedora-release-server Error getting repository data for fedora, repository not found # yum repolist all repolist: 0 In fact, /etc/yum/repos.d is empty, so I am not surprised. Of course, you could use the .raw image, mount the extern btrfs volume into it via nspawn's --bind= switch, then use yum inside of that container to install into the btrfs volume. Then get rid of the .raw image again, and you still have the btrfs volume that should be bootable. A bit complex, but you almost were there already... ;-) Wunderbach # systemd-nspawn -M Fedora-Cloud-Base-22_Beta-20150415.x86_64.raw -- bind=/var/lib/machines/enl:/mnt [root@Fedora-Cloud-Base-22_Beta-20150415 ~]#dnf -y --releasever=22 --nogpg --installroot=/mnt --disablerepo='*' --enablerepo=fedora install systemd passwd dnf Complete! - $ ls /var/lib/machines/enl boot/ etc/ media/ opt/ root/ srv/ tmp/ var/ lib@sbin@ dev/ home/ mnt/proc/ run/ sys/ usr/ bin@ lib64@ - But now booting but hanging: #systemd-nspawn -bD /var/lib/machines/enl Spawning container enl on /var/lib/machines/enl. Press ^] three times within 1s to kill container. systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) Detected virtualization 'systemd-nspawn'. Detected architecture 'x86-64'. Running with unpopulated /etc. Welcome to Fedora 22 (Twenty Two)! Initializing machine ID from random generator. Populated /etc with preset unit settings. Unit etc.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Unit var.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. Startup finished in 51ms. Maybe my btrfs story ? Unit etc.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Unit var.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Will investigate. --bind was certainly the most easy trick once the raw image is downloaded. Lennart -- Lennart Poettering, Red Hat -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] install Fedora systemd-nspawn container on btrfs
On Thu, 23.04.15 19:00, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: On Thu, Apr 23, 2015 at 4:47 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 14:18, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: Pick one: a) download the raw image and use that, but it will be a loopback file with its own file system inside or: b) do the dnf/yum install root thing, and install it into a directory tree. I installed yum package on Arch but couldn't manage to do the install. # yum -y --releasever=22 --nogpg --installroot=/var/lib/machines/enl --disablerepo='*' --enablerepo=fedora install systemd passwd dnf fedora-release-server Error getting repository data for fedora, repository not found # yum repolist all repolist: 0 In fact, /etc/yum/repos.d is empty, so I am not surprised. Of course, you could use the .raw image, mount the extern btrfs volume into it via nspawn's --bind= switch, then use yum inside of that container to install into the btrfs volume. Then get rid of the .raw image again, and you still have the btrfs volume that should be bootable. A bit complex, but you almost were there already... ;-) Wunderbach # systemd-nspawn -M Fedora-Cloud-Base-22_Beta-20150415.x86_64.raw -- bind=/var/lib/machines/enl:/mnt [root@Fedora-Cloud-Base-22_Beta-20150415 ~]#dnf -y --releasever=22 --nogpg --installroot=/mnt --disablerepo='*' --enablerepo=fedora install systemd passwd dnf Complete! - $ ls /var/lib/machines/enl boot/ etc/ media/ opt/ root/ srv/ tmp/ var/ lib@sbin@ dev/ home/ mnt/proc/ run/ sys/ usr/ bin@ lib64@ - But now booting but hanging: #systemd-nspawn -bD /var/lib/machines/enl Spawning container enl on /var/lib/machines/enl. Press ^] three times within 1s to kill container. systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) Detected virtualization 'systemd-nspawn'. Detected architecture 'x86-64'. Running with unpopulated /etc. Welcome to Fedora 22 (Twenty Two)! Initializing machine ID from random generator. Populated /etc with preset unit settings. Unit etc.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Unit var.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. Startup finished in 51ms. Maybe my btrfs story ? Unit etc.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Unit var.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Will investigate. --bind was certainly the most easy trick once the raw image is downloaded. Hmm, my guess is that you somehow lost the /etc and /var directories half way, probably because of the weird mounting your are doing. --bind= should normally be recursive, but maybe this didn't work? 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] Complex supervision structures/delegating watchdog?
On Mon, 16.02.15 21:36, Holger Hans Peter Freyther (hol...@freyther.de) wrote:
Sorry for the late reply, still catching up with piles of email queued
up.
On Mon, Feb 16, 2015 at 11:21:53AM +0100, Lennart Poettering wrote:
Is your pppd daemon itself also a systemd service?
What precisely does monitor consist of for this case?
Yes, the pppd is invoked by systemd as a service. What I am
doing right now is:
link.service:
ExecStart=pppd call uplink ... nodetach
/etc/ppp/ip-up.d/NN-linkmon:
linkmon -i $PPP_IFACE -d 8.8.8.8 -p `cat /run/${PPP_IFACE}.pid`
The monitoring right now involves simple ICMP request and
depending on the outcome I change the metric of one of the
default routes. So in case some amount of packet loss is
reached the linkmon will SIGKILL the pid provided.
We have watchdog support already, with sd_notify(0, WATCHDOG=1), and
WatchdogSec=. But that requires you to run your pppd as a service of
its own, to be useful.
I thought the sd_notify is only possible by the main
application that got started?
Well, that's the way this was intended originally, but you actually
use it differently, by using NotifyAccess=all (instead of
NotifyAccess=main).
That said given your usecase I don#t really see how the watchdog
systemd implements would be helpful. After all the key words here
really are app specific monitoring rather than just ping watchdog.
So far whenever the question of monitoring came up I just said: we
provide the apis, you implement the monitoring, without going into
more detail. I figure we should put together some wiki page that
explains exactly how we think a monitoring tool would make use of
systemd's functionality, and actually figure out if we really have
everything in place to make it work nicely, and fill the gaps where we
don't.
E.g. in the above case the linkmon would be a child of pppd. My
application wouldn't run until pppd has setup the link. This means I
would need to configure a high enough timeout to cope with a
potential bigger set-up time.
Ideally, pppd would simply report back when it finished setting up the
connection. Then, the monitoring daemon could use After= on the ppd
service, and would be started only after the connection up. And it
should use BindsTo= to glue itself to the pppd instances.
I figure making pppd report back when it completed setting up the
connection is easy, by making use of the normal detach mode with
Type=forking and a PID file. Even better of course would be to patch
pppd to use sd_notify(READY=1) so that this ugliness with double
forking would be unnecessary
Hope this makes some sense,
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] config_parse_exec_mount_flags: get rid of unnecessary copy
On Fri, 13.02.15 09:49, Maciej Wereski (m.were...@partner.samsung.com) wrote: Dnia środa, 11 lutego 2015 13:08:26 Lennart Poettering pisze: This optimization is not valid. If 'word' is set to sh, then l will be 2, and strneq(word, shared, 2) is true, but we don't actually want to allow such abbreviations! Lennart True, I can use strlen(shared ) then as a n value in strneq. Or please at least change that: -else if (streq(word, private)) + else if (streq(t, private)) Indeed! Fixed now in git: http://cgit.freedesktop.org/systemd/systemd/commit/?id=8d9803b83c1f72e1bf158af4615b1c53a4749118 Sorry for the delay! 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] How can I map PID between host and container?
On Fri, 24.04.15 00:10, WaLyong Cho (walyong@samsung.com) wrote:
Hello,
I'm looking for a proper way what method to map PID between host and
container.
In case of systemctl, if I know pid in container(let's call this pid_c)
then I can find the pid in sight of host(let's call this pid_h) by using
systemctl -M {container} pid_c in host shell. But I can not find pid_c
when I know pid_h by using systemctl status pid_h.
The former seems possible by parsing machine cgroup.
In the latter case, can we also find the pid_c?
And is there any other method to map between those?
For example, when if I use lxc then how I find each pid? (lxc-ps?)
According to my search, namespace can give me some of hints about this.
I could not find more detail.
Is there any proper libs or tools for this?
The kernel doesn't have any nice userspace APIs to translate PIDs like
this, to my knowledge at least.
That said, one can implement something like this by using the fact
that the kernel will translate user credentials that are sent via
AF_UNIX SCM_CREDENTIALS that pass through a PID namespace
boundary. hence, let's say you have one pid $n that identifies the
namespace you care about, and a container pid $a you want to translate
to host pid $b, then you'd create an AF_UNIX/SOCK_SEQPACKET
socketpair(), fork(), run setns() in the child to join the namespace
of $n, and send a single datagram to the parent with sendmsg(), while
explicitly specifiying the SCM_CREDENTIALS auxiliary field with the $a
in it, and exit. In the parent you use recvmsg() to read that datagram
with its SCM_CREDENTIALS, and use the pid you see as $b. Vice versa,
if you want to translate the other way you would send the datagram the
other way.
nasty? absolutely! (also, only available for privileged processes, due
to the setns() call).
I am not aware of any nicer way.
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] udisks in systemd user-sessions (or kdbus in future)
On Mon, 09.03.15 12:32, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: Sorry for the late response, still trying to process all the queued emails. systemd/kdbus developers: is this consistent with how you think situations like this should work in the kdbus-based future? Yes, I believe there is no point in trying to ever prohibit access between sessions of the same user. That's not how UNIX works, and is doomed to be pointless anyway. So yeah, the logic should be that a process should be allowed to access *any* disk that is on any seat the process' user is currently *active* on, regardless in which precise session that process is or to which actual seat that process' session is at attached. If I log in once on seat A, and once on seat B, I should be able to access A's devices from seat B the same way as B's. And from A I should be able to access the devices of both A and B, too. And there should only be a single PK action for this. 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] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidj...@gmail.com) wrote: What does this actually do? Is the specified key file read from the specified device? It reads keyfile from filesystem on device identifed by keyfile_device. The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? keyfile is mandatory, keyfile_device is optional and can be omitted. I believe dracut looked at all existing devices then. This order makes it easier to omit optional parameter(s). Well, whether it is [device:]file or file[:device] is hardly any difference for the parser... Does it really matter? Well, we might as well implement this in the most obvious way if it is not a completely standard feature yet. To me it appears that only one initrd supported it, and it lost it a while back without too much complaining... But anyway, I don't mind too much. The Is this specific to Dracut so far? Is this widely used, and something that we really want. I can say about dracut only but yes, it is used and it is serious regression when it is used comparing with pre-systemd version. Can you point me to documentation about the previous features in this regard? Which initrd implementations are you referring to? Sure, in dracut manual page: crypto LUKS - key on removable device support rd.luks.key=keypath:keydev:luksdev keypath is a path to key file to look for. It’s REQUIRED. When keypath ends with .gpg it’s considered to be key encrypted symmetrically with GPG. You will be prompted for password on boot. GPG support comes with crypt-gpg module which needs to be added explicitly. To make this clear: the gpg support is crazy. I don't want to see that in systemd at all. Also, so far we don't allow luksdev to be specified for any of the other options, such as luks.options or so. I am not convinced we should support that here. I'd be willing to merge a patch that supports basic rd.luks.key=keypath:keydev, even though I think it's usecase is more security theater than really useful. But please put the temporary mount into /run, keep it minimal, define a clear trigger to unmount it, no gpg, no luksdev support. 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] Failure(s) Building Systemd with --enable-resolved
Lennart Poettering lenn...@poettering.net wrote on 04/23/2015 09:59:38 AM: On Thu, 23.04.15 09:43, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: I cloned down the master branch yesterday and tried to build, but got: src/shared/random-util.c:26:22: fatal error: sys/auxv.h: No such file or directory Which is new. Apparently sys/auxv.h was added in eglibc 2.16, and I'm stuck with eglibc 2.15, so that's a new unrelated wrinkle. See the README, we require 2.16. Please update your glibc first! Well, yeah, now systemd requires 2.16, but 219 doesn't, unless that was an oversight. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] install Fedora systemd-nspawn container on btrfs
On Thu, Apr 23, 2015 at 7:12 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 19:00, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: On Thu, Apr 23, 2015 at 4:47 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 14:18, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: Pick one: a) download the raw image and use that, but it will be a loopback file with its own file system inside or: b) do the dnf/yum install root thing, and install it into a directory tree. I installed yum package on Arch but couldn't manage to do the install. # yum -y --releasever=22 --nogpg --installroot=/var/lib/machines/enl --disablerepo='*' --enablerepo=fedora install systemd passwd dnf fedora-release-server Error getting repository data for fedora, repository not found # yum repolist all repolist: 0 In fact, /etc/yum/repos.d is empty, so I am not surprised. Of course, you could use the .raw image, mount the extern btrfs volume into it via nspawn's --bind= switch, then use yum inside of that container to install into the btrfs volume. Then get rid of the .raw image again, and you still have the btrfs volume that should be bootable. A bit complex, but you almost were there already... ;-) Wunderbach # systemd-nspawn -M Fedora-Cloud-Base-22_Beta-20150415.x86_64.raw -- bind=/var/lib/machines/enl:/mnt [root@Fedora-Cloud-Base-22_Beta-20150415 ~]#dnf -y --releasever=22 --nogpg --installroot=/mnt --disablerepo='*' --enablerepo=fedora install systemd passwd dnf Complete! - $ ls /var/lib/machines/enl boot/ etc/ media/ opt/ root/ srv/ tmp/ var/ lib@sbin@ dev/ home/ mnt/proc/ run/ sys/ usr/ bin@ lib64@ - But now booting but hanging: #systemd-nspawn -bD /var/lib/machines/enl Spawning container enl on /var/lib/machines/enl. Press ^] three times within 1s to kill container. systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) Detected virtualization 'systemd-nspawn'. Detected architecture 'x86-64'. Running with unpopulated /etc. Welcome to Fedora 22 (Twenty Two)! Initializing machine ID from random generator. Populated /etc with preset unit settings. Unit etc.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Unit var.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. Startup finished in 51ms. Maybe my btrfs story ? Unit etc.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Unit var.mount is bound to inactive unit dev-sdb1.device. Stopping, too. Will investigate. --bind was certainly the most easy trick once the raw image is downloaded. Hmm, my guess is that you somehow lost the /etc and /var directories half way, probably because of the weird mounting your are doing. --bind= should normally be recursive, but maybe this didn't work? root@hortensia ➤➤ lib/machines # ls poppy/etc lvm/systemd/ groupld.so.cache machine-id os-release@ resolv.conf pam.d/ udev/ gshadow localtime@ nsswitch.conf passwd shadow /etc seems correctly populated. Container boot but can't have login prompt. It hangs with no possibility to enter anything. Lennart -- Lennart Poettering, Red Hat -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failure(s) Building Systemd with --enable-resolved
Lennart Poettering lenn...@poettering.net wrote on 04/23/2015 10:35:12 AM: On Thu, 23.04.15 10:16, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: Lennart Poettering lenn...@poettering.net wrote on 04/23/2015 09:59:38 AM: On Thu, 23.04.15 09:43, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: I cloned down the master branch yesterday and tried to build, but got: src/shared/random-util.c:26:22: fatal error: sys/auxv.h: No such file or directory Which is new. Apparently sys/auxv.h was added in eglibc 2.16, and I'm stuck with eglibc 2.15, so that's a new unrelated wrinkle. See the README, we require 2.16. Please update your glibc first! Well, yeah, now systemd requires 2.16, but 219 doesn't, unless that was an oversight. Yeah, it kinda was. See 3dd26f3e3aa7fa0696d304e14551362133dd281f. That said, if this is just about IP_UNICAST_IF, I'd be willing to merge a patch that adds this to missing.h I wouldn't worry too much about it. I just need to figure out how to upgrade my stuff.___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] user units and system units behavior
On Mon, 16.02.15 11:14, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: No, mine /etc/X11/xinitrc.d is Simon's /etc/X11/Xsession.d and similar setups. It's apparently a distro-specific path. Yes. I think /etc/X11/xinitrc.d is what Red Hat and its derivatives use. Xsession.d is used instead in Debian and its derivatives, including Ubuntu. The differences are because, historically, this sort of plumbing was something that every distribution had to invent for itself. Would be happy to take a patch that makes xinitrcdir in Makefile.am configurable via configure, so that we can drop 50-systemd-user.sh into the right place on either distro. 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] Another attempt: Making dependencies properly overridable
On 04/23/2015 08:36 PM, Lennart Poettering wrote: I mean, so far the deps we set are combined from: unit file (1) + dropins(2) + .wants/ + .requires/ symlinks (3) + automatic deps (4) + deps configured in other units (5) I'd allow unsetting deps configured in (1) from (1), (2) and (3). I'd allow unsetting deps configured in (2) from (2) and (3). I'd allow unsetting deps made in (3) from (3). I would not allow unsetting deps made in (1,2,3) with (4) or (5), or vice versa. That makes sense, I'll incorporate that. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Another attempt: Making dependencies properly overridable
On 04/23/2015 08:38 PM, Lennart Poettering wrote: On Sun, 19.04.15 09:29, Andrei Borzenkov (arvidj...@gmail.com) wrote: Unless I'm mistaken, the only real change is that Wants= will clear list, just like it does it for ExecStart=. This should be rather straightforward to implement I guess. Actually it's not that easy. You need to collect the deps created from unit configuration into a set of hashmaps of their own, and then add a final commit step that merges those into the real deps. And if we want to do this without needless copies and allocations this is actually not easy at all. Yes, I know, because I'm currently working on a patch for this. ;-) I'll probably send a first version in a couple of days. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] sysusers: allow separate alternate roots for configs and modifications
On 2015-04-23 at 17:15 +0200, Lennart Poettering wrote: On Thu, 23.04.15 18:09, Ivan Shapovalov (intelfx...@gmail.com) wrote: On 2015-04-23 at 16:48 +0200, Lennart Poettering wrote: On Thu, 23.04.15 17:46, Ivan Shapovalov (intelfx...@gmail.com) wrote: On 2015-04-23 at 14:11 +0200, Lennart Poettering wrote: On Thu, 26.02.15 02:46, Ivan Shapovalov (intelfx...@gmail.com ) wrote: This is useful, for example, to create system accounts on an initramfs using the host's configuration. Hmm, but you can already do this, by specifiying the config files on the command line, no? Actually, this means duplicating the logic of determining of the directory list (/usr/lib vs /lib, ...). True, but it's not *that* complex in that case... Not really, because it is then also needed to do priority -overriding of the configuration snippets by hand. I would really like to avoid re -implementing this logic. There is an alternative to bind-mount all configuration directories into the destination root, but it's not atomic against killing of the process (if we get killed in between, stale bind mounts will remain). So I won't like to do this either. I'm sure that mkinitcpio maintainer in arch will not accept this solution as well. Any other options? Hmm, I don't really see the use for this I must say. That said, I figure I would accept a patch that adds a new switch --configuration-root= or so, similar to your original patch, but leaves --root= as it is right now, and really only adds a new --configuration-root= that if specified overrides the root directory otherwise specified for the reading of the configuration files. If you add this tmpfiles should probably get something similar, to make this match up nicely... Actually, thinking about this once more, I've realized that my usecase is broken. I wanted to use systemd-sysusers to generate new passwd/group for the initcpio, but never realized that newly created UIDs and GIDs can mismatch the host ones (and we are copying files from the host). So, disregard this patch, there is indeed no usecase so far. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev leaves dangling symlinks
Thanks for this, and sorry for the delay! Fix pushed. Tom On Thu, Apr 16, 2015 at 9:51 PM, Mantas Mikulėnas graw...@gmail.com wrote: So recently I noticed that udev no longer deletes /dev symlinks for removed devices, leaving quite a few dangling links over time (and greatly confusing udisks as a side effect). This was broken by: commit 3c0bab4aaf70b2383aa4cbabf6059c48744e8960 Author: Tom Gundersen t...@jklm.no Date: Fri Mar 6 18:22:35 2015 +0100 udevd: event - make db loading lazy in REMOVE event handling But udev_node_remove() needs the DB to know about symlinks, so… -- 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 mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] journal: use audit event names instead of numbers
On Mon, Apr 20, 2015 at 05:06:33PM +0200, Lennart Poettering wrote:
On Mon, 20.04.15 14:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Mon, Apr 20, 2015 at 04:43:20PM +0200, Lennart Poettering wrote:
On Tue, 14.04.15 21:58, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
wrote:
+const char *audit_type_name(int type,
+char buf[AUDIT_NAME_BUF_SIZE]) {
+const char *s;
+
+s = audit_type_to_string(type);
+if (s)
+return s;
+
+/* This is inspired by DNS TYPEnnn formatting */
+snprintf(buf, AUDIT_NAME_BUF_SIZE, AUDIT%04i, type);
+return buf;
Shouldn't we stick to audit-xyz at least, to stay congruent to what
we so far did, at least for the unknown ones?
I thought the visual difference between the capitalized names and what we
used so far is too big: e.g. ADD_USER and audit-1114, and it is better
to have something visually similar at least.
Hmm, I see. You do have a point, hence go ahead.
Also, may turn this into a macro expression using ({}) that returns
this as alloca() allocated string?
You mean the whole function? I'll try that. The only downside is it
cannot be called directly in the args to another function.
Yeah, the whole function.
Make sure to name this in a way that it is clear that this is an
alloca()-based macro, by including an _alloca() suffix or so?
Also see procfs_file_alloca() or inspiration.
I now pushed something along those lines. Seems simple enough
not to warrant another posting to the mailing list.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Another attempt: Making dependencies properly overridable
On 23 April 2015 at 14:58, Christian Seiler christ...@iwakd.de wrote: On 04/23/2015 08:36 PM, Lennart Poettering wrote: I mean, so far the deps we set are combined from: unit file (1) + dropins(2) + .wants/ + .requires/ symlinks (3) + automatic deps (4) + deps configured in other units (5) I'd allow unsetting deps configured in (1) from (1), (2) and (3). I'd allow unsetting deps configured in (2) from (2) and (3). I'd allow unsetting deps made in (3) from (3). I would not allow unsetting deps made in (1,2,3) with (4) or (5), or vice versa. That makes sense, I'll incorporate that. I like this as well. -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
On 23 April 2015 at 13:08, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidj...@gmail.com) wrote: What does this actually do? Is the specified key file read from the specified device? It reads keyfile from filesystem on device identifed by keyfile_device. The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? keyfile is mandatory, keyfile_device is optional and can be omitted. I believe dracut looked at all existing devices then. This order makes it easier to omit optional parameter(s). Well, whether it is [device:]file or file[:device] is hardly any difference for the parser... Does it really matter? Well, we might as well implement this in the most obvious way if it is not a completely standard feature yet. To me it appears that only one initrd supported it, and it lost it a while back without too much complaining... But anyway, I don't mind too much. The debian's initramfs-tools, but not ubuntu's, support keyfile on usb-disk for unlocking luks volumes. the exact name of the option and semantics to specify it to initramfs-tools is different from dracut's (but that's typical) but said equivalent feature does exist in the major other initramfs implementation. Is this specific to Dracut so far? Is this widely used, and something that we really want. I can say about dracut only but yes, it is used and it is serious regression when it is used comparing with pre-systemd version. Can you point me to documentation about the previous features in this regard? Which initrd implementations are you referring to? Sure, in dracut manual page: crypto LUKS - key on removable device support rd.luks.key=keypath:keydev:luksdev keypath is a path to key file to look for. It’s REQUIRED. When keypath ends with .gpg it’s considered to be key encrypted symmetrically with GPG. You will be prompted for password on boot. GPG support comes with crypt-gpg module which needs to be added explicitly. To make this clear: the gpg support is crazy. I don't want to see that in systemd at all. Also, so far we don't allow luksdev to be specified for any of the other options, such as luks.options or so. I am not convinced we should support that here. I'd be willing to merge a patch that supports basic rd.luks.key=keypath:keydev, even though I think it's usecase is more security theater than really useful. But please put the temporary mount into /run, keep it minimal, define a clear trigger to unmount it, no gpg, no luksdev support. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`
On 2015-04-08 at 19:28 +0200, Lennart Poettering wrote: On Mon, 23.03.15 16:04, Ivan Shapovalov (intelfx...@gmail.com) wrote: Hello, is it possible/allowed/desired to support assigning ExecStartPre= and similar options via dbus interface, i. e. in `systemctl set -property` or `systemd-run -p`? So far our philosophy for allowing dynamically changable properties is that we do this only for properties we can actually really alter dynamically at runtime. For example, properties that map to cgroup attributes are of this kind, as we can pass them to the kernel immediately so that they take effect. However, other properties, like for example the nice level are not of this kind, since we can reasonably set them only while forking off processes, and afterwards it is not clear what to set them on (just the main process? all processes? and what to do if the service altered its own nice level, and applied different levels to different procecesses, what do we do then?). ExecStartPre= is a property we cannot really adjust dynamically, after all it specifies what to execute, and that's only relevant during service startup? I'm hitting a usecase when I need to run a service with multiple executed processes via `systemd-run`. I think this makes sense to support, isn't it? Can you elaborate on this? A service with multiple processes? In parallel? Normally we recommend a 1:1 mapping between services and forked off processes, i.e. never fork off multiple processes for the same service (unless the service does that internally...). The only exception to this logic is for Type=oneshot services, where we allow multiple processes, but only serialized, not parallel. Anyway, I don't really grok what you want to to... OK, in avoidance of an X-Y problem, I'll describe the initial task. I would like to run a vnc connection tunneled over ssh. This requires running two binaries: an ssh client in TCP port forwarding mode and a vnc client. They are started one after another. The second one is terminated at user's choice, the first one has no knowledge of vnc session ended and hence should be manually terminated. This could be solved with templated units, but there is more than one parameter to pass (both to ssh and vnc clients). So, I need to generate units on the fly. There are three possibilities: - generate two units manually and somehow mark them as transient so that they will be removed after stop - do `systemd-run` twice and somehow set up the dependencies between two transient units - do `systemd-run` once, starting ssh client in ExecStartPre= and vnc client in ExecStart= Neither of these is possible at the moment. How can this be achieved? Thanks, -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Both volatile and persistent journald logs
I am migrating to systemd/journald (via an upgrade from Debian wheezy to jessie) and I've come across a problem migrating that is peculiar to my setup. I currently have /var/log on an SSD. I also have some noisy logs. In attempt to not have rsyslog write continuously to the SSD, I have set up some syslog facilities and special filters to log to /run/log files instead of /var/log for those noise logs. I have an hourly cron job that runs logrotate on the /run/log files and appends the rotated log (the .1 file) to the persistent logs in /var/log. I would like to be able to do something similar with journald. The specifics of my logging that is temporarily volatile is captured in these rsyslog configs: local1.*/tmp/log/dnsmasq.log local4.*/tmp/log/ldap.log if $syslogfacility-text == 'kern' and $msg contains 'firewall:' then /tmp/log/firewall.log I am aware that on an unclean shutdown these logs get lost. I am ok with that. They are mostly useful for realtime debugging and not historical analysis. In the rare event of an unclean shutdown, I accept this loss (I've not yet had such a shutdown). Is there a way to configure journald to do something similar? Is there some other mechanism that can address excessive log writing to an SSD? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] zsh-completion: add missing completions for machinectl
On Wed, Apr 22, 2015 at 12:30:32PM -0700, Lukas Rusak wrote:
Ah, completely missed images. So perhaps something like this would be
better?
machinectl --full --no-legend --no-pager list-images | awk '{print $1}'
We usually try to avoid running external programs unless necessary. This
can be implemented in pure shell which should be slightly faster.
I think you can ignore spaces for now. This is just tab completion after all,
it doesn't have to be bullet proof, and using spaces in image names would be
fairly exotic.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald-remote problem
Excerpts from Eric's message of 2015-04-22 21:14:56 +0900: Hi, I'm trying to sync my vps log to laptop. They are connected with openvpn. Both laptop and vps are, - Arch Linux - systemd 219-5 - vps: 10.8.0.1 - laptop: 10.8.0.6 It is already secured by openvpn tunnel. So I tried with normal http settings. Services are launched successfully. There is nothing happening in journal. Also there is nothing in /var/log/journal/remote/ . Also I tried example from man page. ~~~ $ ll /tmp/jjj -rw-r--r-- 1 a a 0 Apr 22 15:54 /tmp/jjj $ journalctl -o export | /usr/lib/systemd/systemd-journal-remote -o /tmp/jjj - Received 0 descriptors Using standard input as source. Failed to open output journal /tmp/jjj: Invalid argument Failed to get writer for source stdin: Invalid argument Failed to create source for fd:0 (stdin): Invalid argument ~~~ Am I doing right? I attach config and service file. Thanks. # laptop ; 10.8.0.6 # /etc/systemd/system/systemd-journal-remote.socket [Unit] Description=Journal Remote Sink Socket [Socket] ListenStream=10.8.0.6:19532 [Install] WantedBy=sockets.target # laptop ; 10.8.0.6 # /etc/systemd/system/systemd-journal-remote.service [Unit] Description=Journal Remote Sink Service Requires=systemd-journal-remote.socket [Service] ExecStart=/usr/lib/systemd/systemd-journal-remote \ --listen-http=-3 \ --output=/var/log/journal/remote/ User=systemd-journal-remote Group=systemd-journal-remote PrivateTmp=yes PrivateDevices=yes PrivateNetwork=yes WatchdogSec=10min [Install] Also=systemd-journal-remote.socket # vps ; 10.8.0.1 # /usr/lib/systemd/system/systemd-journal-upload.service [Unit] Description=Journal Remote Upload Service After=network.target [Service] ExecStart=/usr/lib/systemd/systemd-journal-upload \ --save-state User=systemd-journal-upload PrivateTmp=yes PrivateDevices=yes WatchdogSec=20min [Install] WantedBy=multi-user.target # vps ; 10.8.0.1 # /etc/systemd/journal-remote.conf [Upload] URL=http://10.8.0.6 It's working now. It was quite long journey. The problem was journald-upload process couldn't read journal file. I had run with strace and it repeatedly said like this, (open /var/log/.../system.journal, PERMISSION DENIED). $ ls -l /var/log/journal/.../system.journal -rw-r-+ 1 root systemd-journal 8388608 Apr 23 21:08 /var/log/journal/87dd383134bc4070950aa51ab6cbd793/system.journal I added systemd-journal-upload user to systemd-journal group then it's working. Next step would be automatically trigger syncing when vpn connection ready. 1. Power on laptop 2. openvpn service up 3. journal-remote up 4. send notification to vps 5. journal-upload up (vps) 6. syncing until vpn disconnect If I could just retry journald-upload periodically, It would be good enough. Any advice would be appreciated. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Both volatile and persistent journald logs
On Thu, 23.04.15 06:58, Cam Hutchison (c...@xdna.net) wrote: I am migrating to systemd/journald (via an upgrade from Debian wheezy to jessie) and I've come across a problem migrating that is peculiar to my setup. I currently have /var/log on an SSD. I also have some noisy logs. In attempt to not have rsyslog write continuously to the SSD, I have set up some syslog facilities and special filters to log to /run/log files instead of /var/log for those noise logs. I have an hourly cron job that runs logrotate on the /run/log files and appends the rotated log (the .1 file) to the persistent logs in /var/log. I would like to be able to do something similar with journald. The specifics of my logging that is temporarily volatile is captured in these rsyslog configs: local1.*/tmp/log/dnsmasq.log local4.*/tmp/log/ldap.log if $syslogfacility-text == 'kern' and $msg contains 'firewall:' then /tmp/log/firewall.log journald does not allow seperate log files or filter expressions, please use rsyslog or another syslog daemon for things like this. The idea behind the journal is to place everything in a big pool and filter on read access only, only splitting things into multiple files where rotation or access control demand it. I am aware that on an unclean shutdown these logs get lost. I am ok with that. They are mostly useful for realtime debugging and not historical analysis. In the rare event of an unclean shutdown, I accept this loss (I've not yet had such a shutdown). Is there a way to configure journald to do something similar? Noep, sorry. Is there some other mechanism that can address excessive log writing to an SSD? There has been a feature request to allow writing to journal files in /run and /var in parallel, arbitrating by the log level. I'd be happy to support something like that, which would allow storing debug messages only in /run, but the more important one in /var. However, that's not going to deliver what you are asking for. Sorry, 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] install Fedora systemd-nspawn container on btrfs
On Thu, Apr 23, 2015 at 1:50 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: Not sure what I did wrong, but I can't install/boot my nspawn container. Here is my setup: Archlinux box- updated 1- created 3 btrfs subvol on /dev/sdb1 (SSD). The goal is to manage snapshots easily. no nested subvol. -- # btrfs subvolume list . ID 266 gen 39 top level 5 path rootvol ID 268 gen 41 top level 5 path var ID 269 gen 42 top level 5 path etc # btrfs filesystem show Label: 'poppy-root' uuid: ef1b44cd-e7b0-4166-b933-e7d4d20a1171 Total devices 1 FS bytes used 64.00KiB devid1 size 80.00GiB used 12.00MiB path /dev/sdb1 -- 2 - mount btrfs subvol --- # mount -t btrfs -o subvol=rootvol /dev/sdb1 /var/lib/machines/enl # mkdir /var/lib/machines/enl/var # mkdir /var/lib/machines/enl/etc # mount -t btrfs -o subvol=etc /dev/sdb1 /var/lib/machines/enl/etc # mount -t btrfs -o subvol=var /dev/sdb1 /var/lib/machines/enl/var THis isn't really how one would normally use subvolumes. No need to mount each subvolume explicitly, they are just special directories... 3- install fedora minimal and boot it - # machinectl pull-raw --verify=no http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/22/Cloud/Images/x86_64/Fedora-Cloud-Base-22_Beta-20150415-x86_64.raw.xz $ tar # systemd-nspawn -M Fedora-Cloud-Base-22_Beta-20150415.x86_64.raw Spawning container Fedora-Cloud-Base-22_Beta-20150415.x86_64.raw on /var/lib/machines/Fedora-Cloud-Base-22_Beta-20150415.x86_64.raw. Press ^] three times within 1s to kill container. [root@Fedora-Cloud-Base-22_Beta-20150415 ~]# 4- install Fedora on /var/lib/machines/enl -- [root@Fedora-Cloud-Base-22_Beta-20150415 ~]# dnf -y --releasever=22 --nogpg --installroot=/var/lib/machines/MyContainer --disablerepo='*' --enablerepo=fedora install systemd passwd dnf fedora-release-server vim-minimal .. INSTALL ... Complete! -- Hmm? With this command you installed another fedora inside the raw fedora image you downloaded. You now have three linuxes, installed within each other... I suspected such kind of thing indeed. In the container, /var/lib/machines is in fact inside the container and not on my host! Stupid. Pick one: a) download the raw image and use that, but it will be a loopback file with its own file system inside or: b) do the dnf/yum install root thing, and install it into a directory tree. I installed yum package on Arch but couldn't manage to do the install. # yum -y --releasever=22 --nogpg --installroot=/var/lib/machines/enl --disablerepo='*' --enablerepo=fedora install systemd passwd dnf fedora-release-server Error getting repository data for fedora, repository not found # yum repolist all repolist: 0 In fact, /etc/yum/repos.d is empty, so I am not surprised. Do either of those in the host, not in the container. Lennart -- Lennart Poettering, Red Hat -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] install Fedora systemd-nspawn container on btrfs
On Thu, Apr 23, 2015 at 2:00 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 14:57, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Thu, Apr 23, 2015 at 2:50 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: Not sure what I did wrong, but I can't install/boot my nspawn container. Here is my setup: Archlinux box- updated 1- created 3 btrfs subvol on /dev/sdb1 (SSD). The goal is to manage snapshots easily. no nested subvol. -- # btrfs subvolume list . ID 266 gen 39 top level 5 path rootvol ID 268 gen 41 top level 5 path var ID 269 gen 42 top level 5 path etc # btrfs filesystem show Label: 'poppy-root' uuid: ef1b44cd-e7b0-4166-b933-e7d4d20a1171 Total devices 1 FS bytes used 64.00KiB devid1 size 80.00GiB used 12.00MiB path /dev/sdb1 -- 2 - mount btrfs subvol --- # mount -t btrfs -o subvol=rootvol /dev/sdb1 /var/lib/machines/enl # mkdir /var/lib/machines/enl/var # mkdir /var/lib/machines/enl/etc # mount -t btrfs -o subvol=etc /dev/sdb1 /var/lib/machines/enl/etc # mount -t btrfs -o subvol=var /dev/sdb1 /var/lib/machines/enl/var THis isn't really how one would normally use subvolumes. No need to mount each subvolume explicitly, they are just special directories... As long as you never clone parent volume (but why use btrfs then?) As soon as you create clone or snapshot of parent volume, all childs will be out of place in it unless you explicitly mount them in correct place in hierarchy. Hmm? not following. The btrfs tool surely doesn't do recursive snapshots currently. But it doesn't reinstate mount points either (or even makes them persistent), hence I really don't get what you are saying. (note that machined's clone command in git *does* recursive snapshots) I am not a Btrfs expert, but from what I understood, and after some posts on Btrfs ML[0], creating and mounting these subvol was the right way to easily manage snapshots. [0]http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg42856.html Lennart -- Lennart Poettering, Red Hat -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journalctl Unit Completion Optmization
On Wed, Apr 22, 2015 at 06:37:06PM +0200, Lennart Poettering wrote: On Tue, 03.03.15 23:02, Justin Brown (justin.br...@fandingo.org) wrote: Hello, I've recently been using journalctl on one of my longer-lived systems, and I'm running into a slight annoyance. Most of the time I'm using `journalctl -u unit -e`. I use tab completion for the unit name, and the annoyance is the long pause journalctl takes to complete a unit. With cold cache (meaning writing 3 to /proc/sys/vm/drop_caches), this takes 23 seconds on a system using Btrfs on a SATA3 SSD. With warm cache, it still takes 3-4 seconds. Both cases are quite a bit slower than normal tab completion behavior. Is it really that bad if the files on btrfs are defragmented properly? Note that btrfs is notoriously bad at handling journald's write pattern currently, which results in heavily fragmented files. Use the filefrag tool to check how fragmented they are, and use btrfs defrag to the fix this. Before we look into other options I'd really prefer if you could check if this already fixes your issues. (Note that very recent journald will set the btrfs NOCOW flag now on the journal files, which should work around this issue.) Also make sure that you're running recent enough and have commit v219-99-g950c07d421. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] install Fedora systemd-nspawn container on btrfs
On Thu, 23.04.15 14:57, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Thu, Apr 23, 2015 at 2:50 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: Not sure what I did wrong, but I can't install/boot my nspawn container. Here is my setup: Archlinux box- updated 1- created 3 btrfs subvol on /dev/sdb1 (SSD). The goal is to manage snapshots easily. no nested subvol. -- # btrfs subvolume list . ID 266 gen 39 top level 5 path rootvol ID 268 gen 41 top level 5 path var ID 269 gen 42 top level 5 path etc # btrfs filesystem show Label: 'poppy-root' uuid: ef1b44cd-e7b0-4166-b933-e7d4d20a1171 Total devices 1 FS bytes used 64.00KiB devid1 size 80.00GiB used 12.00MiB path /dev/sdb1 -- 2 - mount btrfs subvol --- # mount -t btrfs -o subvol=rootvol /dev/sdb1 /var/lib/machines/enl # mkdir /var/lib/machines/enl/var # mkdir /var/lib/machines/enl/etc # mount -t btrfs -o subvol=etc /dev/sdb1 /var/lib/machines/enl/etc # mount -t btrfs -o subvol=var /dev/sdb1 /var/lib/machines/enl/var THis isn't really how one would normally use subvolumes. No need to mount each subvolume explicitly, they are just special directories... As long as you never clone parent volume (but why use btrfs then?) As soon as you create clone or snapshot of parent volume, all childs will be out of place in it unless you explicitly mount them in correct place in hierarchy. Hmm? not following. The btrfs tool surely doesn't do recursive snapshots currently. But it doesn't reinstate mount points either (or even makes them persistent), hence I really don't get what you are saying. (note that machined's clone command in git *does* recursive snapshots) 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 1/3] sysusers: allow separate alternate roots for configs and modifications
On Thu, 26.02.15 02:46, Ivan Shapovalov (intelfx...@gmail.com) wrote: This is useful, for example, to create system accounts on an initramfs using the host's configuration. Hmm, but you can already do this, by specifiying the config files on the command line, no? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] 628c89cc (tentative devices) + disk/by-label udev rule
It is not uncommon that file systems have the same volume label, especially on flash drives. disk/by-label udev rule in 60-persistent-storage.rules generates a symb link to the device. 2 devices might have the same label link if they have same label. After 628c89cc, this becomes very visible with Device dev-disk-by\x2dlabel-Axis.device appeared twice with different sysfs paths error message. The LABEL field of the volumes are relatively short (11 char on vfat, 16 on ext4). It won't be unique. How can we solve it? What is the purpose of the disk/by-label rule? Who uses that device node? Umut ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 628c89cc (tentative devices) + disk/by-label udev rule
On Thu, Apr 23, 2015 at 2:20 PM, Umut Tezduyar Lindskog u...@tezduyar.com wrote: It is not uncommon that file systems have the same volume label, especially on flash drives. disk/by-label udev rule in 60-persistent-storage.rules generates a symb link to the device. 2 devices might have the same label link if they have same label. After 628c89cc, this becomes very visible with Device dev-disk-by\x2dlabel-Axis.device appeared twice with different sysfs paths error message. The LABEL field of the volumes are relatively short (11 char on vfat, 16 on ext4). It won't be unique. How can we solve it? What is the purpose of the disk/by-label rule? Who uses that device node? mount LABEL=foo /mnt ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 2/2] Add more firewire properties for sound, to be closer to USB and PCI
On Wed, 22.04.15 21:05, Adam Goode (ago...@google.com) wrote: USB and PCI soundcards have a nice set of ID_* properties. It would be handy for firewire soundcards to have the same. Note that this removes the explicit setting of ID_ID in the firewire conditional. Because we are now setting ID_SERIAL, ID_ID will come from later in the file. Applied both. Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] install Fedora systemd-nspawn container on btrfs
Not sure what I did wrong, but I can't install/boot my nspawn container. Here is my setup: Archlinux box- updated 1- created 3 btrfs subvol on /dev/sdb1 (SSD). The goal is to manage snapshots easily. no nested subvol. -- # btrfs subvolume list . ID 266 gen 39 top level 5 path rootvol ID 268 gen 41 top level 5 path var ID 269 gen 42 top level 5 path etc # btrfs filesystem show Label: 'poppy-root' uuid: ef1b44cd-e7b0-4166-b933-e7d4d20a1171 Total devices 1 FS bytes used 64.00KiB devid1 size 80.00GiB used 12.00MiB path /dev/sdb1 -- 2 - mount btrfs subvol --- # mount -t btrfs -o subvol=rootvol /dev/sdb1 /var/lib/machines/enl # mkdir /var/lib/machines/enl/var # mkdir /var/lib/machines/enl/etc # mount -t btrfs -o subvol=etc /dev/sdb1 /var/lib/machines/enl/etc # mount -t btrfs -o subvol=var /dev/sdb1 /var/lib/machines/enl/var 3- install fedora minimal and boot it - # machinectl pull-raw --verify=no http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/22/Cloud/Images/x86_64/Fedora-Cloud-Base-22_Beta-20150415-x86_64.raw.xz $ tar # systemd-nspawn -M Fedora-Cloud-Base-22_Beta-20150415.x86_64.raw Spawning container Fedora-Cloud-Base-22_Beta-20150415.x86_64.raw on /var/lib/machines/Fedora-Cloud-Base-22_Beta-20150415.x86_64.raw. Press ^] three times within 1s to kill container. [root@Fedora-Cloud-Base-22_Beta-20150415 ~]# 4- install Fedora on /var/lib/machines/enl -- [root@Fedora-Cloud-Base-22_Beta-20150415 ~]# dnf -y --releasever=22 --nogpg --installroot=/var/lib/machines/MyContainer --disablerepo='*' --enablerepo=fedora install systemd passwd dnf fedora-release-server vim-minimal .. INSTALL ... Complete! -- 5- Now, nothing !! % ls -a /var/lib/machines/enl ./ ../ etc/ var/ # systemd-nspawn -bD /var/lib/machines/enl [sudo] password for root: Directory /var/lib/machines/enl doesn't look like an OS root directory (os-release file is missing). Refusing. --- Not sure if my issue comes from a wrong Btrfs setup, or if I missed something when installing from the cloud minimal Fedora. Thank you for hints -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] install Fedora systemd-nspawn container on btrfs
On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: Not sure what I did wrong, but I can't install/boot my nspawn container. Here is my setup: Archlinux box- updated 1- created 3 btrfs subvol on /dev/sdb1 (SSD). The goal is to manage snapshots easily. no nested subvol. -- # btrfs subvolume list . ID 266 gen 39 top level 5 path rootvol ID 268 gen 41 top level 5 path var ID 269 gen 42 top level 5 path etc # btrfs filesystem show Label: 'poppy-root' uuid: ef1b44cd-e7b0-4166-b933-e7d4d20a1171 Total devices 1 FS bytes used 64.00KiB devid1 size 80.00GiB used 12.00MiB path /dev/sdb1 -- 2 - mount btrfs subvol --- # mount -t btrfs -o subvol=rootvol /dev/sdb1 /var/lib/machines/enl # mkdir /var/lib/machines/enl/var # mkdir /var/lib/machines/enl/etc # mount -t btrfs -o subvol=etc /dev/sdb1 /var/lib/machines/enl/etc # mount -t btrfs -o subvol=var /dev/sdb1 /var/lib/machines/enl/var THis isn't really how one would normally use subvolumes. No need to mount each subvolume explicitly, they are just special directories... 3- install fedora minimal and boot it - # machinectl pull-raw --verify=no http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/22/Cloud/Images/x86_64/Fedora-Cloud-Base-22_Beta-20150415-x86_64.raw.xz $ tar # systemd-nspawn -M Fedora-Cloud-Base-22_Beta-20150415.x86_64.raw Spawning container Fedora-Cloud-Base-22_Beta-20150415.x86_64.raw on /var/lib/machines/Fedora-Cloud-Base-22_Beta-20150415.x86_64.raw. Press ^] three times within 1s to kill container. [root@Fedora-Cloud-Base-22_Beta-20150415 ~]# 4- install Fedora on /var/lib/machines/enl -- [root@Fedora-Cloud-Base-22_Beta-20150415 ~]# dnf -y --releasever=22 --nogpg --installroot=/var/lib/machines/MyContainer --disablerepo='*' --enablerepo=fedora install systemd passwd dnf fedora-release-server vim-minimal .. INSTALL ... Complete! -- Hmm? With this command you installed another fedora inside the raw fedora image you downloaded. You now have three linuxes, installed within each other... Pick one: a) download the raw image and use that, but it will be a loopback file with its own file system inside or: b) do the dnf/yum install root thing, and install it into a directory tree. Do either of those in the host, not in the container. 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] 628c89cc (tentative devices) + disk/by-label udev rule
On Thu, 23.04.15 13:20, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: It is not uncommon that file systems have the same volume label, especially on flash drives. disk/by-label udev rule in 60-persistent-storage.rules generates a symb link to the device. 2 devices might have the same label link if they have same label. After 628c89cc, this becomes very visible with Device dev-disk-by\x2dlabel-Axis.device appeared twice with different sysfs paths error message. I have now downgraded the message in git to debug. Which should basically get us back to the status quo ante in this regard. The LABEL field of the volumes are relatively short (11 char on vfat, 16 on ext4). It won't be unique. How can we solve it? What is the purpose of the disk/by-label rule? Who uses that device node? Well, it's unsolvable. THe names are not unique. But we probably shouldn't make a big fuss about it, hence I downgraded the message now. 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] install Fedora systemd-nspawn container on btrfs
On Thu, Apr 23, 2015 at 2:50 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.04.15 13:45, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: Not sure what I did wrong, but I can't install/boot my nspawn container. Here is my setup: Archlinux box- updated 1- created 3 btrfs subvol on /dev/sdb1 (SSD). The goal is to manage snapshots easily. no nested subvol. -- # btrfs subvolume list . ID 266 gen 39 top level 5 path rootvol ID 268 gen 41 top level 5 path var ID 269 gen 42 top level 5 path etc # btrfs filesystem show Label: 'poppy-root' uuid: ef1b44cd-e7b0-4166-b933-e7d4d20a1171 Total devices 1 FS bytes used 64.00KiB devid1 size 80.00GiB used 12.00MiB path /dev/sdb1 -- 2 - mount btrfs subvol --- # mount -t btrfs -o subvol=rootvol /dev/sdb1 /var/lib/machines/enl # mkdir /var/lib/machines/enl/var # mkdir /var/lib/machines/enl/etc # mount -t btrfs -o subvol=etc /dev/sdb1 /var/lib/machines/enl/etc # mount -t btrfs -o subvol=var /dev/sdb1 /var/lib/machines/enl/var THis isn't really how one would normally use subvolumes. No need to mount each subvolume explicitly, they are just special directories... As long as you never clone parent volume (but why use btrfs then?) As soon as you create clone or snapshot of parent volume, all childs will be out of place in it unless you explicitly mount them in correct place in hierarchy. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
