Re: [systemd-devel] no tar balls at release time
Kay Sievers [2015-06-23 1:21 +0200]: > Please test these setups locally if that model will work in your > setups, and what would possibly need to be fixed in the git tree to > make that easier for you. Fine for Debian/Ubuntu. We've always rebuilt the autoconfiscation anyway, and our build system also handles package builds straight from a git checkout (for CI). Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Confusing error message
$ systemctl restart systemd-networkd Failed to restart systemd-networkd.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files $ sudo systemctl restart systemd-networkd Works. Presumably this error message could be improved, in particular because that name is indeed not provided by any .service files :-) Cheers, Johannes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no tar balls at release time
On Mon, Jun 22, 2015 at 10:21 PM, Mike Gilbert wrote: > On Mon, Jun 22, 2015 at 7:30 PM, Lennart Poettering > wrote: >> On Tue, 23.06.15 01:21, Kay Sievers (k...@vrfy.org) wrote: >> >>> We currently considering to stop creating release tar balls. >>> >>> For build systems which still require them, they can be created >>> locally from the upstream git repository with: >>> git archive --format=tar --prefix=systemd-$(VERSION)/ $(VERSION) | \ >>> xz > systemd-$(VERSION).tar.xz >>> >>> These tar balls will not include the "500k of shell scripts" added by >>> autotools. These files need to be added to the extracted tarball by >>> running ./autogen.sh. >>> >>> These tar balls will also not include any generated content like >>> fonts, man, html pages. This is intentional. >> >> Which of course means the build tools for all of these need to be >> around on the build machines, as *everything* will be rebuilt from >> scratch now. Specifically you need >> autoconf/automake/python/perl/m4/xsltproc/... on every build machine. >> >> Hence the question to ask is: is anyone downstream relying on the >> pre-built stuff, and has a very good reason why he couldn't just >> install the build tools on his build machine and build things with >> that? > > On Gentoo, most users build from source, so this means additional > dependencies on most users' systems. We would appreciate having the > autotools-generated tarballs, but we can certainly live without them. > > FYI, having to run autoreconf introduces the following dependencies for us: > > app-text/docbook-xml-dtd:4.2 > app-text/docbook-xml-dtd:4.5 > app-text/docbook-xsl-stylesheets > dev-libs/libxslt:0 > >=dev-libs/libgcrypt-1.4.5:0" Plus autoconf/automake/libtools, etc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no tar balls at release time
On Mon, Jun 22, 2015 at 7:30 PM, Lennart Poettering wrote: > On Tue, 23.06.15 01:21, Kay Sievers (k...@vrfy.org) wrote: > >> We currently considering to stop creating release tar balls. >> >> For build systems which still require them, they can be created >> locally from the upstream git repository with: >> git archive --format=tar --prefix=systemd-$(VERSION)/ $(VERSION) | \ >> xz > systemd-$(VERSION).tar.xz >> >> These tar balls will not include the "500k of shell scripts" added by >> autotools. These files need to be added to the extracted tarball by >> running ./autogen.sh. >> >> These tar balls will also not include any generated content like >> fonts, man, html pages. This is intentional. > > Which of course means the build tools for all of these need to be > around on the build machines, as *everything* will be rebuilt from > scratch now. Specifically you need > autoconf/automake/python/perl/m4/xsltproc/... on every build machine. > > Hence the question to ask is: is anyone downstream relying on the > pre-built stuff, and has a very good reason why he couldn't just > install the build tools on his build machine and build things with > that? On Gentoo, most users build from source, so this means additional dependencies on most users' systems. We would appreciate having the autotools-generated tarballs, but we can certainly live without them. FYI, having to run autoreconf introduces the following dependencies for us: app-text/docbook-xml-dtd:4.2 app-text/docbook-xml-dtd:4.5 app-text/docbook-xsl-stylesheets dev-libs/libxslt:0 >=dev-libs/libgcrypt-1.4.5:0" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no tar balls at release time
On Tue, Jun 23, 2015 at 01:21:36AM +0200, Kay Sievers wrote: > We currently considering to stop creating release tar balls. What's the motivation for this change? I suspect that with this, 'make distcheck' will never again be run and it will eventually break build configurations which don't align with what the CI tests. > For build systems which still require them, they can be created > locally from the upstream git repository with: > git archive --format=tar --prefix=systemd-$(VERSION)/ $(VERSION) | \ > xz > systemd-$(VERSION).tar.xz > > These tar balls will not include the "500k of shell scripts" added by > autotools. These files need to be added to the extracted tarball by > running ./autogen.sh. > > These tar balls will also not include any generated content like > fonts, man, html pages. This is intentional. > > Please test these setups locally if that model will work in your > setups, and what would possibly need to be fixed in the git tree to > make that easier for you. Arch switched over to the git repo directly when it was discovered that the v220 tarball wasn't useful. We didn't bother going back to the tarballs with v221, either. Seems fine. dR ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no tar balls at release time
On Tue, 23.06.15 01:21, Kay Sievers (k...@vrfy.org) wrote: > We currently considering to stop creating release tar balls. > > For build systems which still require them, they can be created > locally from the upstream git repository with: > git archive --format=tar --prefix=systemd-$(VERSION)/ $(VERSION) | \ > xz > systemd-$(VERSION).tar.xz > > These tar balls will not include the "500k of shell scripts" added by > autotools. These files need to be added to the extracted tarball by > running ./autogen.sh. > > These tar balls will also not include any generated content like > fonts, man, html pages. This is intentional. Which of course means the build tools for all of these need to be around on the build machines, as *everything* will be rebuilt from scratch now. Specifically you need autoconf/automake/python/perl/m4/xsltproc/... on every build machine. Hence the question to ask is: is anyone downstream relying on the pre-built stuff, and has a very good reason why he couldn't just install the build tools on his build machine and build things with that? Are there any other reasons why the automake tarball would be preferable over the git archive tarball? Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] no tar balls at release time
We currently considering to stop creating release tar balls. For build systems which still require them, they can be created locally from the upstream git repository with: git archive --format=tar --prefix=systemd-$(VERSION)/ $(VERSION) | \ xz > systemd-$(VERSION).tar.xz These tar balls will not include the "500k of shell scripts" added by autotools. These files need to be added to the extracted tarball by running ./autogen.sh. These tar balls will also not include any generated content like fonts, man, html pages. This is intentional. Please test these setups locally if that model will work in your setups, and what would possibly need to be fixed in the git tree to make that easier for you. The Fedora build setup was happy without any adjustments to take the git created tar ball instead of the autotools created one. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] machinectl clone -- access denied
I can import-tar, list-images, image-status, start, rename, and remove, but
> sudo machinectl clone depot depot2
Could not clone image: Access denied
Am I doing this wrong?
This is systemd 221-1 on Arch.
$ sudo machinectl list-images
NAME TYPE RO USAGE CREATED MODIFIED
depot subvolume no 888.2M Mon 2015-06-22 23:02:38 UTC n/a
1 images listed.
$ sudo machinectl show-image depot
Name=depot
Path=/var/lib/machines/depot
Type=subvolume
ReadOnly=no
CreationTimestamp=Mon 2015-06-22 23:02:38 UTC
Usage=937963520
Limit=18446744073709551615
UsageExclusive=937963520
LimitExclusive=18446744073709551615
[root@localhost]# strace machinectl clone depot depot2
execve("/usr/bin/machinectl", ["machinectl", "clone", "depot", "depot2"], [/*
19 vars */]) = 0
brk(0) = 0x7f274af0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=113959, ...}) = 0
mmap(NULL, 113959, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f274a264000
close(3)= 0
open("/usr/lib/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220!\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=31672, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f274a263000
mmap(NULL, 2128856, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f2749e57000
mprotect(0x7f2749e5e000, 2093056, PROT_NONE) = 0
mmap(0x7f274a05d000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f274a05d000
close(3)= 0
open("/usr/lib/liblzma.so.5", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2001\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=154288, ...}) = 0
mmap(NULL, 2249360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f2749c31000
mprotect(0x7f2749c56000, 2093056, PROT_NONE) = 0
mmap(0x7f2749e55000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24000) = 0x7f2749e55000
close(3)= 0
open("/usr/lib/liblz4.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300$\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=71968, ...}) = 0
mmap(NULL, 2167144, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f2749a1f000
mprotect(0x7f2749a3, 2093056, PROT_NONE) = 0
mmap(0x7f2749c2f000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x7f2749c2f000
close(3)= 0
open("/usr/lib/libgcrypt.so.20", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\221\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=919976, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f274a262000
mmap(NULL, 3016352, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f274973e000
mprotect(0x7f2749815000, 2097152, PROT_NONE) = 0
mmap(0x7f2749a15000, 40960, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd7000) = 0x7f2749a15000
close(3)= 0
open("/usr/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320`\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=142832, ...}) = 0
mmap(NULL, 2213040, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f2749521000
mprotect(0x7f2749539000, 2093056, PROT_NONE) = 0
mmap(0x7f2749738000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f2749738000
mmap(0x7f274973a000, 13488, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f274973a000
close(3)= 0
open("/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\10\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1979984, ...}) = 0
mmap(NULL, 3807760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f274917f000
mprotect(0x7f2749318000, 2093056, PROT_NONE) = 0
mmap(0x7f2749517000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x198000) = 0x7f2749517000
mmap(0x7f274951d000, 14864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f274951d000
close(3)= 0
open("/usr/lib/libgpg-error.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20)\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=76320, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f274a261000
mmap(NULL, 2171480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x7f2748f6c000
mprotect(0x7f2748f7e000, 2093056, P
Re: [systemd-devel] filtering journal logs
On Mon, 22.06.15 23:16, Michał Zegan (webczat_...@poczta.onet.pl) wrote: > Are audit messages in _TRANSPORT=audit in systemd 219, or later only? Since day #1 of the native audit support they are _TRANSPORT=audit, hence also in v219. Note thought that the kernel also copies audit msgs to kmsg -- if you have no auditd running. Those messages are considered kmsg messages, and cannot sanely be detected. The kernel really needs to be fixed to not dump audit msgs to kmsg anymore if userspace is listening via multicast audit, the way journald does 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] [ANNOUNCE] systemd v221
Kay Sievers wrote on 20/06/15 20:49: > On Sat, Jun 20, 2015 at 6:08 PM, cee1 wrote: >> 2015-06-20 2:06 GMT+08:00 Lennart Poettering : >>> On Fri, 19.06.15 16:06, Lennart Poettering (lenn...@poettering.net) wrote: >>> Heya! It's primarily a bugfix release, but we also make sd-bus.h and sd-event.h public. (A blog story on sd-bus and how to use it will follow shortly.) >>> >>> The blog story is online now: >>> >>> http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html >>> >>> Enjoy, >> Glad to see this :) >> >> BTW, what about libabc? Would libsystemd be part of libabc? Also >> libsystemd is a linux-specific library, will it further ports and >> integrates some kernel libraries to libabc?? > > Assuming you mean this: > https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git > > Libabac is an example stub that does absolutely nothing, and in the > future it will keep doing nothing. Excellent. I'd hate to see a libabc API breakage ;) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] filtering journal logs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Are audit messages in _TRANSPORT=audit in systemd 219, or later only? W dniu 2015-06-22 o 23:07, Lennart Poettering pisze: > On Sat, 20.06.15 00:57, Michał Zegan (webczat_...@poczta.onet.pl) > wrote: > >> Hello. >> >> I am curious if it is possible or planned to add support for >> pattern matching and/or negation matching in journal? for example >> I would like to view everything except audit entries. Actually, >> when we are at it, are audit entries actually distinguished now, >> or not? > > Yes, audit messages have _TRANSPORT=audit set. > > There's currently no "negative" field matching, but we should add > it, and it's on the TODO list for a while. It's not trivial to do > nicely unfortunately, since the data structures are designed to > find things effectively, but not skip things effectively... But > certainly doable. > > Lennart > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJViHsQAAoJEHb1CzgxXKwYTy4P/2zshMvx+fGgpXo/kwnQnA8W EQhDl/W5j08+BNJ1NEsGhEyYNYYqR8h7aP7BRpNiz5PJ3ESUwfK09yy82NCD9WPX 4Ri/TU282vVg/v+HpPUBHbAZ09Bw4nXGYU+9jGfY9kUnC44dTHfzjEFbRbJzK80Q rl26PKF7+Qq60qN3en52/mNSC/lVLGhuilklMQ2hEtlsAyD8VQUKeRdjzoP+izM8 nF1tl7M6cQwqQxBCKm7FR643k4GWzrIDWLtptjP43rysTwnunmN9dXuJnV0Tg4Jm jqFHUQUkAPuQYG3Csv4d7WGuu8Esrn+C6oYVlsdonw1dvQo9lgyGhzYT+KNMWKFH HSie7XjLvftq7xNSYDYnXNGZDCVRUMez6Ut8yeJwGe+9jeQyY1m/h8ajNdzRT3wy Em6PbUrpdoo3tAt9/AKAiPLudKu/CQbqjC41JJWuTAZV0CJ5Vw3qqMlWXbgmrKNa fKLbOwBoTQ8Q0as2iasl+F4UpCRrq8TIzALQOK5x668qmxNWytiO6Rua5FVsSb8M oDC3rcKwWcHB4qI6i0kx1leUmcClSIybhM9XydQVT3xJch3/YE0J6wqccj3F/ytp H+5LOoF++OseGVGoEiT1H5iCkAx8gaXEYrMB2xw6zmkcQ/SmRQP5bfUqPmyU8mnm VIqdx87j1x3VLJXzCzzy =dfuB -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] remote-fs dependency/ordering on network
On Mon, 22.06.15 14:49, Jan Synacek (jsyna...@redhat.com) wrote: > Lukáš Nykrýn writes: > > > Jan Synáček píše v Čt 18. 06. 2015 v 15:41 +0200: > >> Is remote-fs.target somehow dependent/ordered on network.target or > >> network-online.target? I can't find anything that would suggest it > >> actually is. > >> > >> Cheers, > > > > If I am not mistaken remote-fs.target should be after all netdev mounts > > and netdev mounts should be after network-online.target. > > I'm sure it should, but I don't see any evidence that it really is. My > mnt-nfs.mount that was generated by the fstab generator is ordered > before remote-fs.target, which is correct. However, I can't find any > dependency between remote-fs.target, and network*. I'm quite puzzled how > NFS mounts mounted on boot can actually work correctly right now. There's also remote-fs-pre.target. That's ordered before all NFS mounts, and that's what the online stuff should be ordered before. 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] filtering journal logs
On Sat, 20.06.15 00:57, Michał Zegan (webczat_...@poczta.onet.pl) wrote: > Hello. > > I am curious if it is possible or planned to add support for pattern > matching and/or negation matching in journal? for example I would like > to view everything except audit entries. > Actually, when we are at it, are audit entries actually distinguished > now, or not? Yes, audit messages have _TRANSPORT=audit set. There's currently no "negative" field matching, but we should add it, and it's on the TODO list for a while. It's not trivial to do nicely unfortunately, since the data structures are designed to find things effectively, but not skip things effectively... But certainly doable. 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] Bind key combination to isolate emergency mode
On Sat, 20.06.15 17:35, Thomas Meyer (tho...@m3y3r.de) wrote: > > Also don't forget the magic SysRq keys – Alt+SysRq+F will run the OOM > > killer in case of heavy swapping, Alt+SysRq+E/I will sigterm/sigkill > > all programs (systemd will restart gettys afterwards), and > > Alt+SysRq+N will renice high-priority processes. You need to enable > > this via sysctl.conf though. > > Hi Mantas, > > thanks for the hint. I will try this. > I remember that SysRq was once always enabled? It now seems to be > disabled in current Fedora releases. I think enabling F key should be > default. At least it shouldn't be possbile to do something bad with it, > or is it? well, it's an authenticated way to execute quite a few operations that are potentially risky, hence it's disabled by default. Executing potentially risky operations is fine, but only after auth. 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] hostname and dnsdomainname
On Sat, 20.06.15 10:18, Kevin Wilson (wkev...@gmail.com) wrote: > Hi, > > I can set a hostname with > hostnamectl set-hostname --static newHostname > > I have a DNS domain server in my local LAN. so > > when I restart the machine, it gets this full hostname, which can be > displayed by > > > hostname -f > newHostname.mydomanName > > and hostname alone shows > newHostname > > > Is there some way (for example, restarting some service) by which I > can be assigned > the domain name without performing a full reboot ? I am not sure I understand the question. The FQDN that "hostname -f" returns is usually determined at runtime by asking getaddrinfo() for the canonical name of the system hostname. This will usually have the effect that the configured search domains are in turn appended and checked if the hostname exists there. and then the suffixed name is returned. Or in other words: the fqdn is usually not configured locally explicitly, but via the search domain logic in conjunction with your DNS server. 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] machinectl start vs. systemctl enable systemd-nspawn@...
On Mon, 22.06.15 10:36, Johannes Ernst (johannes.er...@gmail.com) wrote: > What’s the difference between > machinectl start foo > and > systemctl start systemd-nspawn@foo > ? They look the same to me. They are pretty much, as the man page even says. It's a bit nicer to user "machinectl start foo" though, since if foo contains weird chars, machinectl will apply the right escaping for you, which is particularly useful when you container names contain dashes. Also, machinectl start has its own PolicyKit action, which means you can grant that to specific users without having to grant them the right to start any kind of service. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] machinectl start vs. systemctl enable systemd-nspawn@...
What’s the difference between machinectl start foo and systemctl start systemd-nspawn@foo ? They look the same to me. Thanks, Johannes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] remote-fs dependency/ordering on network
Lukáš Nykrýn writes: > Jan Synáček píše v Čt 18. 06. 2015 v 15:41 +0200: >> Is remote-fs.target somehow dependent/ordered on network.target or >> network-online.target? I can't find anything that would suggest it >> actually is. >> >> Cheers, > > If I am not mistaken remote-fs.target should be after all netdev mounts > and netdev mounts should be after network-online.target. I'm sure it should, but I don't see any evidence that it really is. My mnt-nfs.mount that was generated by the fstab generator is ordered before remote-fs.target, which is correct. However, I can't find any dependency between remote-fs.target, and network*. I'm quite puzzled how NFS mounts mounted on boot can actually work correctly right now. -- Jan Synacek Software Engineer, Red Hat signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
