Re: [systemd-devel] should random seeds go into /var/cache?
Hey Lennart, On Mon, May 2, 2022 at 11:19 AM Lennart Poettering wrote: > I think /var/cache/ is not the right place, because of the weak > persistency guarantees on it. i.e. /var/cache/ much like /var/tmp/ > means "hey, please keep this, but it's OK if you don't". I think > that's too little though for the random seed, because if the random > seed is not kept it's entirely useless. There is no need to keep a > random seed in the file system if it would be flushed out on each > boot... > > /var/lib/ otoh sounds much more appropriate as it means "please keep > this", and that's exactly the persistance requirement we want here. Alright, thanks a lot for the clarification. Seems like a reasonable argument. I'll keep things as-is. Jason
[systemd-devel] should random seeds go into /var/cache?
Hey,
I've been working on my small seedrng utility, which is more or less
the same thing as systemd-random-seed.service, with a few unimportant
design differences here and there. As I'd worked with
systemd-random-seed.service quite a bit before, its choices comprised
much of my mental model starting out.
One of the things I did like systemd-random-seed.service without
really thinking too much about it is I made use of /var/lib/seedrng/,
just as systemd uses /var/lib/systemd/random-seed/. Seems reasonable
enough I guess. But I was thinking: wouldn't /var/cache/{blah}/ be the
better for this? Seeds are supposed to be somewhat volatile, and
shouldn't be copied between images, and the default behavior of
/var/lib is usually to be copied, whereas /var/cache usually isn't.
There's also /var/tmp too, right? Which is supposed to be never a
tmpfs or something? But "cache" seems a bit more fitting than
"temporary".
Anyway, I'm not really sure what makes the most sense, and it seems
like FHS placement is more of an art than a science. I don't think I'm
super far off, though, in at least wondering whether random seeds
belong in /var/cache rather than /var/lib.
Does anybody have opinions on this? Should I just submit a PR moving
the systemd seeds to /var/cache and see what happens?
Jason
Re: [systemd-devel] Dropping split-usr/unmerged-usr support
Hi Wol, On Fri, Apr 8, 2022 at 12:02 AM Wol wrote: > > On 07/04/2022 17:47, Mike Gilbert wrote: > >> So, my guess would be that the people who dislike merged-/usr are also > >> the ones who dislike systemd, no? i.e. do they really matter if we are > >> talking about what to support in systemd? They'd not use our stuff > >> anyway, so why bother? > > There's probably also a big minority of users (like me) who may be > pro-systemd, but run a systemd-hostile distro for reasons that are > nothing to do with systemd ... > > > There's probably a large overlap between users who don't like systemd > > and users who don't like merged-/usr. I would guess we don't have a > > critical mass of users/developers running systemd. > > > > I could probably force the users who do run systemd to migrate to > > merged-/usr, but I don't really see much benefit from that if all > > other packages in Gentoo still need to support both configurations. > > And I'm sorry if I upset Mike, but I class gentoo as systemd-hostile. > It's MUCH easier to install/run Gentoo with OpenRC, systemd isn't that > well documented (it's better than it was). There are people who support > systemd, but I get the impression it's seen as an unwanted rival to OpenRC. I was actually just talking about merged usr with some people in #gentoo-dev the other day. I was at first wondering, "hey have we done this? what's the hold up?" And the answer seemed to be that nobody has really got around to it, and there's not currently a huge champion of the project moving it forward. Somebody piped up kind of mildly opposed, and then I explained what the general vision for merged usr is (hermetic OS in /usr and such), and felt like the reception to that was actually somewhat welcoming. Later I posted a link to Lennart's latest blog post, and people seemed to think it was cool. Somebody mentioned they were going to try out merged usr on Gentoo to see what happened, and another person mentioned they were the author of a blog post tutorial on how to do it. A few conversations over the course of the day in an IRC channel isn't necessarily representative of the whole project, but the impression I got was way less so about hostility and more so just that nobody has gotten around to doing the work and tracking whatever bugs come out of it that need to be fixed. It's been started, but seems to have fizzled. Maybe the recent discussion here and funny happenings over in Debian will inject some life into it. So maybe we'll wind up with merged usr after all. No promises, but I think it's much more a matter of "when" than "if". (My personal 2ยข is that I'd be happy to see systemd help corral us stragglers into merged usr, and in the process, drop some complexity of its own for supporting unmerged usr.) Jason
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, Jun 2, 2015 at 1:06 PM, David Herrmann dh.herrm...@gmail.com wrote: Regarding the final github address: David Strauss kindly offered the 'systemd' user to us. Hence, we hope to move the repository to github.com/systemd/systemd this week. Sorry for the confusion, I hope we can settle all this this week. I recommend you get this sorted out as soon as possible and not wait another moment. People have already submitted pull requests to both repos, and things are going to get quite confusing if you don't move fast on this. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] timesyncd, dnssec
Hey Lennart Folks, I've been watching the commits come in for timesyncd. I saw recently you're restoring the time from file timestamps, just so something is decently recent. Neat. I thought I'd share a problem I had with another init system with regards to NTP and DNSSEC, so that it's somewhere in the back of your mind when designing the dependency system for timesyncd. Machine with no battery powered clock. NTPd (timesyncd in this case) needs DNS to resolve NTP servers. Local DNS resolver, in this case unbound, requires correct time to do proper DNSSEC validation. So, NTP needs DNS, but DNS needs NTP. Temporary work around is to hard code IPs into NTP. To add to the problem: Internet requires PPPoE. Aspects of PPPoE negotiation require having a correct time. So in sum: Internet needs PPPoE. PPPoE needs NTP. NTP needs Internet. NTP needs DNS. DNS needs NTP. DNS needs Internet. The easiest solution has been to just not use DNS for NTP, and instead hardcode IPs. But maybe these types of weird constraints have better solutions. I'm no longer seeking an answer, as I don't administer this setup anymore, but I thought this kind of (possibly common) weirdness might be something to keep in mind. Thanks, Jason ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] commas vs spaces in config syntax
Hey folks, Just came across this section in the systemd-sleep.conf man page: More than one value can be specified by separating multiple values with commas. But then I remember seeing in 99-default.link the line, NamePolicy=database onboard slot path. It seems like our configuration syntax is a bit inconsistent. Which is better? Should things change? Jason ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd version debus call changed
FYI to others experiencing weirdness, the Version api function changed between 208 and 209: in 208: zx2c4@thinkpad ~ $ sudo qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.Version systemd 208 in 209 and 210: zx2c4@thinkpad ~ $ sudo qdbus --system org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager.Version 210 This apparently, as of writing, causes in KDE: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp#L48 In KDE, this breaks suspend support. In case anyone else hits this snag, here's the issue. ___ 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] 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, 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] 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: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, 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
[systemd-devel] discussions of pkg-config black magic over at gentoo
Hey guys, Thought I'd put this discussion upstream. At the moment at Gentoo [1], we're considering building without the compat-libs, but still with installing the pkg-config files, so that most out of date packages will work with a rebuild without having to patch the build system, and we won't have to ship the old libraries, which is problematic for us because we want to support ARM. So right now we're considering something like this [2] or [3]. A bit of a bummer to patch the build system like this, but we don't want to rely on IFUNC, and this seems like the cleanest solution. So I thought I'd mention this up here in case folks have opinions and such. Thanks, Jason [1] https://bugs.gentoo.org/show_bug.cgi?id=501860 [2] https://bugs.gentoo.org/attachment.cgi?id=370894action=diff [3] https://bugs.gentoo.org/attachment.cgi?id=370896action=diff ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unmentioned 209 change: 80-net-name-slot.rules is gone
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. Jason ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd on by default?
Hi folks, 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? Jason ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
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. --- Makefile.am | 3 --- units/systemd-networkd.service.in | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile.am b/Makefile.am index c71367d..0e4ce72 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3921,9 +3921,6 @@ systemd_networkd_LDADD = \ nodist_systemunit_DATA += \ units/systemd-networkd.service -MULTI_USER_TARGET_WANTS += \ - systemd-networkd.service - test_network_SOURCES = \ src/network/test-network.c \ src/network/networkd.h \ diff --git a/units/systemd-networkd.service.in b/units/systemd-networkd.service.in index 835c07d..ca40691 100644 --- a/units/systemd-networkd.service.in +++ b/units/systemd-networkd.service.in @@ -20,3 +20,6 @@ Restart=always RestartSec=0 ExecStart=@rootlibexecdir@/systemd-networkd WatchdogSec=1min + +[Install] +WantedBy=multi-user.target -- 1.8.5.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] README: audit no longer breaks container
Ever since the seccomp trick, this is no longer an issue. --- README | 7 --- 1 file changed, 7 deletions(-) diff --git a/README b/README index b918132..df04cc9 100644 --- a/README +++ b/README @@ -83,13 +83,6 @@ REQUIREMENTS: CONFIG_EFI_VARS CONFIG_EFI_PARTITION -Note that kernel auditing is broken when used with systemd's -container code. When using systemd in conjunction with -containers, please make sure to either turn off auditing at -runtime using the kernel command line option audit=0, or -turn it off at kernel compile time using: - CONFIG_AUDIT=n - glibc = 2.14 libcap libseccomp = 1.0.0 (optional) -- 1.8.5.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sd-rtnl: use correct function convention
Ret values come second.
---
src/libsystemd/sd-rtnl/rtnl-util.c | 4 ++--
src/libsystemd/sd-rtnl/sd-rtnl.c | 4 ++--
src/libsystemd/sd-rtnl/test-rtnl.c | 8
src/nspawn/nspawn.c| 6 +++---
src/systemd/sd-rtnl.h | 4 ++--
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/libsystemd/sd-rtnl/rtnl-util.c
b/src/libsystemd/sd-rtnl/rtnl-util.c
index ec1a92e..3bdb4f6 100644
--- a/src/libsystemd/sd-rtnl/rtnl-util.c
+++ b/src/libsystemd/sd-rtnl/rtnl-util.c
@@ -42,7 +42,7 @@ int rtnl_set_link_name(sd_rtnl *rtnl, int ifindex, const char
*name) {
if (r 0)
return r;
-r = sd_rtnl_call(rtnl, message, 0, NULL);
+r = sd_rtnl_call(rtnl, NULL, message, 0);
if (r 0)
return r;
@@ -91,7 +91,7 @@ int rtnl_set_link_properties(sd_rtnl *rtnl, int ifindex,
const char *alias,
}
if (need_update) {
-r = sd_rtnl_call(rtnl, message, 0, NULL);
+r = sd_rtnl_call(rtnl, NULL, message, 0);
if (r 0)
return r;
}
diff --git a/src/libsystemd/sd-rtnl/sd-rtnl.c b/src/libsystemd/sd-rtnl/sd-rtnl.c
index 0588965..70333fb 100644
--- a/src/libsystemd/sd-rtnl/sd-rtnl.c
+++ b/src/libsystemd/sd-rtnl/sd-rtnl.c
@@ -537,9 +537,9 @@ int sd_rtnl_call_async_cancel(sd_rtnl *nl, uint32_t serial)
{
}
int sd_rtnl_call(sd_rtnl *nl,
+sd_rtnl_message **ret,
sd_rtnl_message *message,
-uint64_t usec,
-sd_rtnl_message **ret) {
+uint64_t usec) {
usec_t timeout;
uint32_t serial;
bool room = false;
diff --git a/src/libsystemd/sd-rtnl/test-rtnl.c
b/src/libsystemd/sd-rtnl/test-rtnl.c
index 7bbc448..d965592 100644
--- a/src/libsystemd/sd-rtnl/test-rtnl.c
+++ b/src/libsystemd/sd-rtnl/test-rtnl.c
@@ -41,7 +41,7 @@ static void test_link_configure(sd_rtnl *rtnl, int ifindex) {
assert(sd_rtnl_message_append_ether_addr(message, IFLA_ADDRESS,
ether_aton(mac)) = 0);
assert(sd_rtnl_message_append_u32(message, IFLA_MTU, mtu) = 0);
-assert(sd_rtnl_call(rtnl, message, 0, NULL) == 1);
+assert(sd_rtnl_call(rtnl, NULL, message, 0) == 1);
assert(sd_rtnl_message_read(message, type, data) 0);
assert(type == IFLA_IFNAME);
@@ -80,7 +80,7 @@ static void test_link_get(sd_rtnl *rtnl, int ifindex) {
assert(sd_rtnl_message_append_u32(m, IFLA_NUM_TX_QUEUES, 0) = 0);
assert(sd_rtnl_message_append_u32(m, IFLA_NUM_RX_QUEUES, 0) = 0);
-assert(sd_rtnl_call(rtnl, m, -1, r) == 1);
+assert(sd_rtnl_call(rtnl, r, m, -1) == 1);
/* u8 read back */
assert(sd_rtnl_message_read(m, type, data) == 1);
@@ -372,14 +372,14 @@ int main(void) {
assert(sd_rtnl_message_read(m, type, data) == -EPERM);
-assert(sd_rtnl_call(rtnl, m, 0, r) == 1);
+assert(sd_rtnl_call(rtnl, r, m, 0) == 1);
assert(sd_rtnl_message_get_type(r, type) = 0);
assert(type == RTM_NEWLINK);
assert(sd_rtnl_message_read(m, type, data) == 0);
assert((r = sd_rtnl_message_unref(r)) == NULL);
-assert(sd_rtnl_call(rtnl, m, -1, r) == -EPERM);
+assert(sd_rtnl_call(rtnl, r, m, -1) == -EPERM);
assert((m = sd_rtnl_message_unref(m)) == NULL);
assert((r = sd_rtnl_message_unref(r)) == NULL);
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 089af07..beb347f 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -1369,7 +1369,7 @@ static int setup_veth(pid_t pid, char iface_name[]) {
return r;
}
-r = sd_rtnl_call(rtnl, m, 0, NULL);
+r = sd_rtnl_call(rtnl, NULL, m, 0);
if (r 0) {
log_error(Failed to add new veth interfaces: %s,
strerror(-r));
return r;
@@ -1422,7 +1422,7 @@ static int setup_bridge(const char veth_name[]) {
return r;
}
-r = sd_rtnl_call(rtnl, m, 0, NULL);
+r = sd_rtnl_call(rtnl, NULL, m, 0);
if (r 0) {
log_error(Failed to add veth interface to bridge: %s,
strerror(-r));
return r;
@@ -1491,7 +1491,7 @@ static int move_network_interfaces(pid_t pid) {
return r;
}
-r = sd_rtnl_call(rtnl, m, 0, NULL);
+r = sd_rtnl_call(rtnl, NULL, m, 0);
if (r 0) {
log_error(Failed to move interface %s to namespace:
%s, *i, strerror(-r));
return r;
diff --git a/src/systemd/sd-rtnl.h b/src/systemd/sd-rtnl.h
index 502183e..edb71d8 100644
--- a/src/systemd/sd-rtnl.h
+++ b/src/systemd/sd-rtnl.h
@@ -50,8 +50,8 @@ int sd_rtnl_call_async(sd_rtnl *nl, sd_rtnl_message *message,
sd_rtnl_message_handler_t callback,
void *userdata, uint64_t usec,
[systemd-devel] [PATCH] sd-bus: the bus returned should be the first arg
This matches the API of previous headers, such as sd-journal.h.
---
TODO | 2 --
src/libsystemd/sd-bus/bus-util.c | 8
src/libsystemd/sd-bus/sd-bus.c | 4 ++--
src/machine/machinectl.c | 2 +-
src/systemd/sd-bus.h | 4 ++--
5 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/TODO b/TODO
index e74aa7e..63f3f7e 100644
--- a/TODO
+++ b/TODO
@@ -29,8 +29,6 @@ Preparation for 209:
* Review new libraries
-* libsystemd-journal returns the object created as first param in
sd_journal_new(), sd_bus_new() and suchlike as last...
-
Features:
* implement Distribute= in socket units to allow running multiple
diff --git a/src/libsystemd/sd-bus/bus-util.c b/src/libsystemd/sd-bus/bus-util.c
index a468bca..8a6a70c 100644
--- a/src/libsystemd/sd-bus/bus-util.c
+++ b/src/libsystemd/sd-bus/bus-util.c
@@ -1054,11 +1054,11 @@ int bus_open_transport(BusTransport transport, const
char *host, bool user, sd_b
break;
case BUS_TRANSPORT_REMOTE:
-r = sd_bus_open_system_remote(host, bus);
+r = sd_bus_open_system_remote(bus, host);
break;
case BUS_TRANSPORT_CONTAINER:
-r = sd_bus_open_system_container(host, bus);
+r = sd_bus_open_system_container(bus, host);
break;
default:
@@ -1089,11 +1089,11 @@ int bus_open_transport_systemd(BusTransport transport,
const char *host, bool us
break;
case BUS_TRANSPORT_REMOTE:
-r = sd_bus_open_system_remote(host, bus);
+r = sd_bus_open_system_remote(bus, host);
break;
case BUS_TRANSPORT_CONTAINER:
-r = sd_bus_open_system_container(host, bus);
+r = sd_bus_open_system_container(bus, host);
break;
default:
diff --git a/src/libsystemd/sd-bus/sd-bus.c b/src/libsystemd/sd-bus/sd-bus.c
index 1187690..9b9a2a1 100644
--- a/src/libsystemd/sd-bus/sd-bus.c
+++ b/src/libsystemd/sd-bus/sd-bus.c
@@ -1214,7 +1214,7 @@ fail:
return r;
}
-_public_ int sd_bus_open_system_remote(const char *host, sd_bus **ret) {
+_public_ int sd_bus_open_system_remote(sd_bus **ret, const char *host) {
_cleanup_free_ char *e = NULL;
char *p = NULL;
sd_bus *bus;
@@ -1250,7 +1250,7 @@ _public_ int sd_bus_open_system_remote(const char *host,
sd_bus **ret) {
return 0;
}
-_public_ int sd_bus_open_system_container(const char *machine, sd_bus **ret) {
+_public_ int sd_bus_open_system_container(sd_bus **ret, const char *machine) {
_cleanup_free_ char *e = NULL;
sd_bus *bus;
char *p;
diff --git a/src/machine/machinectl.c b/src/machine/machinectl.c
index 3f4f8ac..ac2fbe3 100644
--- a/src/machine/machinectl.c
+++ b/src/machine/machinectl.c
@@ -618,7 +618,7 @@ static int login_machine(sd_bus *bus, char **args, unsigned
n) {
return -EIO;
}
-r = sd_bus_open_system_container(args[1], container_bus);
+r = sd_bus_open_system_container(container_bus, args[1]);
if (r 0) {
log_error(Failed to get container bus: %s, strerror(-r));
return r;
diff --git a/src/systemd/sd-bus.h b/src/systemd/sd-bus.h
index 34d4263..94a435ac 100644
--- a/src/systemd/sd-bus.h
+++ b/src/systemd/sd-bus.h
@@ -102,8 +102,8 @@ int sd_bus_default_system(sd_bus **ret);
int sd_bus_open(sd_bus **ret);
int sd_bus_open_user(sd_bus **ret);
int sd_bus_open_system(sd_bus **ret);
-int sd_bus_open_system_remote(const char *host, sd_bus **ret);
-int sd_bus_open_system_container(const char *machine, sd_bus **ret);
+int sd_bus_open_system_remote(sd_bus **ret, const char *host);
+int sd_bus_open_system_container(sd_bus **ret, const char *machine);
int sd_bus_new(sd_bus **ret);
int sd_bus_set_address(sd_bus *bus, const char *address);
--
1.8.5.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] kdbus.txt: grammatical fixes
--- kdbus.txt | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/kdbus.txt b/kdbus.txt index a3d806b..de36672 100644 --- a/kdbus.txt +++ b/kdbus.txt @@ -6,7 +6,7 @@ all communication between processes take place over special character device nodes in /dev/kdbus/. For the general D-Bus protocol specification, the payload format, the -marshaling, the communication semantics, please refer to: +marshaling, and the communication semantics, please refer to: http://dbus.freedesktop.org/doc/dbus-specification.html For a kdbus specific userspace library implementation please refer to: @@ -21,28 +21,28 @@ Terminology === Domain: A domain is a named object containing a number of buses. A system -container which contains its own init system and users usually also +container that contains its own init system and users usually also runs in its own kdbus domain. The /dev/kdbus/domain/container-name/ directory shows up inside the domain as /dev/kdbus/. Every domain offers a control device node to create new buses or domains. -Domains have no connection to each other, cannot see or talk to +Domains have no connection to each other and cannot see nor talk to each other. Only from the initial domain, given the process has the -needed access rights, the device nodes inside of other domains -can be seen. +required access rights, can the device nodes inside of other domains +be seen. Bus: A bus is a named object inside a domain. Clients exchange messages -over a bus. Multiple buses themselves have no connection to each other, +over a bus. Multiple buses themselves have no connection to each other; messages are only exchanged on the same bus. The default entry point to a bus, where clients establish the connection to, is the bus device node /dev/kdbus/bus name/bus. Common operating system setups create one system bus per system, and one -user bus for every logged-in user. Applications or services can create -their own private named buses if they want to. +user bus for every logged-in user. Applications or services may create +their own private named buses. Endpoint: -An endpoint provides the device node to talk to a bus. Opening a the -enpoint creates a new connection to the bus the endpoint belongs to. +An endpoint provides the device node to talk to a bus. Opening an +endpoint creates a new connection to the bus to which the endpoint belongs. Every bus has a default endpoint called bus. A bus can optionally offer additional endpoints with custom names to provide a restricted access to the same bus. Custom endpoints carry @@ -51,24 +51,24 @@ Terminology Connection: A connection to a bus is created by opening an endpoint device node of -a bus, and becoming an active client with the HELLO exchange. Every -connected client connection has a unique identifier on the bus, and can +a bus and becoming an active client with the HELLO exchange. Every +connected client connection has a unique identifier on the bus and can address messages to every other connection on the same bus by using the peer's connection id as the destination. Well-known Name: A connection can, in addition to its implicit unique connection id, request the ownership of a textual well-known name. Well-known names are noted -in reverse-domain notation like com.example.service. Connections offering +in reverse-domain notation, such as com.example.service. Connections offering a service on a bus are usually reached by its well-known name. The analogy of connection id and well-known name is an IP address and a DNS name associated with that address. Message: Connections can exchange messages with other connections by addressing -the peers with their connection id or well-known name. A message consist -of a message header with kernel-specific information how to route the -message, and the message payload which is a logical byte stream of +the peers with their connection id or well-known name. A message consists +of a message header with kernel-specific information on how to route the +message, and the message payload, which is a logical byte stream of arbitrary size. Messages can carry additional file descriptors to be passed from one connection to another. Every connection can specify which set of metadata the kernel should attach to the message when it is delivered -- 1.8.5.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] /run needs to be mounted? ugh.
Hey folks, I'm using better-initramfs [1], a very small and minimal initrd that has been working very well for me. In switching to systemd, I found it necessary to have the initrd mount /run as tmpfs, according to the specs [2]. I made a little patch for better-initramfs, and now I'm talking to the maintainer about merging that. But really... I don't want to do this. Why is systemd itself not capable of setting up /run? Why does the initrd need to do it? My experience booting without /run is that systemd then fails to start completely. Is this what's supposed to happen? What's going on? Preferably, I don't desire to place any additional systemd-specific burden on better-initramfs. Thanks, Jason [1] https://github.com/slashbeast/better-initramfs [2] http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /run needs to be mounted? ugh.
On Tue, Feb 11, 2014 at 5:01 PM, Dave Reisner d...@falconindy.com wrote: systemd is already capable of setting up /run on its own: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/mount-setup.c#n69 You appear to be right. In that case should the spec [1] be amended to remove this requirement? [1] http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /run needs to be mounted? ugh.
On Tue, Feb 11, 2014 at 5:01 PM, Dave Reisner d...@falconindy.com wrote: Strange name. I can't find one thing which I find better about this project compared to the more well-known initramfs creation tools. I'd appreciate it if you kept the antagonism to a minimum. It adds nothing to the technical discussion. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /run needs to be mounted? ugh.
On Tue, Feb 11, 2014 at 5:15 PM, Dave Reisner d...@falconindy.com wrote: I don't think there's any change needed here. The interface states: The initrd should mount /run as a tmpfs. And sure enough, this isn't a requirement, but there's many valid reasons to do this. Ahh, okay. I suppose what I'm wondering is what the advantages are to mounting /run (if the remaining interfaces in the list aren't used)? It looks like mounting /run occurs pretty soon in core/main.c. Could it be that the only advantages of mounting /run early on are for using the more advanced systemd initrd interfaces, such as giving control back during shutdown? Or are there benefits in doing this even for the most minimal of initrd? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /run needs to be mounted? ugh.
On Tue, Feb 11, 2014 at 5:25 PM, Lennart Poettering lenn...@poettering.net wrote: An initrd without /run is mostly pointless, no? Either you have storage daemons and hence need /run around, or you don't have storage daemons, in which case you can just boot without involving any initrd? In my use of an initrd, I just use cryptsetup, which AFAIK, isn't a storage daemon but rather reads the LUKS header, determines the key, and calls the ioctl to get it mapped. In this case, all the 'state' remains in the kernel, and thus doesn't require /run. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /run needs to be mounted? ugh.
On Tue, Feb 11, 2014 at 6:25 PM, Colin Guthrie gm...@colin.guthr.ie wrote: As has been mentioned elsewhere on this thread, there are a number of gotchas and corner cases, that this mechanism solved, even in the cases of things working. In my case, I'm just using devtmpfs and cryptsetup, and then switching into the real root and execing systemd. So presumably I do not need a /run, correct? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /run needs to be mounted? ugh.
On Tue, Feb 11, 2014 at 5:25 PM, Lennart Poettering lenn...@poettering.net wrote: Hmm, so how do you wait for the LUKS device to show up? You need something like udev around, which uses /run... And AFAIR the DM userspace does keep some runtime state around, and that one probably wants to pass over to the host OS... Lennart devtmpfs does the trick. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /run needs to be mounted? ugh.
On Tue, Feb 11, 2014 at 7:56 PM, Lennart Poettering lenn...@poettering.net wrote: devtmpfs does not give you notifications when devices appear. If you want to generically wait for the right LUKS device to show up, you need something like udev in the mix, which provides you with notifications for this... My drivers are compiled into my kernel, and the kernel is on the same drive (though a different partition) as the one that's going to be cryptsetup'd. Things work super well and super simply. It's very minimal. As far as I can see with my particular setup, there are no potential races either. Cryptsetup itself works fine without the udev hooks, as the mapped device node is created before luksOpen exits. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] pager: remove --no-init setting from LESS options
On Tue, Feb 11, 2014 at 6:40 PM, Lennart Poettering
lenn...@poettering.net wrote:
I think adding support for $SYSTEMD_LESS which is copied to $LESS right
before invoking less would be a good choice, since it would allow people
to override whatever systemd tries to set.
So something along the lines of:
user_less = getenv(SYSTEMD_LESS);
if (!user_less) {
if (scroll_to_end)
final_less = FRSXMK+G;
else
final_less = FRSXMK;
} else {
if (scroll_to_end)
final_less = concat(user_less, +G);
else
final_less = user_less;
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] pager: support SYSTEMD_LESS environment variable
This allows customization of the arguments used by less. The main
motivation is that some folks might not like having --no-init on every
invocation of less.
---
If you'd like me to update some documentation, let me know what
files I should edit, and I'll send a v2.
src/shared/pager.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/src/shared/pager.c b/src/shared/pager.c
index 72a29f2..4a7be4e 100644
--- a/src/shared/pager.c
+++ b/src/shared/pager.c
@@ -50,6 +50,8 @@ noreturn static void pager_fallback(void) {
int pager_open(bool jump_to_end) {
int fd[2];
const char *pager;
+char *less_opts;
+_cleanup_free_ *joined_less_opts = NULL;
pid_t parent_pid;
int r;
@@ -88,10 +90,17 @@ int pager_open(bool jump_to_end) {
dup2(fd[0], STDIN_FILENO);
close_pipe(fd);
-if (jump_to_end)
-setenv(LESS, FRSXMK+G, 1);
-else
-setenv(LESS, FRSXMK, 1);
+less_opts = getenv(SYSTEMD_LESS);
+if (!less_opts) {
+if (jump_to_end)
+less_opts = FRSXMK+G;
+else
+less_opts = FRSXMK;
+} else if (jump_to_end) {
+joined_less_opts = strjoin(less_opts, +G, NULL);
+less_opts = joined_less_opts;
+}
+setenv(LESS, less_opts, 1);
/* Make sure the pager goes away when the parent dies */
if (prctl(PR_SET_PDEATHSIG, SIGTERM) 0)
--
1.8.5.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] pager: support SYSTEMD_LESS environment variable
This allows customization of the arguments used by less. The main motivation is that some folks might not like having --no-init on every invocation of less. --- man/journalctl.xml | 4 man/localectl.xml | 4 man/loginctl.xml| 4 man/machinectl.xml | 4 man/systemctl.xml | 4 man/systemd-analyze.xml | 4 man/timedatectl.xml | 4 src/shared/pager.c | 19 ++- 8 files changed, 42 insertions(+), 5 deletions(-) diff --git a/man/journalctl.xml b/man/journalctl.xml index 3b05e80..18a1b9e 100644 --- a/man/journalctl.xml +++ b/man/journalctl.xml @@ -887,6 +887,10 @@ this to an empty string or the value literalcat/literal is equivalent to passing option--no-pager/option./para/listitem + termvarname$SYSTEMD_LESS/varname/term + listitemparavarname$SYSTEMD_LESS/varname overrides the + default options passed to literalless/literal + (literalFRSXMK/literal)./para/listitem /varlistentry /variablelist /refsect1 diff --git a/man/localectl.xml b/man/localectl.xml index 0950cce..238757c 100644 --- a/man/localectl.xml +++ b/man/localectl.xml @@ -265,6 +265,10 @@ this to an empty string or the value literalcat/literal is equivalent to passing option--no-pager/option./para/listitem + termvarname$SYSTEMD_LESS/varname/term + listitemparavarname$SYSTEMD_LESS/varname overrides the + default options passed to literalless/literal + (literalFRSXMK/literal)./para/listitem /varlistentry /variablelist /refsect1 diff --git a/man/loginctl.xml b/man/loginctl.xml index 13105d4..ede869f 100644 --- a/man/loginctl.xml +++ b/man/loginctl.xml @@ -486,6 +486,10 @@ this to an empty string or the value literalcat/literal is equivalent to passing option--no-pager/option./para/listitem + termvarname$SYSTEMD_LESS/varname/term + listitemparavarname$SYSTEMD_LESS/varname overrides the + default options passed to literalless/literal + (literalFRSXMK/literal)./para/listitem /varlistentry /variablelist /refsect1 diff --git a/man/machinectl.xml b/man/machinectl.xml index 6e991ee..1f272a8 100644 --- a/man/machinectl.xml +++ b/man/machinectl.xml @@ -299,6 +299,10 @@ this to an empty string or the value literalcat/literal is equivalent to passing option--no-pager/option./para/listitem + termvarname$SYSTEMD_LESS/varname/term + listitemparavarname$SYSTEMD_LESS/varname overrides the + default options passed to literalless/literal + (literalFRSXMK/literal)./para/listitem /varlistentry /variablelist /refsect1 diff --git a/man/systemctl.xml b/man/systemctl.xml index ed1bf48..1b0f8e5 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -1479,6 +1479,10 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service equivalent to passing option--no-pager/option./para /listitem + termvarname$SYSTEMD_LESS/varname/term + listitemparavarname$SYSTEMD_LESS/varname overrides the + default options passed to literalless/literal + (literalFRSXMK/literal)./para/listitem /varlistentry /variablelist /refsect1 diff --git a/man/systemd-analyze.xml b/man/systemd-analyze.xml index cbf59e0..54479e4 100644 --- a/man/systemd-analyze.xml +++ b/man/systemd-analyze.xml @@ -335,6 +335,10 @@ $ eog targets.svg/programlisting equivalent to passing option--no-pager/option./para /listitem + termvarname$SYSTEMD_LESS/varname/term + listitemparavarname$SYSTEMD_LESS/varname overrides the + default options passed to literalless/literal + (literalFRSXMK/literal)./para/listitem /varlistentry /variablelist /refsect1 diff --git a/man/timedatectl.xml b/man/timedatectl.xml index
[systemd-devel] [PATCH] pager: remove --no-init setting from LESS options
I use konsole. It has a nice feature that when the scrollbars have been
disabled -- like in the case of a full-console app like vim or less --
it makes the mouse wheel send up and down key strokes, so that
scrolling happens. It's really nice. I open up less, and then I can
scroll through it using the mouse wheel.
This doesn't work with systemd's pager, however, because systemd passes
--no-init to less. This patch removes this X flag.
---
src/shared/pager.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/shared/pager.c b/src/shared/pager.c
index 72a29f2..2155713 100644
--- a/src/shared/pager.c
+++ b/src/shared/pager.c
@@ -89,9 +89,9 @@ int pager_open(bool jump_to_end) {
close_pipe(fd);
if (jump_to_end)
-setenv(LESS, FRSXMK+G, 1);
+setenv(LESS, FRSMK+G, 1);
else
-setenv(LESS, FRSXMK, 1);
+setenv(LESS, FRSMK, 1);
/* Make sure the pager goes away when the parent dies */
if (prctl(PR_SET_PDEATHSIG, SIGTERM) 0)
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Future of Polkit XML with kdbus
Hi folks, Forgive me in advance if the underlying reasonings behind these questions are a bit naive... Will kdbus make use of polkit? If partially so, will it be feasible to have a normal desktop system with systemd+kdbus that does not require polkit? Will polkit play a smaller role going forward? Will it be phased out in any way? Perhaps tangentially related: will kdbus make use of dbus's current xml definition files? Will all that xml somehow be a part of future dbus situations? More generally: can all the not-so-nice stuff go away with the kdbus? Again, sorry for these ridiculous questions. I wish I could ask something more direct. Thanks, Jason ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] assigning one udev attr to another
I'd like to have a rule that does this:
zx2c4@thinkpad /etc/udev/rules.d $ cat 90-hotkeys.rules
DRIVER==thinkpad_acpi, ATTR{hotkey_mask}=ATTR{hotkey_recommended_mask}
Unfortunately, it doesn't work.
This works:
zx2c4@thinkpad /etc/udev/rules.d $ cat 90-hotkeys.rules
DRIVER==thinkpad_acpi, ATTR{hotkey_mask}=123
But assigning one to another does not.
Any advice?
Thanks,
Jason
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] assigning one udev attr to another
Perfect, thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
