Re: [systemd-devel] [PATCH] Add AppArmor profile switching
Le vendredi 21 février 2014 à 03:48 +0100, Lennart Poettering a écrit : On Thu, 20.02.14 16:19, m...@zarb.org (m...@zarb.org) wrote: From: Michael Scherer m...@zarb.org This permit to switch to a specific apparmor profile when starting a daemon. This will result in a non operation if apparmor is disabled. It also add a new build requirement on libapparmor for using this feature. Applied! I made some changes though, there were some missing bits to make sure the config hookup works correctly. I don't have any apparmor available though. Could you check if everything works correctly? I will, I do have a opensuse VM for that, and I think intrigeri in CC, likely does too. I figure the only missing bit to get apparmor up to the same level of support in systemd as SELinux, SMACK and IMA have would be policy uploading during early boot. Yeah, but this requires call to a external binary, I was wondering is using some unit wouldn't be enough. Upstart also do provides a way to load a policy specificied in a job, which is maye something we could support, like on demand module loading for selinux . What do people think about it ? ( for on demand loading of profile/module ) -- Michael Scherer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd on by default?
Am 21.02.2014 04:41, schrieb Zbigniew Jędrzejewski-Szmek: On Fri, Feb 21, 2014 at 04:00:10AM +0100, Jason A. Donenfeld wrote: systemd-networkd seems to get started by default in 209. Why is this? What if I don't want to use it to manage my networks? Why does it have to be on by default? I think the reasoning was that it doesn't do anything by default (when there are no configuration files) that is a bad reasoning not a single process should be running if it has no job to do for the sake of ressource usage, security and clean systems signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add AppArmor profile switching
Hi, Michael Scherer wrote (21 Feb 2014 08:39:12 GMT) : Le vendredi 21 février 2014 à 03:48 +0100, Lennart Poettering a écrit : I don't have any apparmor available though. Could you check if everything works correctly? I will, I do have a opensuse VM for that, and I think intrigeri in CC, likely does too. I'll happily test this (in our upcoming Tor unit file) as soon as we have a version of systemd in Debian, that this patchset cleanly applies to. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [arch-dev-public] systemd 209 in [testing]
Am 20.02.2014 17:33, schrieb Dave Reisner: Hi all, I'm working on packaging the systemd 209 release, and I expect to have pkgrel=1 into [testing] in a few hours, barring any unforseen problems. It's a huge release (nearly 2000 commits since 208), and I don't anticipate that this will make it into [core]. This version works fine on my desktop, but fails on my laptop. The initramfs works fine. While booting up the system, systemd hangs and this appears in the journal: systemd[1]: Assertion '(x-type == SOURCE_MONOTONIC y-type == SOURCE_MONOTONIC) || (x-type == SOURCE_REALTIME y-type == SOURCE_REALTIME)' failed at src/libsystemd/sd-event/sd-event.c:264, function latest_time_prioq_compare(). Aborting. systemd[1]: Caught ABRT, dumped core as pid 317. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd on by default?
I agree with Harald. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sd-event: Fix systemd crash when using timer units.
There was a copy-paste error introduced in commit
c2ba3ad6604ef2e189d7e0a36d696e84d3ab
which causes the following error when using timer units:
Assertion '(x-type == SOURCE_MONOTONIC y-type == SOURCE_MONOTONIC) ||
(x-type == SOURCE_REALTIME y-type == SOURCE_REALTIME)'
failed at src/libsystemd/sd-event/sd-event.c:264, function
latest_time_prioq_compare(). Aborting.
---
I did cannot test this at the moment, but the problem looks very obvious to me.
src/libsystemd/sd-event/sd-event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd/sd-event/sd-event.c
b/src/libsystemd/sd-event/sd-event.c
index 25dfd17..1f039bc 100644
--- a/src/libsystemd/sd-event/sd-event.c
+++ b/src/libsystemd/sd-event/sd-event.c
@@ -771,7 +771,7 @@ _public_ int sd_event_add_realtime(sd_event *e,
sd_event_time_handler_t callback,
void *userdata) {
-return event_add_time_internal(e, ret, SOURCE_REALTIME,
e-realtime_fd, CLOCK_REALTIME, e-realtime_earliest, e-monotonic_latest,
usec, accuracy, callback, userdata);
+return event_add_time_internal(e, ret, SOURCE_REALTIME,
e-realtime_fd, CLOCK_REALTIME, e-realtime_earliest, e-realtime_latest,
usec, accuracy, callback, userdata);
}
static int event_update_signal_fd(sd_event *e) {
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] analyze/run: Use bus_open_transport_systemd instead of bus_open_transport.
Both systemd-analyze and systemd-run only access org.freedesktop.systemd1
on the bus. This patch allows using systemd-run --user and systemd-analyze
--user even if the user session's bus is not properly integrated with the
systemd user unit.
---
src/analyze/analyze.c | 2 +-
src/run/run.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/analyze/analyze.c b/src/analyze/analyze.c
index 3d2d08f..37d8beb 100644
--- a/src/analyze/analyze.c
+++ b/src/analyze/analyze.c
@@ -1274,7 +1274,7 @@ int main(int argc, char *argv[]) {
if (r = 0)
goto finish;
-r = bus_open_transport(arg_transport, arg_host, arg_user, bus);
+r = bus_open_transport_systemd(arg_transport, arg_host, arg_user,
bus);
if (r 0) {
log_error(Failed to create bus connection: %s, strerror(-r));
goto finish;
diff --git a/src/run/run.c b/src/run/run.c
index 885d881..134cb66 100644
--- a/src/run/run.c
+++ b/src/run/run.c
@@ -490,7 +490,7 @@ int main(int argc, char* argv[]) {
arg_description = description;
}
-r = bus_open_transport(arg_transport, arg_host, arg_user, bus);
+r = bus_open_transport_systemd(arg_transport, arg_host, arg_user,
bus);
if (r 0) {
log_error(Failed to create bus connection: %s, strerror(-r));
goto finish;
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-dhcp-client: prevent timer related memory leaks
On 21 Feb 2014 03:22, Lennart Poettering lenn...@poettering.net wrote: On Thu, 20.02.14 21:04, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: Tom commited this. Thanks! Tom, please always do a quick reply on the ML so that it is easy to see what is commited and what is not! Sorry about that. It seems my reply only went to Umut and not the ML... Thanks! --- src/libsystemd-dhcp/sd-dhcp-client.c |4 1 file changed, 4 insertions(+) diff --git a/src/libsystemd-dhcp/sd-dhcp-client.c b/src/libsystemd-dhcp/sd-dhcp-client.c index ec2b53f..53abe22 100644 --- a/src/libsystemd-dhcp/sd-dhcp-client.c +++ b/src/libsystemd-dhcp/sd-dhcp-client.c @@ -392,6 +392,8 @@ static int client_timeout_resend(sd_event_source *s, uint64_t usec, next_timeout += (random_u32() 0x1f); +client-timeout_resend = sd_event_source_unref(client-timeout_resend); + r = sd_event_add_monotonic(client-event, client-timeout_resend, next_timeout, @@ -477,6 +479,8 @@ static int client_initialize_events(sd_dhcp_client *client, if (r 0) goto error; +client-timeout_resend = sd_event_source_unref(client-timeout_resend); + r = sd_event_add_monotonic(client-event, client-timeout_resend, usec, 0, Lennart -- Lennart Poettering, Red Hat ___ 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] install: Do not enable systemd-networkd by default
On Fri, 21.02.14 04:38, Jason A. Donenfeld (ja...@zx2c4.com) wrote: systemd-network.service should not be started unless the administrator runs systemctl enable systemd-network.service, as it's entirely unessential and most distributions use their own network management daemons instead. If some distributions or users choose to use systemd's built in networking, then it is simple enough to enable. But by default, it doesn't make sense to waste resources running this when no networks are configured with it. I'd propose to make it compile-time optional (logind is too). And I'd move it to be installed via [Install] instead of a static symlink in /usr. However, I'd still create the /etc symlink on make install; the same way as we enable remote-fs.target or suchlike. Tom? 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] Add setns() functions if not in the C library.
On Fri, 21.02.14 08:28, Holger Schurig (holgerschu...@gmail.com) wrote: Compilation works okay here. And make check said PASS: test-namespace. The change I made is to complain if __NR_setns is not defined. The approach with an error message (at runtime) was taken from iproute2. I used that because for many (desktop) users namespace support isn't really needed. So if the libc would really not provide it, ... who cares. Then just the namespace related units wouldn't work, and they are not central to system bringup. The behaviour is not too different now, it's now just the kernel that returns ENOSYS, not userspace. Since setns() has been added in kernel 3.0 (which is the minimum kernel we require) it sounds sensible to simply define the syscall number I didn't knew the syscall numbers differs between architectures. It never occured to me that this could be a sane design :-) It's entirely moronic. It gets even worse when you notice the x86 madness that is socketcall(), where they decided to multiplex all socket system calls through a single meta-syscall, just because. 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] Add AppArmor profile switching
On Fri, 21.02.14 09:39, Michael Scherer (m...@zarb.org) wrote: Applied! I made some changes though, there were some missing bits to make sure the config hookup works correctly. I don't have any apparmor available though. Could you check if everything works correctly? I will, I do have a opensuse VM for that, and I think intrigeri in CC, likely does too. I figure the only missing bit to get apparmor up to the same level of support in systemd as SELinux, SMACK and IMA have would be policy uploading during early boot. Yeah, but this requires call to a external binary, I was wondering is using some unit wouldn't be enough. Upstart also do provides a way to Well, MAC policies sound like something one really should upload at a time where no process but PID 1 is around, so that it is guaranteed to apply to every process on the system. Uploading it in a normal unit loads it releatively late and in parallel to other servics. I am happy to add code that uploads the AppArmor policy the same way we upload SELinux, IMA, SMACK, but either this uploading must be so simple that we can easily implement this in our own code (which is the way we went for IMA or SMACK), or they must provide us with some library, but doing this via invoking a binary is something that I don't want to see in systemd upstream. load a policy specificied in a job, which is maye something we could What is different from what we have now with AppArmorProfile=? support, like on demand module loading for selinux . Hmm, on-demand module loading for selinux? What do you mean by that? 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] install: Do not enable systemd-networkd by default
On Fri, Feb 21, 2014 at 1:53 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 21.02.14 04:38, Jason A. Donenfeld (ja...@zx2c4.com) wrote: systemd-network.service should not be started unless the administrator runs systemctl enable systemd-network.service, as it's entirely unessential and most distributions use their own network management daemons instead. If some distributions or users choose to use systemd's built in networking, then it is simple enough to enable. But by default, it doesn't make sense to waste resources running this when no networks are configured with it. I'd propose to make it compile-time optional (logind is too). And I'd move it to be installed via [Install] instead of a static symlink in /usr. However, I'd still create the /etc symlink on make install; the same way as we enable remote-fs.target or suchlike. Tom? Sounds fine to me. It is already compile-time optional, so I'll just apply this patch and add the /etc symlink in a follow-up. Thanks for the patch Jason. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sd-event: Fix systemd crash when using timer units.
On Fri, 21.02.14 11:20, Thomas Bächler (tho...@archlinux.org) wrote: There was a copy-paste error introduced in commit c2ba3ad6604ef2e189d7e0a36d696e84d3ab which causes the following error when using timer units: Assertion '(x-type == SOURCE_MONOTONIC y-type == SOURCE_MONOTONIC) || (x-type == SOURCE_REALTIME y-type == SOURCE_REALTIME)' failed at src/libsystemd/sd-event/sd-event.c:264, function latest_time_prioq_compare(). Aborting. Thanks! Applied! 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] Unmentioned 209 change: 80-net-name-slot.rules is gone
On Fri, Feb 21, 2014 at 3:29 AM, Jason A. Donenfeld ja...@zx2c4.com wrote: Hey guys, This commit caught me by surprise: http://git.zx2c4.com/systemd/commit/?id=daeb71a36a98834664e4d95773a3629b746f4db8 It wasn't in the NEWS or the mailing list post for 209, so when updating I encountered a bit of unexpected behavior. I see that I can disable persistent names using net.ifnames=0 in my kernel command line. Still not certain what the equivalent of the udev rule override is, though. Yeah, that should have been in the NEWS. Sorry about that. This is what we do in Arch to preserve the behavior form v208: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/systemd.install?h=packages/systemd#n65. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH WIP] shell-completion: Change zsh boot id completion
Previously we put the boot offset and boot ID into the completion, now
we use something similar to the coredumpctl completion, but only with
the boot offsets.
---
This is just something I'm working on, but would like some input. I'm fine
with it not having the boot ID's output, but that may be unacceptable.
shell-completion/zsh/_journalctl | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/shell-completion/zsh/_journalctl b/shell-completion/zsh/_journalctl
index 0d16a26..4467249 100644
--- a/shell-completion/zsh/_journalctl
+++ b/shell-completion/zsh/_journalctl
@@ -40,12 +40,9 @@ _journal_fields() {
}
_journal_boots() {
- local -a _bootid _previousboots
- _bootid=( ${(fao)$(_call_program bootid $service -F _BOOT_ID)} )
- _previousboots=( -{1..${#_bootid}} )
- _alternative : \
-offsets:boot offsets:(${_previousboots[1,-2]}) \
-bootid:boot ids:(${_bootid[@]})
+ local -a _bootoff
+ _bootoff=( ${(foa)$(journalctl --list-boots | awk 'BEGIN{OFS=:} {print
$1,$0}' 2/dev/null)} )
+ _describe -t pids 'boot offsets' _bootoff
}
_arguments -s \
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unmentioned 209 change: 80-net-name-slot.rules is gone
On Fri, Feb 21, 2014 at 02:24:58PM +0100, Tom Gundersen wrote: On Fri, Feb 21, 2014 at 3:29 AM, Jason A. Donenfeld ja...@zx2c4.com wrote: Hey guys, This commit caught me by surprise: http://git.zx2c4.com/systemd/commit/?id=daeb71a36a98834664e4d95773a3629b746f4db8 It wasn't in the NEWS or the mailing list post for 209, so when updating I encountered a bit of unexpected behavior. I see that I can disable persistent names using net.ifnames=0 in my kernel command line. Still not certain what the equivalent of the udev rule override is, though. Yeah, that should have been in the NEWS. Sorry about that. This is what we do in Arch to preserve the behavior form v208: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/systemd.install?h=packages/systemd#n65. It should still be added... Lots of people look at NEWS in the web git interface, or long after the release. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
On Fri, Feb 21, 2014 at 2:08 PM, Tom Gundersen t...@jklm.no wrote: I'll just apply this patch and add the /etc symlink in a follow-up. I appreciate merging my patch, so now administrators can disable it in a sane way (without having to use mask). But still, why enable it by default? I thought the idea of networkd was that it was an opt-in thing. For folks that want to use it, it's there. For folks who are already using something else that works, they don't need it. Enabling it by default seems a bit heavy handed: you shall now use system resources using our network manager, my default. Seems like until it's got a little more wide-spread adoption, a default symlink in etc is inappropriate. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] configure: show if networkd is enabled in status
---
configure.ac | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure.ac b/configure.ac
index 80c1449..8943c96 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1150,6 +1150,7 @@ AC_MSG_RESULT([
hostnamed: ${have_hostnamed}
timedated: ${have_timedated}
localed: ${have_localed}
+networkd:${have_networkd}
coredump:${have_coredump}
polkit: ${have_polkit}
efi: ${have_efi}
--
1.8.5.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [patch] Install 99-default.link to rootprefix instead of prefix (as required)
By passing --rootprefix= you can get systemd-udevd installed to /lib/systemd, as opposed to /usr/lib/systemd And by logic, network configuration is needed to accompany the daemon since /usr might not be mounted yet, the network configuration needs to go to same prefix with the systemd-udevd Currently we are overriding networkdir= at `make install` argument in Gentoo's package for udev, but obviously that is only a workaround. This patch fixes things. Other than this, I've had no issues with building, packaging, and running udev separately without systemd from the systemd tree. Keep up the great work! Thanks! - Samuli From 44180dccea7ea9dee2c40f012d6b0b3e558c0e0b Mon Sep 17 00:00:00 2001 From: Samuli Suominen ssuomi...@gentoo.org Date: Fri, 21 Feb 2014 16:14:51 +0200 Subject: [PATCH] With --rootprefix= systemd-udevd gets installed to /lib/systemd, and since the network configuration is also required during early boot, it should be available there with it. Using --prefix= is not an option since it would put everything, including pkg-config files, man pages, documentation, to / which is not wanted. This commit puts 99-default.link to /lib/systemd/network/ when required. --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index f6c22bd..1fc23f7 100644 --- a/Makefile.am +++ b/Makefile.am @@ -87,7 +87,7 @@ userunitdir=$(prefix)/lib/systemd/user userpresetdir=$(prefix)/lib/systemd/user-preset tmpfilesdir=$(prefix)/lib/tmpfiles.d sysctldir=$(prefix)/lib/sysctl.d -networkdir=$(prefix)/lib/systemd/network +networkdir=$(rootprefix)/lib/systemd/network pkgincludedir=$(includedir)/systemd systemgeneratordir=$(rootlibexecdir)/system-generators usergeneratordir=$(prefix)/lib/systemd/user-generators -- 1.8.5.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Revert install: enable networkd by default
This reverts commit ca1a3847695d02ebe62007d8f335f23d3fe04638. It's not right to install this by default. networkd is extremely new, has no real world miles, and most importantly, simply does-not-do-anything-at-all unless you write configuration files for it. So, for folks who want to use networkd, they'll write config files, which means they're also in a position to type systemctl enable systemd-networkd. It doesn't make any sense to enable this by default during install, since by default it doesn't serve any function. It's simply a waste of resources. It's also not very sensitive to the community at large to by default enable a brand new network management daemon. --- Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index f6c22bd..8099acd 100644 --- a/Makefile.am +++ b/Makefile.am @@ -4745,7 +4745,6 @@ USER_UNIT_ALIASES += \ GENERAL_ALIASES += \ $(systemunitdir)/remote-fs.target $(pkgsysconfdir)/system/multi-user.target.wants/remote-fs.target \ - $(systemunitdir)/systemd-networkd.service $(pkgsysconfdir)/system/multi-user.target.wants/systemd-networkd.service \ $(systemunitdir)/getty@.service $(pkgsysconfdir)/system/getty.target.wants/getty@tty1.service \ $(pkgsysconfdir)/user $(sysconfdir)/xdg/systemd/user \ ../system-services/org.freedesktop.systemd1.service $(dbussessionservicedir)/org.freedesktop.systemd1.service -- 1.8.5.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
On Fri, 21.02.14 15:03, Jason A. Donenfeld (ja...@zx2c4.com) wrote: On Fri, Feb 21, 2014 at 2:08 PM, Tom Gundersen t...@jklm.no wrote: I'll just apply this patch and add the /etc symlink in a follow-up. I appreciate merging my patch, so now administrators can disable it in a sane way (without having to use mask). But still, why enable it by default? I thought the idea of networkd was that it was an opt-in thing. For folks that want to use it, it's there. For folks who are already using something else that works, they don't need it. Enabling it by default seems a bit heavy handed: you shall now use system resources using our network manager, my default. Seems like until it's got a little more wide-spread adoption, a default symlink in etc is inappropriate. Well, ultimately it's up the distributions to decide what they want to enable and what not. What we enabled like this from upstream make install is simply what we thinkmakes a good choice if you build your own system. And yupp, I think networkd is a good choice, especially since it doesn't break anything without configs around. Moreover, we will probably start shipping some .network files by default to auto configure the veth tunnels of nspawn automatically. This is the kind of functionality that should just work and that is not available out-of-the-box with other managers, since they tend not to run in containers. Consider this a gentle push to leave the thing on, but ultimately it's the distro's choice what they want to do. 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] Add -lresolv to libudev LIBADD
On Fri, 21.02.14 15:54, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Fix problems with unresolved symbols when building on Ubuntu 12.04 x86_64. --8---cut here---start-8--- ./.libs/libudev.so: undefined reference to `__res_search' ./.libs/libudev.so: undefined reference to `__res_query' collect2: ld returned 1 exit status --8---cut here---end---8--- This doesn't look right. libudev really shouldn't need libresolv. We should figure out how these calls got pulled in... --- Makefile.am |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index f6c22bd..682266b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2416,7 +2416,8 @@ libudev_la_LDFLAGS = \ libudev_la_LIBADD = \ libsystemd-internal.la \ - libsystemd-shared.la + libsystemd-shared.la \ + -lresolv pkgconfiglib_DATA += \ src/libudev/libudev.pc 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] Install 99-default.link to rootprefix instead of prefix (as required)
On Fri, Feb 21, 2014 at 3:27 PM, Samuli Suominen ssuomi...@gentoo.org wrote: By passing --rootprefix= you can get systemd-udevd installed to /lib/systemd, as opposed to /usr/lib/systemd And by logic, network configuration is needed to accompany the daemon since /usr might not be mounted yet, the network configuration needs to go to same prefix with the systemd-udevd Currently we are overriding networkdir= at `make install` argument in Gentoo's package for udev, but obviously that is only a workaround. This patch fixes things. Other than this, I've had no issues with building, packaging, and running udev separately without systemd from the systemd tree. Keep up the great work! Thanks! Thanks Samuli! Applied (after reformatting the commit message a bit). -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
On Fri, Feb 21, 2014 at 4:19 PM, Lennart Poettering lenn...@poettering.net wrote: Well, ultimately it's up the distributions to decide what they want to enable and what not. True, but this requires manual patching and fixing up of `make install`, which is a bummer. I think networkd is a good choice, especially since it doesn't break anything without configs around. But it shouldn't even run when it doesn't have configs. It seems totally superfluous and wasteful to do so. Moreover, we will probably start shipping some .network files by default to auto configure the veth tunnels of nspawn automatically. Couldn't nspawn then run it, as needed? Seems wasteful to have this running all the time, especially because most people never even touch nspawn. This is the kind of functionality that should just work and that is not available out-of-the-box with other managers, since they tend not to run in containers. Having it not enabled by default doesn't destroy the out-of-box functionality, since configuration files need to be written anyway. An administrator will write this configs, and then type systemctl enable systemd-networkd. Otherwise, it doesn't need to be running. but ultimately it's the distro's choice what they want to do. complain downstream isn't a very nice thing to hear. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] install: networkd.service depend on !--disable
It doesn't make any sense to symlink this unit file into /etc when the unit file itself isn't even installed, with --disable-networkd. This moves the GENERAL_ALIASES logic into the right if block. --- Makefile.am | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 1fc23f7..88d0ce3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3955,6 +3955,9 @@ systemd_networkd_LDADD = \ nodist_systemunit_DATA += \ units/systemd-networkd.service +GENERAL_ALIASES += \ + $(systemunitdir)/systemd-networkd.service $(pkgsysconfdir)/system/multi-user.target.wants/systemd-networkd.service + test_network_SOURCES = \ src/network/test-network.c \ src/network/networkd.h \ @@ -4745,7 +4748,6 @@ USER_UNIT_ALIASES += \ GENERAL_ALIASES += \ $(systemunitdir)/remote-fs.target $(pkgsysconfdir)/system/multi-user.target.wants/remote-fs.target \ - $(systemunitdir)/systemd-networkd.service $(pkgsysconfdir)/system/multi-user.target.wants/systemd-networkd.service \ $(systemunitdir)/getty@.service $(pkgsysconfdir)/system/getty.target.wants/getty@tty1.service \ $(pkgsysconfdir)/user $(sysconfdir)/xdg/systemd/user \ ../system-services/org.freedesktop.systemd1.service $(dbussessionservicedir)/org.freedesktop.systemd1.service -- 1.8.5.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
2014-02-21 16:31 GMT+01:00 Jason A. Donenfeld ja...@zx2c4.com: On Fri, Feb 21, 2014 at 4:19 PM, Lennart Poettering lenn...@poettering.net wrote: Well, ultimately it's up the distributions to decide what they want to enable and what not. True, but this requires manual patching and fixing up of `make install`, which is a bummer. I think networkd is a good choice, especially since it doesn't break anything without configs around. But it shouldn't even run when it doesn't have configs. It seems totally superfluous and wasteful to do so. What about Zbigniews idea of using something like: ConditionDirectoryNotEmpty=/etc/systemd/network/ Would that work? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd on by default?
'Twas brillig, and Reindl Harald at 21/02/14 08:45 did gyre and gimble: Am 21.02.2014 04:41, schrieb Zbigniew Jędrzejewski-Szmek: On Fri, Feb 21, 2014 at 04:00:10AM +0100, Jason A. Donenfeld wrote: systemd-networkd seems to get started by default in 209. Why is this? What if I don't want to use it to manage my networks? Why does it have to be on by default? I think the reasoning was that it doesn't do anything by default (when there are no configuration files) that is a bad reasoning not a single process should be running if it has no job to do for the sake of ressource usage, security and clean systems Well I kinda get that using it for containers and such like could be useful, but I also suspect it should be bus or socket activated rather than statically enabled... like localed, datetimed etc. Any reason to enable it statically? (I guess it maybe has to do stuff by itself, but I would figure udev should kick it in via the setup link built in in most cases - but I guess that wouldn't work inside containers, so perhaps this is where things break down and you need it statically enabled). 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] systemd-networkd on by default?
Am 21.02.2014 16:44, schrieb Colin Guthrie: 'Twas brillig, and Reindl Harald at 21/02/14 08:45 did gyre and gimble: Am 21.02.2014 04:41, schrieb Zbigniew Jędrzejewski-Szmek: On Fri, Feb 21, 2014 at 04:00:10AM +0100, Jason A. Donenfeld wrote: systemd-networkd seems to get started by default in 209. Why is this? What if I don't want to use it to manage my networks? Why does it have to be on by default? I think the reasoning was that it doesn't do anything by default (when there are no configuration files) that is a bad reasoning not a single process should be running if it has no job to do for the sake of ressource usage, security and clean systems Well I kinda get that using it for containers and such like could be useful, but I also suspect it should be bus or socket activated rather than statically enabled... like localed, datetimed etc. Any reason to enable it statically? (I guess it maybe has to do stuff by itself, but I would figure udev should kick it in via the setup link built in in most cases - but I guess that wouldn't work inside containers, so perhaps this is where things break down and you need it statically enabled) statically enabled is bad in general, containers are not a good reason to enable something for everybody, many if not most people never will use containers for several reasons and if it because they use full-virtualization and move machines between different also non-linux hosts where i would support something new enabled by default is if could *replace* something else like LSB network.service while use it's ifcfg-configurations for backward compatibility and test out if it really can replace all cases if i can replace that below i start to be one of the first production users in a complexer setup (one is the MAC of the physical card, the other is what it becames before fetch the IP from the ISP because you need to register your MAC there, that's the same like MAC cloning in small soho-routers) DEVICE=eth1 HWADDR=68:05:ca:0d:62:c1 ONBOOT=yes BOOTPROTO=dhcp IPV6INIT=no NM_CONTROLLED=no USERCTL=no PEERDNS=no MACADDR=00:50:8d:b5:cc:de but something hanging around unconfigured please no signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: networkd.service depend on !--disable
On Fri, Feb 21, 2014 at 4:36 PM, Jason A. Donenfeld ja...@zx2c4.com wrote: It doesn't make any sense to symlink this unit file into /etc when the unit file itself isn't even installed, with --disable-networkd. This moves the GENERAL_ALIASES logic into the right if block. Applied. Thanks! Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add -lresolv to libudev LIBADD
It was 2014-02-21 pią 16:22, when Lennart Poettering wrote:
On Fri, 21.02.14 15:54, Łukasz Stelmach (l.stelm...@samsung.com) wrote:
Fix problems with unresolved symbols when building on Ubuntu 12.04 x86_64.
--8---cut here---start-8---
./.libs/libudev.so: undefined reference to `__res_search'
./.libs/libudev.so: undefined reference to `__res_query'
collect2: ld returned 1 exit status
--8---cut here---end---8---
This doesn't look right. libudev really shouldn't need libresolv. We
should figure out how these calls got pulled in...
Let me go step-by-step:
--8---cut here---start-8---
$ strings ./.libs/libudev.so | grep __res_'\(query\|search\)'
__res_query
__res_search
# libudev needs libsystemd-internal
$ strings ./.libs/libsystemd-internal.a | grep __res_'\(query\|search\)'
__res_query
__res_search
$ grep __res_query [list of objects used to build l-i.a]
Binary file src/libsystemd/sd-resolve/.libs/libsystemd_internal_la-sd-resolve.o
matches
$ rm -f src/libsystemd/sd-resolve/libsystemd_internal_la-sd-resolve.lo \
strace make src/libsystemd/sd-resolve/libsystemd_internal_la-sd-resolve.lo
$ grep __res_'\(query\|search\)' /usr/include/resolv.h
#define res_query __res_query
#define res_querydomain __res_querydomain
#define res_search __res_search
$ gcc -std=gnu99 [...]-E src/libsystemd/sd-resolve/sd-resolve.c -fPIC \
-DPIC | grep __res_'\(query\|search\)'
void __res_close (void) __attribute__ ((__nothrow__ , __leaf__));
int __res_init (void) __attribute__ ((__nothrow__ , __leaf__));
int __res_isourserver (const struct sockaddr_in *) __attribute__ ((__nothrow__
, __leaf__));
int __res_mkquery (int, const char *, int, int, const u_char *,
int, const u_char *, u_char *, int) __attribute__ ((__nothrow__ ,
__leaf__));
int __res_query (const char *, int, int, u_char *, int) __attribute__
((__nothrow__ , __leaf__));
int __res_querydomain (const char *, const char *, int, int,
u_char *, int) __attribute__ ((__nothrow__ , __leaf__));
int __res_search (const char *, int, int, u_char *, int) __attribute__
((__nothrow__ , __leaf__));
int __res_send (const u_char *, int, u_char *, int) __attribute__ ((__nothrow__
, __leaf__));
# 327 /usr/include/resolv.h 3 4
int __res_hnok (const char *) __attribute__ ((__nothrow__ , __leaf__));
--
do { if ((__builtin_expect(!!(!(length == sizeof(ResRequest) +
res_req-dname_len)),0))) log_assert_failed(length == sizeof(ResRequest) +
res_req-dname_len, src/libsystemd/sd-resolve/sd-resolve.c, 425,
__PRETTY_FUNCTION__); } while (0);
dname = (const char *) req + sizeof(ResRequest);
if (req-type == REQUEST_RES_QUERY)
ret = __res_query(dname, res_req-class,
res_req-type, (unsigned char *) answer, 10240);
else
ret = __res_search(dname, res_req-class,
res_req-type, (unsigned char *) answer, 10240);
return send_res_reply(out_fd, req-id, (unsigned char *)
answer, ret, (*__errno_location ()), (*__h_errno_location ()));
}
case REQUEST_TERMINATE:
--8---cut here---end---8---
There are defines in resolv.h which make res_query() and res_search() be
substituted with __res_.* versions. These does not look like Ubuntu
specific stuff[1].
[1]
https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/resolv.h;h=53c3bba182be49ba0a2372ffba7920c016029ecd;hb=HEAD#l262
--
Łukasz Stelmach
Samsung RD Institute Poland
Samsung Electronics
pgp3lwnDs_tBP.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
On Fri, Feb 21, 2014 at 4:44 PM, Michael Biebl mbi...@gmail.com wrote: 2014-02-21 16:31 GMT+01:00 Jason A. Donenfeld ja...@zx2c4.com: On Fri, Feb 21, 2014 at 4:19 PM, Lennart Poettering lenn...@poettering.net wrote: Well, ultimately it's up the distributions to decide what they want to enable and what not. True, but this requires manual patching and fixing up of `make install`, which is a bummer. I think networkd is a good choice, especially since it doesn't break anything without configs around. But it shouldn't even run when it doesn't have configs. It seems totally superfluous and wasteful to do so. What about Zbigniews idea of using something like: ConditionDirectoryNotEmpty=/etc/systemd/network/ Would that work? We'd have to look in all the possible folders, and there may (and due to 99-deafult.link, always will) be files there, so we don't really have a reasonable test. When we start shipping some default .network files it becomes even harder (e.g. the thing Lennart mentioned which will only apply for given interfaces that we create ourselves inside systemd-nspawn). We'll then always have config files, but they may not necessarily apply (and we can't know whether or not they ever will). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add -lresolv to libudev LIBADD
On Fri, Feb 21, 2014 at 4:58 PM, Łukasz Stelmach l.stelm...@samsung.com wrote: It was 2014-02-21 pią 16:22, when Lennart Poettering wrote: On Fri, 21.02.14 15:54, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Fix problems with unresolved symbols when building on Ubuntu 12.04 x86_64. --8---cut here---start-8--- ./.libs/libudev.so: undefined reference to `__res_search' ./.libs/libudev.so: undefined reference to `__res_query' collect2: ld returned 1 exit status --8---cut here---end---8--- This doesn't look right. libudev really shouldn't need libresolv. We should figure out how these calls got pulled in... Let me go step-by-step: --8---cut here---start-8--- $ strings ./.libs/libudev.so | grep __res_'\(query\|search\)' __res_query __res_search # libudev needs libsystemd-internal $ strings ./.libs/libsystemd-internal.a | grep __res_'\(query\|search\)' This does not seem to happen here. Are you sure that as-needed is working in your setup? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unmentioned 209 change: 80-net-name-slot.rules is gone
On 21/02/14 17:37, Colin Guthrie wrote: 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 21/02/14 13:58 did gyre and gimble: On Fri, Feb 21, 2014 at 02:24:58PM +0100, Tom Gundersen wrote: On Fri, Feb 21, 2014 at 3:29 AM, Jason A. Donenfeld ja...@zx2c4.com wrote: Hey guys, This commit caught me by surprise: http://git.zx2c4.com/systemd/commit/?id=daeb71a36a98834664e4d95773a3629b746f4db8 It wasn't in the NEWS or the mailing list post for 209, so when updating I encountered a bit of unexpected behavior. I see that I can disable persistent names using net.ifnames=0 in my kernel command line. Still not certain what the equivalent of the udev rule override is, though. Yeah, that should have been in the NEWS. Sorry about that. This is what we do in Arch to preserve the behavior form v208: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/systemd.install?h=packages/systemd#n65. It should still be added... Lots of people look at NEWS in the web git interface, or long after the release. I updated the wiki page: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames Col udev/rules.d/80-net-setup-link.rules is only a trigger for systemd/network/99-default.link.rules where the actual order of preference is recorded wouldn't it be better to override the actual configuration, where you can easily change the order of preference the interfaces get renamed to, than the dummy trigger? because the upstream wiki was updated to mention the .rules, then someone changed my instructions here: https://wiki.gentoo.org/index.php?title=Udev/upgradediff=110279oldid=110235 and that looks like an regression, rather than improvement, to me can we record the overriding of 99-default.link instead of 80-net-setup-link.rules, please? - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
On Fri, Feb 21, 2014 at 4:31 PM, Jason A. Donenfeld ja...@zx2c4.com wrote: On Fri, Feb 21, 2014 at 4:19 PM, Lennart Poettering lenn...@poettering.net wrote: Well, ultimately it's up the distributions to decide what they want to enable and what not. True, but this requires manual patching and fixing up of `make install`, which is a bummer. I think networkd is a good choice, especially since it doesn't break anything without configs around. But it shouldn't even run when it doesn't have configs. It seems totally superfluous and wasteful to do so. In the not-too-distant future we'll start shipping some configuration files (as Lennart mentioned to do with nspawn). These are files that in most cases will not apply, and shouldn't interfere with your existing networking solutions, but we want them to apply in the very special circumstances that we know are safe (in a nspawn container, on a device we create ourselves with a specific purpose). Moreover, we will probably start shipping some .network files by default to auto configure the veth tunnels of nspawn automatically. Couldn't nspawn then run it, as needed? Seems wasteful to have this running all the time, especially because most people never even touch nspawn. We want this (by default) to be a generally available service, so requiring each user of it (nspawn is obivously just the first example) to enable it feels wrong. We don't want to be wasteful though, so please file bugs if you are noticing any problems with resource usage... This is the kind of functionality that should just work and that is not available out-of-the-box with other managers, since they tend not to run in containers. Having it not enabled by default doesn't destroy the out-of-box functionality, since configuration files need to be written anyway. An administrator will write this configs, and then type systemctl enable systemd-networkd. Otherwise, it doesn't need to be running. As I mentioned above, we'll likely start shipping these files by default, so that they really work out-of-the-box. If you are experiencing any real technical, measurable problems, please let me know. Otherwise, I don't think there is anything to do here. Sorry about that. Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unmentioned 209 change: 80-net-name-slot.rules is gone
To clarify things: 1. Arch's script deals with 80-net-setup-link.rules 2. freedesktop.org wiki followed suit and added that suggestion 3. Others have said elsewhere that the proper way to do this is actually to override 99-default.link instead. 4. Gentoo went with number 3. Now: 5. Can numbers 1 and 2 update to the suggestion of 3? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
On Fri, Feb 21, 2014 at 5:10 PM, Jason A. Donenfeld ja...@zx2c4.com wrote: On Fri, Feb 21, 2014 at 5:03 PM, Tom Gundersen t...@jklm.no wrote: We'd have to look in all the possible folders, and there may (and due to 99-deafult.link, always will) be files there, so we don't really have a reasonable test. When we start shipping some default .network files it becomes even harder (e.g. the thing Lennart mentioned which will only apply for given interfaces that we create ourselves inside systemd-nspawn). We'll then always have config files, but they may not necessarily apply (and we can't know whether or not they ever will). It seems like the component in this equation that always does know whether or not it should be running is the system administrator who is taking the time to write config files for networkd, or not. And in the case that the sysadmin sits down to write config files, then undoubtedly he'll also 'systemctl enable systemd-networkd.service' it. In the case that he doesn't write config files, then of course it shouldn't be running by default. You probably sent this before reading my previous answer, so sorry for repeating myself: there will soon be cases where (special purpose) config files are shipped by packages rather than written by administrators, which is what we want to 'just work'. The admin and/or distribution is of course free to ignore our recommendation (as always). Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
On Fri, Feb 21, 2014 at 5:11 PM, Tom Gundersen t...@jklm.no wrote: In the not-too-distant future we'll start shipping some configuration files (as Lennart mentioned to do with nspawn). These are files that in most cases will not apply, and shouldn't interfere with your existing networking solutions, but we want them to apply in the very special circumstances that we know are safe (in a nspawn container, on a device we create ourselves with a specific purpose). But in the case of nspawn using it, then nspawn should start it. Otherwise if nobody is going to use nspawn, why start it? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
On Fri, 21.02.14 16:31, Jason A. Donenfeld (ja...@zx2c4.com) wrote: On Fri, Feb 21, 2014 at 4:19 PM, Lennart Poettering lenn...@poettering.net wrote: Well, ultimately it's up the distributions to decide what they want to enable and what not. True, but this requires manual patching and fixing up of `make install`, which is a bummer. Well, packaging is hard, let's go shopping. I think networkd is a good choice, especially since it doesn't break anything without configs around. But it shouldn't even run when it doesn't have configs. It seems totally superfluous and wasteful to do so. Well, it will have these configs as soon as we do the veth thing for containers. Moreover, we will probably start shipping some .network files by default to auto configure the veth tunnels of nspawn automatically. Couldn't nspawn then run it, as needed? Seems wasteful to have this running all the time, especially because most people never even touch nspawn. The idea is that we run the same image inside and outside of a container, unmodified. If people build systemd from scratch then they should just pass --disable-networkd. If they get it from distributions then the distributions should make a choice whether they either split it out into its own package, or whether they disable it by default but leave it in the default package, or whether they leave it enabled and ship it by default, or whether they do that but also add more default configuration to it. I fail to see who you are trying to make happy here: people who build from source with everything compile-time enabled but then want that stuff to be runtime-disabled by default? That sounds like a very weird combination to support out-of-the-box. If you compile it yourself turn it off completely, or turn it on completely, but the middle thing is really not for those people: it's for the distributions. 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] install: Do not enable systemd-networkd by default
On Fri, Feb 21, 2014 at 5:13 PM, Tom Gundersen t...@jklm.no wrote: You probably sent this before reading my previous answer, so sorry for repeating myself: there will soon be cases where (special purpose) config files are shipped by packages rather than written by administrators, which is what we want to 'just work'. Then those other packages and utilities should be responsible for starting systemd-networkd, either with a Requires/After, or via another API for starting it. But keeping it running when there's no use makes little sense. The whole idea of the dependency system is for situations like this one. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
On Fri, 21.02.14 17:14, Jason A. Donenfeld (ja...@zx2c4.com) wrote: On Fri, Feb 21, 2014 at 5:11 PM, Tom Gundersen t...@jklm.no wrote: In the not-too-distant future we'll start shipping some configuration files (as Lennart mentioned to do with nspawn). These are files that in most cases will not apply, and shouldn't interfere with your existing networking solutions, but we want them to apply in the very special circumstances that we know are safe (in a nspawn container, on a device we create ourselves with a specific purpose). But in the case of nspawn using it, then nspawn should start it. Otherwise if nobody is going to use nspawn, why start it? That'd be all backwards... nspawn is not going to reach into the container and start specific services there as it pleases. The code inside the container should figure out what it wants to run. 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] install: Do not enable systemd-networkd by default
Am 21.02.2014 17:03, schrieb Tom Gundersen: What about Zbigniews idea of using something like: ConditionDirectoryNotEmpty=/etc/systemd/network/ Would that work? We'd have to look in all the possible folders, and there may (and due to 99-deafult.link, always will) be files there, so we don't really have a reasonable test. When we start shipping some default .network files it becomes even harder (e.g. the thing Lennart mentioned which will only apply for given interfaces that we create ourselves inside systemd-nspawn). We'll then always have config files, but they may not necessarily apply (and we can't know whether or not they ever will). Just a crazy idea, but I'm still throwing it out here, since I think this may make people happy: * Start networkd from udev whenever a network interface appears/changes/disappears. * Networkd quits after a timeout if it has nothing to do + A timer to a scheduled event (DHCP renew or similar) would stop it from quitting entirely. + A netlink message informing networkd of new interfaces or removal of interfaces would reset the timer. Honestly, why does networkd need to keep running after configuring a static address? It is only needed when the admin wants to bring the network down, or when some interfaces change (which would cause it to to be started again by udev and look at what has changed). This would also work with your nspawn use case: When a new veth appears, networkd is launched and sees the new veth. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd on by default?
On Fri, 21.02.14 15:44, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Reindl Harald at 21/02/14 08:45 did gyre and gimble: Am 21.02.2014 04:41, schrieb Zbigniew Jędrzejewski-Szmek: On Fri, Feb 21, 2014 at 04:00:10AM +0100, Jason A. Donenfeld wrote: systemd-networkd seems to get started by default in 209. Why is this? What if I don't want to use it to manage my networks? Why does it have to be on by default? I think the reasoning was that it doesn't do anything by default (when there are no configuration files) that is a bad reasoning not a single process should be running if it has no job to do for the sake of ressource usage, security and clean systems Well I kinda get that using it for containers and such like could be useful, but I also suspect it should be bus or socket activated rather than statically enabled... like localed, datetimed etc. Any reason to enable it statically? (I guess it maybe has to do stuff by itself, but I would figure udev should kick it in via the setup link built in in most cases - but I guess that wouldn't work inside containers, so perhaps this is where things break down and you need it statically enabled). networkd has a set of config files that have [Match] sections in them that described to which interface types they apply. networkd watches network interfaces come and go and picks the config file with the highest prio and apply that. If there is none it will not do anything and leave the interface for other components. In addition to that it can actually create devices based on .netdev files. What networkd does hence is dependent on devices showing up as well as configuration files, and they do not map trivially against each other. This means that we need to start networkd both when there is config around and when net devices pop up. Now with the veth stuff there will always be config around and on pretty much any system there will be network interfaces around of some kind, hence it would tsart anyway by default. And given that that is how it is we simply start it at boot, because it is simpler, and less magic... networkd does not currently have a client API, thus socket and bus activation do not apply. 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] journald: ignore failure to watch hostname_fd on older kernels
Prior to 3.2, /proc/sys/kernel/hostname isn't a pollable file and
sd_event_add_io will return EPERM. Ignore this failure, since it isn't
critical to journald operation.
---
Reported and tested by user sraue on IRC.
src/journal/journald-server.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 5872e91..add6cf5 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -1430,6 +1430,14 @@ static int server_open_hostname(Server *s) {
r = sd_event_add_io(s-event, s-hostname_event_source,
s-hostname_fd, 0, dispatch_hostname_change, s);
if (r 0) {
+/* kernels prior to 3.2 don't support polling this file.
+ * quietly ignore the failure. */
+if (r == -EPERM) {
+close_nointr_nofail(s-hostname_fd);
+s-hostname_fd = -1;
+return 0;
+}
+
log_error(Failed to register hostname fd in event loop: %s,
strerror(-r));
return r;
}
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
True, but this requires manual patching and fixing up of `make
install`, which is a bummer.
Why?
Your debian/rules or rpmspec %build can simply do something like this:
make install
rm -f ${DEST}/etc/systemd/system/FOOO.BAR
that is much easier than quilt patches that modify Makefile.am. Also,
those patches tend to not apply from time to time (if the area around
the patch got changed upstream).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd on by default?
On Fri, 21.02.14 16:51, Reindl Harald (h.rei...@thelounge.net) wrote: Well I kinda get that using it for containers and such like could be useful, but I also suspect it should be bus or socket activated rather than statically enabled... like localed, datetimed etc. Any reason to enable it statically? (I guess it maybe has to do stuff by itself, but I would figure udev should kick it in via the setup link built in in most cases - but I guess that wouldn't work inside containers, so perhaps this is where things break down and you need it statically enabled) statically enabled is bad in general, containers are not a good reason to enable something for everybody, many if not most people never will use containers for several reasons and if it because they use full-virtualization and move machines between different also non-linux hosts Tom changed git to not statically enable it anymore, but still enable it by default. where i would support something new enabled by default is if could *replace* something else like LSB network.service while use it's ifcfg-configurations for backward compatibility and test out if it really can replace all cases Well, the old network script is not part of LSB... But yeah, networkd should already cover much of what ifcfg could do, but not everything. There are some thing that'll be added shortly (like dhcp6 support), but others we will never support, such as isdn... if i can replace that below i start to be one of the first production users in a complexer setup (one is the MAC of the physical card, the other is what it becames before fetch the IP from the ISP because you need to register your MAC there, that's the same like MAC cloning in small soho-routers) DEVICE=eth1 HWADDR=68:05:ca:0d:62:c1 ONBOOT=yes BOOTPROTO=dhcp IPV6INIT=no NM_CONTROLLED=no USERCTL=no PEERDNS=no MACADDR=00:50:8d:b5:cc:de Yes, you can do that. drop in a .link file that looks something like this: [Match] MACAddress=68:05:ca:0d:62:c1 [Link] MACAddress=00:50:8d:b5:cc:de Name=foobar With that the device will be matche against 68:05:ca:0d:62:c1 and when that exists we will rename it to foobar and apply the address 00:50:8d:b5:cc:de to it. Then, also drop in a .network file: [Match] Name=foobar [Network] DHCP=yes And there you go. (Note that the ethXYZ namespace is used by the kernel, we will not allow renaming interfaces to that so that we never race against the kernel. Hence the example above uses foobar as interface name instead. 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] systemctl: fix description of --after/--before
It was backward - --after fetches After property, so units shown really come *before* unit given as argument. Same for --before. --- man/systemctl.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/systemctl.xml b/man/systemctl.xml index 355cd11..fef9578 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -148,8 +148,8 @@ along with systemd; If not, see http://www.gnu.org/licenses/. termoption--before/option/term listitem - paraShow which units are started after or before - with commandlist-dependencies/command, respectively. + paraShow after (before) which units the specified unit is started + with commandlist-dependencies/command. /para /listitem /varlistentry -- tg: (74fae42..) u/systemctl-list-deps-man (depends on: master) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journald: ignore failure to watch hostname_fd on older kernels
On Fri, Feb 21, 2014 at 11:22:50AM -0500, Dave Reisner wrote:
Prior to 3.2, /proc/sys/kernel/hostname isn't a pollable file and
sd_event_add_io will return EPERM. Ignore this failure, since it isn't
critical to journald operation.
---
Reported and tested by user sraue on IRC.
This should probably go above ---, to give credit in the changelog.
src/journal/journald-server.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 5872e91..add6cf5 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -1430,6 +1430,14 @@ static int server_open_hostname(Server *s) {
r = sd_event_add_io(s-event, s-hostname_event_source,
s-hostname_fd, 0, dispatch_hostname_change, s);
if (r 0) {
+/* kernels prior to 3.2 don't support polling this file.
+ * quietly ignore the failure. */
+if (r == -EPERM) {
+close_nointr_nofail(s-hostname_fd);
+s-hostname_fd = -1;
+return 0;
+}
Critical not, but certainly worth a warning.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add -lresolv to libudev LIBADD
It was 2014-02-21 pią 17:06, when Kay Sievers wrote: On Fri, Feb 21, 2014 at 4:58 PM, Łukasz Stelmach l.stelm...@samsung.com wrote: It was 2014-02-21 pią 16:22, when Lennart Poettering wrote: On Fri, 21.02.14 15:54, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Fix problems with unresolved symbols when building on Ubuntu 12.04 x86_64. --8---cut here---start-8--- ./.libs/libudev.so: undefined reference to `__res_search' ./.libs/libudev.so: undefined reference to `__res_query' collect2: ld returned 1 exit status --8---cut here---end---8--- This doesn't look right. libudev really shouldn't need libresolv. We should figure out how these calls got pulled in... Let me go step-by-step: --8---cut here---start-8--- $ strings ./.libs/libudev.so | grep __res_'\(query\|search\)' __res_query __res_search # libudev needs libsystemd-internal $ strings ./.libs/libsystemd-internal.a | grep __res_'\(query\|search\)' This does not seem to happen here. Are you sure that as-needed is working in your setup? Stracing gcc linking libudev.so shows --as-needed interleaved with --no-as-needed. This is how libudev.so.1.4.0 is created --8---cut here---start-8--- /usr/bin/ld.bfd.real --sysroot=/ --build-id --no-add-needed --as-needed --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -shared -z relro -o .libs/libudev.so.1.4.0 /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.6/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/4.6 -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.6/../../.. src/libudev/.libs/libudev_la-libudev.o src/libudev/.libs/libudev_la-libudev-list.o src/libudev/.libs/libudev_la-libudev-util.o src/libudev/.libs/libudev_la-libudev-device.o src/libudev/.libs/libudev_la-libudev-enumerate.o src/libudev/.libs/libudev_la-libudev-monitor.o src/libudev/.libs/libudev_la-libudev-queue.o src/libudev/.libs/libudev_la-libudev-hwdb.o --whole-archive ./.libs/libsystemd-internal.a ./.libs/libsystemd-shared.a --no-whole-archive -lrt -ldl --as-needed --no-undefined --gc-sections -z relro -z now --version-script=./src/libudev/libudev.sym -soname libudev.so.1 -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.6/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/crtn.o --8---cut here---end---8--- Got it! --whole-archive before libsystemd-*.a that is! --8---cut here---start-8--- $ git grep whole.archive $ grep -rl whole.archive . ./autom4te.cache/output.2 ./autom4te.cache/output.1 ./autom4te.cache/output.0 ./config.status ./build-aux/ltmain.sh ./configure ./m4/libtool.m4 ./libtool --8---cut here---end---8--- -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics pgpdU73u0Ig1s.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journald: ignore failure to watch hostname_fd on older kernels
On Fri, Feb 21, 2014 at 06:00:46PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Feb 21, 2014 at 11:22:50AM -0500, Dave Reisner wrote:
Prior to 3.2, /proc/sys/kernel/hostname isn't a pollable file and
sd_event_add_io will return EPERM. Ignore this failure, since it isn't
critical to journald operation.
---
Reported and tested by user sraue on IRC.
This should probably go above ---, to give credit in the changelog.
src/journal/journald-server.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 5872e91..add6cf5 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -1430,6 +1430,14 @@ static int server_open_hostname(Server *s) {
r = sd_event_add_io(s-event, s-hostname_event_source,
s-hostname_fd, 0, dispatch_hostname_change, s);
if (r 0) {
+/* kernels prior to 3.2 don't support polling this file.
+ * quietly ignore the failure. */
+if (r == -EPERM) {
+close_nointr_nofail(s-hostname_fd);
+s-hostname_fd = -1;
+return 0;
+}
Critical not, but certainly worth a warning.
Zbyszek
Thanks, I'll push with these 2 changes.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Infiniband network (IPoIB) support in networkd
Greetings What are the current plans for Infiniband network (IPoIB) support in networkd? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Infiniband network (IPoIB) support in networkd
On Fri, Feb 21, 2014 at 06:23:25PM +, Jóhann B. Guðmundsson wrote: Greetings What are the current plans for Infiniband network (IPoIB) support in networkd? Why wouldn't it just work today? Have you tried it? If so, what is missing? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker, Supervisor and systemd
On Thu, 20.02.14 23:25, Paul Menzel (paulepan...@users.sourceforge.net) wrote: Dear systemd folks, Docker, “an open-source project to easily create lightweight, portable, self-sufficient containers from any application”, [1] mostly recommends to use Supervisor [2] to control the processes to be run in the container, like starting and restarting them and logging the output. Actually all things systemd also does to my knowledge. Supervisor also needs a configuration file for each process, which it should start. Has somebody experiences to use systemd for that? Or is there a reason why systemd should not be used for that? systemd should work fine for that. I figure systemd is not yet everywhere hence they suggest an option you can install everywhere... I had a look at the configuration file language of supervisord. THere appears to be nothing interesting we couldn't do already. I mean, there are certain differences, for example they have an XMLRPC API, while ours is via D-Bus, but other than that I don't see much... They have some fcgi hookup, but I don't grok that, and I figure we already can do kinda the same with socket activation, but dunno... 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] Infiniband network (IPoIB) support in networkd
On 02/21/2014 06:34 PM, Greg KH wrote: On Fri, Feb 21, 2014 at 06:23:25PM +, Jóhann B. Guðmundsson wrote: Greetings What are the current plans for Infiniband network (IPoIB) support in networkd? Why wouldn't it just work today? Have you tried it? If so, what is missing? Nope not tried it, I assumed since it had TYPE=Infiniband in the ifcfg file for it that it required an entry in netdev_kind_table ( NETDEV_KIND_INFINIBAND]= infiniband ) went looking did not see it then simply asked. If it's not required and just works today problem solved. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Infiniband network (IPoIB) support in networkd
On Fri, Feb 21, 2014 at 07:25:50PM +, Jóhann B. Guðmundsson wrote: On 02/21/2014 06:34 PM, Greg KH wrote: On Fri, Feb 21, 2014 at 06:23:25PM +, Jóhann B. Guðmundsson wrote: Greetings What are the current plans for Infiniband network (IPoIB) support in networkd? Why wouldn't it just work today? Have you tried it? If so, what is missing? Nope not tried it, I assumed since it had TYPE=Infiniband in the ifcfg file for it that it required an entry in netdev_kind_table ( NETDEV_KIND_INFINIBAND]= infiniband ) went looking did not see it then simply asked. If the device shows up as a normal network device, it should work just fine, if no special commands/programs need to be run. If it's not required and just works today problem solved. Try it out and let us know. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: networkd typo fixes
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com --- Not too sure about the bridge - netdev change. It just seemed a strange to read since we set the type a bit later to be either bridge, bond, or vlan. man/systemd-networkd.service.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/systemd-networkd.service.xml b/man/systemd-networkd.service.xml index 51ae761..026536e 100644 --- a/man/systemd-networkd.service.xml +++ b/man/systemd-networkd.service.xml @@ -68,7 +68,7 @@ paraNetwork configurations applied before networkd is started are not removed, and static configuration applied by networkd -are not removed when networkd exits. This ensures restarting +is not removed when networkd exits. This ensures restarting networkd does not cut the network connection, and, in particular, that it is safe to transition between the initrd and the real root, and back./para @@ -153,7 +153,7 @@ termvarnameName=/varname/term listitem paraThe interface name used when creating the -bridge. This option is compulsory./para +netdev. This option is compulsory./para /listitem /varlistentry varlistentry -- 1.8.5.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: networkd typo fixes
On Fri, Feb 21, 2014 at 8:54 PM, Thomas H.P. Andersen pho...@gmail.com wrote: From: Thomas Hindoe Paaboel Andersen pho...@gmail.com --- Not too sure about the bridge - netdev change. It just seemed a strange to read since we set the type a bit later to be either bridge, bond, or vlan. man/systemd-networkd.service.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/systemd-networkd.service.xml b/man/systemd-networkd.service.xml index 51ae761..026536e 100644 --- a/man/systemd-networkd.service.xml +++ b/man/systemd-networkd.service.xml @@ -68,7 +68,7 @@ paraNetwork configurations applied before networkd is started are not removed, and static configuration applied by networkd -are not removed when networkd exits. This ensures restarting +is not removed when networkd exits. This ensures restarting networkd does not cut the network connection, and, in particular, that it is safe to transition between the initrd and the real root, and back./para @@ -153,7 +153,7 @@ termvarnameName=/varname/term listitem paraThe interface name used when creating the -bridge. This option is compulsory./para +netdev. This option is compulsory./para /listitem /varlistentry varlistentry Applied. Thanks! -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd-run: update bash completion
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com
Add:
--system
-H --host
-M --machine
--service-type (options: simple forking oneshot dbus notify idle)
--uid
--gid
--nice
--setenv
---
The last 5 are not documented in the man page. The options for --service-type
are my guess. Please review.
shell-completion/bash/systemd-run | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/shell-completion/bash/systemd-run
b/shell-completion/bash/systemd-run
index ab55274..50b5c76 100644
--- a/shell-completion/bash/systemd-run
+++ b/shell-completion/bash/systemd-run
@@ -3,6 +3,7 @@
# This file is part of systemd.
#
# Copyright 2013 Zbigniew Jędrzejewski-Szmek
+# Copyright 2014 Thomas H.P. Andersen
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
@@ -25,9 +26,16 @@ __systemctl() {
__get_slice_units () { __systemctl $1 list-units --all -t slice \
| { while read -r a b c d; do echo $a; done; }; }
+__get_machines() {
+local a b
+machinectl list --no-legend --no-pager | { while read a b; do echo
$a; done; };
+}
+
_systemd_run() {
local cur=${COMP_WORDS[COMP_CWORD]} prev=${COMP_WORDS[COMP_CWORD-1]}
-local OPTS='-h --help --version --user --scope --unit --description
--slice -r --remain-after-exit --send-sighup'
+local OPTS='-h --help --version --user --system --scope --unit
--description --slice
+-r --remain-after-exit --send-sighup -H --host -M --machine
--service-type
+--uid --gid --nice --setenv'
local mode=--system
local i
@@ -40,7 +48,7 @@ _systemd_run() {
[[ ${COMP_WORDS[i]} == --user ]] mode=--user
-[[ $i -lt $COMP_CWORD ${COMP_WORDS[i]} ==
@(--unit|--description|--slice) ]] ((i++))
+[[ $i -lt $COMP_CWORD ${COMP_WORDS[i]} ==
@(--unit|--description|--slice|--service-type|-H|--host|-M|--machine) ]]
((i++))
done
case $prev in
@@ -54,6 +62,24 @@ _systemd_run() {
COMPREPLY=( $(compgen -W '$comps' -- $cur) )
return 0
;;
+--service-type)
+local comps='simple forking oneshot dbus notify idle'
+
+COMPREPLY=( $(compgen -W '$comps' -- $cur) )
+return 0
+;;
+-H|--host)
+local comps=$(compgen -A hostname)
+
+COMPREPLY=( $(compgen -W '$comps' -- $cur) )
+return 0
+;;
+-M|--machine)
+local comps=$( __get_machines )
+
+COMPREPLY=( $(compgen -W '$comps' -- $cur) )
+return 0
+;;
esac
COMPREPLY=( $(compgen -W '${OPTS[*]}' -- $cur) )
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fix SECCOMP_CFLAGS usage
El 18/02/14 11:27, Zbigniew Jędrzejewski-Szmek escribió: On Tue, Feb 18, 2014 at 10:56:36AM -0300, Cristian Rodríguez wrote: SECCOMP_CFLAGS must be in the global CFLAGS as seccomp.h is included in core/execute.h. when seccomp.h is not in the standard path.(i.e openSUSE has it in /usr/include/pkg/libseccomp/, precisely to catch this kind of bugs) compiling systemd fails. --- Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile.am b/Makefile.am index 79c49e6..18df645 100644 --- a/Makefile.am +++ b/Makefile.am @@ -196,6 +196,7 @@ AM_CPPFLAGS = \ -I $(top_srcdir)/src/libsystemd/sd-bus \ -I $(top_srcdir)/src/libsystemd/sd-event \ -I $(top_srcdir)/src/libsystemd/sd-rtnl \ + $(SECCOMP_CFLAGS) \ $(OUR_CPPFLAGS) Applied. Zbyszek This is broken again... In file included from ./src/core/unit.h:40:0, from src/shared/condition-util.c:35: ./src/core/execute.h:37:21: fatal error: seccomp.h: No such file or directory #include seccomp.h ^ compilation terminated. Broken by e9642be2cce7f5e90406980092a6f71f504a16af ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
