[systemd-devel] systemd dns smart?
I was just 'cleaning up' a bit an ubuntu server from unnecessary running processes. I think I removed also some things from systemd. Now I have that some external auth that is slow due to the fact that the external auth host has two ip addresses configured. One of those ip addresses is not reachable from my ubuntu server. This results in the default behaviour that when you do a few pings some are not replying because the ping is using the unreachable ip address. I don't think I noticed this behaviour before, my question is now. Is there something 'smart' in systemd that automatically prefers to use the ip address that is routable?
Re: [systemd-devel] systemd-resolve and name servers order
> > I hope this is the right mailing list to ask that kind of question. I'm > following what is recommended on github issue tracker: > https://github.com/systemd/systemd/issues/new/choose > If it's not - feel free to point me to a different place. > > I use azure ubuntu 20.04 build with nameservers obtained by DHCP (there > are three custom nameservers assigned to Azure private Vnet and they are > owned by my company). > These three nameservers are not equal. So the first server provides > different answers than the second and the third server. I think this is not how resolv.conf was designed to be used. Are you 100% sure this is the only way to solve your issue? Having 3 different nameservers reporting different results? Can't you do something with views and sorting? What about just giving your server 3 different ip's and configure the nameservers with specific views for that?
Re: [systemd-devel] systemd-resolve and name servers order
> In the past prior to systemd-resolve as a default solution the order I > think was followed. From what I understand windows > https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows- > server-2008-R2-and-2008/dd197552(v=ws.10) > prefers first server on the list (it doesn't prefer secondary over > tertiary but first one is preferred) so people got used to it. Now > systemd-resolve doesn't seem to care about the order. Formally that > might be a correct approach but this is a change to what we used to have > in the past. So I think having possibility to follow the order would be > something nice to have. I also do not really get sometimes the design changes. I am having different orders in resolv.conf to spread the load over nameservers. So having this done automatically is sort of nice and better. I do not think there will be much support this use case. I think you can only extend this situation a bit, but at some point you need to rethink this architecture. I am here to complain about logging, systemd duplicates the required iops in certain cases (can't even remember exactly). Now I am stuck with no reporting at all on services that start/stop. To be honest I am to busy with other things to familiarize myself with systemd and criticize things.
Re: [systemd-devel] systemd-resolve and name servers order
> > Obviously there are other solutions to the problem described above (eg > having multiple internal servers, although my experience was in the SOHO > environment where that would be excessive). If as Rafał says Windows > prioritises the first DNS option then I'm pretty sure that wasn't always > the case, but it's been well over a decade since I got out of Windows IT > support! For now I would think of disabling systemd resolving (uninstall systemd-resolved) and maybe networkmanager, so you can have the resolv.conf back. I can also think of maybe doing something with dnsmasq, it is quite simple and maybe offers this.
[systemd-devel] problem understanding why I am 'forced' to run systemd-journald
Hello, I have started to upgrade a few machines from CentOS7 to recent versions of CentOS/Rocky. However I don't really get why there is a systemd-journald process writing stuff to disk while I have explicitly configured that logs should go to a remote syslog server. Reading such pages [1] does not really explain the design idea behind wanting to generated 2x the amount iops. One would think with all this environmental co2 global warming stuff, design would be aimed at being more efficient. 1. why do I need system-journald? 2. why is it not a service that can be disabled? 3. How can I make sure that none of the logs I have, are not having a duplicate somewhere? I have 'slower' distributed storage, so it is important to minimize the amount of useless io being generated. I was already complaining to Bill Gates, he should shut up about the environment. If he did not hire 'lazy' people and spend a few billion more on development we would have a lot less energy consumption, because windows is using quite a lot of resources compared to linux. Now upgrading, I have ~2x iops then before. Can anyone help me with my 3 questions?
Re: [systemd-devel] *****SPAM***** Re: problem understanding why I am 'forced' to run systemd-journald
I have seen that, but is that not something like 'accepting log entries and sending data to /dev/null'? I am looking for an option that does not process anything. > https://www.freedesktop.org/software/systemd/man/journald.conf.html#Stor > age= > > → volatile > > > > > > > Hello, > > > > I have started to upgrade a few machines from CentOS7 to recent > versions of CentOS/Rocky. However I don't really get why there is a > systemd-journald process writing stuff to disk while I have explicitly > configured that logs should go to a remote syslog server. > > > > Reading such pages [1] does not really explain the design idea behind > wanting to generated 2x the amount iops. One would think with all this > environmental co2 global warming stuff, design would be aimed at being > more efficient. > > > > 1. why do I need system-journald? > > > > 2. why is it not a service that can be disabled? > > > > 3. How can I make sure that none of the logs I have, are not having a > duplicate somewhere? > > > > I have 'slower' distributed storage, so it is important to minimize > the amount of useless io being generated. > > I was already complaining to Bill Gates, he should shut up about the > environment. If he did not hire 'lazy' people and spend a few billion > more on development we would have a lot less energy consumption, because > windows is using quite a lot of resources compared to linux. Now > upgrading, I have ~2x iops then before. > > > > Can anyone help me with my 3 questions?
[systemd-devel] still annoyed by the default behaviour of systemd-journald
I have been reading this old post[1] again, and am worried that developers are just doing something without thinking. (Don't whine about such statement, because that is quite common these days) I honestly do not get why my default setup is causing systemd-journald on a host to go 100% while I increase the logging of a container that logs remotely (via /dev/log) The only way to disable the waste of resources is to disable logging. But afaik then issues with starting services on the host are not reported as well. What kind of weird design is this? This makes me start to doubt the quality of logics applied in this design. Does anyone in your team even test on things like changes that cause twice the amount of iops? [1] https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg47844.html
RE: CVE-2023-7008 Christmas drama notes
> > Yet, I were accused to have abused something. I did not. But I would like to > thank Luca for removing me from systemd organization. Yes, none of my > proposed commits have been never been merged. I have received limited rights > to be able to mark selected issues with tags like downstream/rhel or > downstream/fedora, so those issues can be prioritized. In order to help > systemd team prioritize important fixed to systemd-resolved for RHEL, given > I possess higher DNS expertise than they do (my opinion without a proof). I > am glad I were removed. > A bit of topic. But I am also not to 'impressed' with the quality of 'senior engineers' at redhat. I am not to pleased that opensource projects that should adhere to open standards are bent to facilitate RedHat needs. I am super annoyed that dyndb for bind has been ruined. Now my reloads/restarts take minutes, because it starts downloading everything. The same I noticed with the csi driver for ceph. This is more a kubernetes driver than it has anything to do with csi. With systemd I have the impression that logging is now causing 2x the iops, and I have to disable logging to prevent it. But doing this, I don't have info on started daemon. It is like nobody is taking time to think things through any more.
[systemd-devel] (no subject)
stop putting this useless shit in dmesg out-of-date, rotating. [60542.641705] systemd-journald[493]: Data hash table of /run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal has a fill level at 75.0 (7568 of 10090 items, 5812224 file size, 768 bytes per hash table item), suggesting rotation. [60542.641724] systemd-journald[493]: /run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal: Journal header limits reached or header out-of-date, rotating. [64142.308221] systemd-journald[493]: Data hash table of /run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal has a fill level at 75.1 (7574 of 10090 items, 5812224 file size, 767 bytes per hash table item), suggesting rotation. [64142.308244] systemd-journald[493]: /run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal: Journal header limits reached or header out-of-date, rotating. [67622.472249] systemd-journald[493]: Data hash table of /run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal has a fill level at 75.0 (7568 of 10090 items, 5812224 file size, 768 bytes per hash table item), suggesting rotation. [67622.472273] systemd-journald[493]: /run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal: Journal header limits reached or header out-of-date, rotating. [71582.874668] systemd-journald[493]: Data hash table of /run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal has a fill level at 75.0 (7569 of 10090 items, 5812224 file size, 767 bytes per hash table item), suggesting rotation. [71582.874687] systemd-journald[493]: /run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal: Journal header limits reached or header out-of-date, rotating. [75362.841598] systemd-journald[493]: Data hash table of /run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal has a fill level at 75.0 (7569 of 10090 items, 5812224 file size, 767 bytes per hash table item), suggesting rotation. [75362.841613] systemd-journald[493]: /run/log/journal/8432ddf2a6da4319b318e6e27319f059/system.journal: Journal header limits reached or header out-of-date, rotating.
[systemd-devel] Thoughts about /etc/crypttab keyscript options
Hi, I was recently bitten by the issue that systemd does not support the keyscript= option in /etc/crypttab. I don't know whether keyscript= is a Debian extension, but the migration to systemd (which was pulled in by some new version of - I think - Network Manager) broke my system's boot process, leaving me with all my filesystems locked since already the root fs used to be unlocked by a keyscript. I have read the thread (from 2012?) where those things were discussed here and I understand that I should replace my keyscript with a passwort agent. Things would then work like this: (1) systemd would try to unlock the root file system and place a ask.xxx file in /run/systemd/ask-password (2) All running PasswordAgents (including my, non-interactive one and all interactive ones) would act on that ask.xxx file. (3) The interactive password agents would present an interactive password request. (4) My PasswordAgent indicates taking responsibility by unlinking the ask.xxx file from /run/systemd/ask-password. The interactive password agents will remove their interactive requests then. The user will therefore see the password request popping up for a very short period of time, if at all. (5) Should my PasswordAgent need a password to act itself (like a PIN for a hardware device, for example), it would place its own ask.xxx file in /run/systemd/ask-password. The interactive PasswordAgents would act on that, obtain the password/PIN interactively from the user and return it to my PasswordAgent. (6) My PasswordAgent would then obtain the password for the file system itself and return it to systemd which can now proceed to unlock the file system. Am I understanding things correctly so far? If so, this leaves the task to write my PasswordAgent. I have found some example code in python for a password agent. To use this to unlock the root fs, an entire python installation would need to go in my initramfs, right? And if I want to keep things simple, the best idea would be to write my PasswordAgent in a compiled language which would only need the binary and its libs in the initramfs, right? Is there code for an example PasswordAgent in C++ which I can use as a template? I am quite reluctant to write a program which needs to to complex string processing and is bound to run as root in C because my C experience is somewhat lacking. Can you please recommend a way to allow me to migrate to systemd? Without keyscript= being supported in /etc/crypttab, I need to replace my 50 line key script written in POSIX shell and would like to keep things simple. Thank you very much for your consideration. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
Hi, did I reach the wrong mailing list? Is there better forum to get systemd working with something resembling my current setup? Greetings Marc On Mon, Jul 21, 2014 at 10:46:21AM +0200, Marc Haber wrote: From: Marc Haber mh+systemd-de...@zugschlus.de Subject: Thoughts about /etc/crypttab keyscript options To: systemd-devel@lists.freedesktop.org Date: Mon, 21 Jul 2014 10:46:21 +0200 User-Agent: Mutt/1.5.21 (2010-09-15) Hi, I was recently bitten by the issue that systemd does not support the keyscript= option in /etc/crypttab. I don't know whether keyscript= is a Debian extension, but the migration to systemd (which was pulled in by some new version of - I think - Network Manager) broke my system's boot process, leaving me with all my filesystems locked since already the root fs used to be unlocked by a keyscript. I have read the thread (from 2012?) where those things were discussed here and I understand that I should replace my keyscript with a passwort agent. Things would then work like this: (1) systemd would try to unlock the root file system and place a ask.xxx file in /run/systemd/ask-password (2) All running PasswordAgents (including my, non-interactive one and all interactive ones) would act on that ask.xxx file. (3) The interactive password agents would present an interactive password request. (4) My PasswordAgent indicates taking responsibility by unlinking the ask.xxx file from /run/systemd/ask-password. The interactive password agents will remove their interactive requests then. The user will therefore see the password request popping up for a very short period of time, if at all. (5) Should my PasswordAgent need a password to act itself (like a PIN for a hardware device, for example), it would place its own ask.xxx file in /run/systemd/ask-password. The interactive PasswordAgents would act on that, obtain the password/PIN interactively from the user and return it to my PasswordAgent. (6) My PasswordAgent would then obtain the password for the file system itself and return it to systemd which can now proceed to unlock the file system. Am I understanding things correctly so far? If so, this leaves the task to write my PasswordAgent. I have found some example code in python for a password agent. To use this to unlock the root fs, an entire python installation would need to go in my initramfs, right? And if I want to keep things simple, the best idea would be to write my PasswordAgent in a compiled language which would only need the binary and its libs in the initramfs, right? Is there code for an example PasswordAgent in C++ which I can use as a template? I am quite reluctant to write a program which needs to to complex string processing and is bound to run as root in C because my C experience is somewhat lacking. Can you please recommend a way to allow me to migrate to systemd? Without keyscript= being supported in /etc/crypttab, I need to replace my 50 line key script written in POSIX shell and would like to keep things simple. Thank you very much for your consideration. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
On Wed, Aug 13, 2014 at 06:42:13PM +0200, Lennart Poettering wrote: On Wed, 13.08.14 16:43, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: did I reach the wrong mailing list? Is there better forum to get systemd working with something resembling my current setup? No, this is the right place. But I just have a huge backlog of threads to reply to on the ML. I am slowly working on catching up now, in preparation for a new release. Ok, I'll sit back quietly ;-) Maybe somebody else cares to comment? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
Hi Lennart, thanks for your thoughts. On Thu, Aug 14, 2014 at 07:44:59PM +0200, Lennart Poettering wrote: On Mon, 21.07.14 10:46, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: (4) My PasswordAgent indicates taking responsibility by unlinking the ask.xxx file from /run/systemd/ask-password. The interactive password Well, so far it is the querier that removes the file, not the agent... I see. What would happen if I remove the file myself? To use this to unlock the root fs, an entire python installation would need to go in my initramfs, right? And if I want to keep things simple, the best idea would be to write my PasswordAgent in a compiled language which would only need the binary and its libs in the initramfs, right? Yes. Correct. If you want to stick something into the initrd, I'd always do things in C (or shell if you must), but nothing else. Is there code for an example PasswordAgent in C++ which I can use as a template? I am quite reluctant to write a program which needs to to complex string processing and is bound to run as root in C because my C experience is somewhat lacking. Not aware of an C++ code. There's a vala one, and of course the one we ship in systemd itself in C, but c++ i cannot help you with, sorry. Is it possible to write a PasswordAgent in shell? Example code please ;) Can you please recommend a way to allow me to migrate to systemd? Without keyscript= being supported in /etc/crypttab, I need to replace my 50 line key script written in POSIX shell and would like to keep things simple. Thank you very much for your consideration. I fear I don#t have an easy suggestion. What kind of device do you actually want to make work here? some smartcard or so? That's the vision, yes. At the moment, my keyscript unlocks a small LUKS partition on the disk and takes the key for the root fs from there. That's just a placeholder for a future more complicated setup. With Debian's initramfs, unlocking the small LUKS partition works transparently even with plymouth. This is real functionality being lost in the systemd migration. I think in the long run we should somehow work towards the direction to make things like that just work, for common devices like smartcards and other auth tokens... First step to do that would be to implement support for the keyscript= option in /etc/crypttab as this is the canonical place to hook into on non-system systems. At least it's the case on Debian, I don't know about Red Hat, Fedora and other distributions. The PasswordAgent stuff is really neat, but complicated due to the socket communication, and it's far from being a drop-in replacement. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
Hi, On Thu, Aug 14, 2014 at 08:09:05PM +0200, David Herrmann wrote: That is, to solve your problem, I'd recommend to make systemd allow external scripts like keyscript= before placing *.ask files (or some other hookup or configuration, if scripts are not suitable for that). If systemd would support keyscript=, migration would be painless. I am absolutely in favor of that ;-) Greetings Marc, unfortunately too bad a C programmer to write a patch -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
On Thu, Aug 14, 2014 at 08:18:10PM +0200, Lennart Poettering wrote: On Thu, 14.08.14 20:10, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: Not aware of an C++ code. There's a vala one, and of course the one we ship in systemd itself in C, but c++ i cannot help you with, sorry. Is it possible to write a PasswordAgent in shell? Example code please ;) Probably possible, after all bash allows you to talk to unix sockets and stuff. And you could probably put the protocol together with carefully crafted echo lines, but I know of nobody who has done that so far... There is also the daemonizing and inotify part... I fear I don#t have an easy suggestion. What kind of device do you actually want to make work here? some smartcard or so? That's the vision, yes. At the moment, my keyscript unlocks a small LUKS partition on the disk and takes the key for the root fs from there. That's just a placeholder for a future more complicated setup. Not following. You place a key for a LUKS partition on another LUKS partition? What's the benefit of that? Inception? ;-) It's actually part of a two-factor-authentification for the poor. The part to know is the key to the LUKS parition, the part to have is an USB key. The key script hashes part of the key found on the USB key and part of the key found on the LUKS partition on the hard disk together to build the actual key to unlock the root fs. I use this scheme for so long that I don't even remember why I implemented it this way, but I guess it was because the logic to unlock a LUKS fs from initramfs was already in place and could be used as-is to unlock the key-part-holding LUKS partition instead of the actual root fs that it was intended for. But I also know of people who use a keyscript to unlock LUKS file systems with the key stored in the system's TPM or on a crypto card. I have never looked into the details of those implementations (having that saved for a long winter night), but I guess that those people will also be pretty hosed on a systemd-based Debian. First step to do that would be to implement support for the keyscript= option in /etc/crypttab as this is the canonical place to hook into on non-system systems. At least it's the case on Debian, I don't know about Red Hat, Fedora and other distributions. Well, I am really not convinced that this is a well-defined interface. Even in your case you have to wait for two devices at least, right? a synchronous shell callout won't solve that for you since there's no guarantee that the second LUKS device has already shown up, or am I missing something? It may be possible that /etc/crypttab is processed sequentially which would obviously not be the case with systemd. So you have a point here. As mentioned we really should redesign the whole thing around the kernel keyring anyway, I am really conservative in adding support for Debian's keyscript thingy upstream now. (That of course shouldn't stop Debian from adding this downstream) It didn't occur to me that /etc/crypttab's keyscript= option was a Debianism. I educated myself in the mean time. I'm going to yell at the Debian systemd team now ;-) The PasswordAgent stuff is really neat, but complicated due to the socket communication, and it's far from being a drop-in replacement. Well, it's really easy in C I figure, but admittedly not in shell... It would be significantly easier if there were boilerplate code to derive from. To a non-adept programmer, adapting the boilerplate would probably lead to enough buffer overflow vulnerabilities anyway ;-) Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
On Fri, Aug 15, 2014 at 01:30:32PM +0200, Lennart Poettering wrote: On Fri, 15.08.14 12:56, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: Is it possible to write a PasswordAgent in shell? Example code please ;) Probably possible, after all bash allows you to talk to unix sockets and stuff. And you could probably put the protocol together with carefully crafted echo lines, but I know of nobody who has done that so far... There is also the daemonizing and inotify part... I fear I don#t have an easy suggestion. What kind of device do you actually want to make work here? some smartcard or so? That's the vision, yes. At the moment, my keyscript unlocks a small LUKS partition on the disk and takes the key for the root fs from there. That's just a placeholder for a future more complicated setup. Not following. You place a key for a LUKS partition on another LUKS partition? What's the benefit of that? Inception? ;-) It's actually part of a two-factor-authentification for the poor. The part to know is the key to the LUKS parition, the part to have is an USB key. The part to have is trivially easy to copy, so why do the excercise at all? Sounds more like theatre to me... Because I still hope to have that in a more secure way in the near future. But I also know of people who use a keyscript to unlock LUKS file systems with the key stored in the system's TPM or on a crypto card. I have never looked into the details of those implementations (having that saved for a long winter night), but I guess that those people will also be pretty hosed on a systemd-based Debian. I think supporting TPM or smartcards out of the box is very desirable to have upstream. Yes, and that should be done in a modular way so that even exotic (or broken) schemes can be plugged in. I am not convinced though that Debian's keyscript= logic is really that well designed that I want to update it upstream. You don't need to. I falsely thought that this was general functionality and not a Debianism. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd and openvswitch?
Hi, is there any possibility to nicely integrate openvswitch to a system that runs systemd-networkd? While I understand that there does not currrently seem to be native openvswitch support in systemd-networkd, maybe somebody has written unit files to bring up the openvswitch before systemd-networkd kicks in? The reason I am trying to do this is that openvswitch is advertised as being capable to switch an entire dot1q VLAN trunk through to a VM, something that a standard Linux bridge doesn't seem to do. Any comments about this? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd and openvswitch?
Hi Richard, thanks for your insights. In the mean time, I was successful in bridging an VLAN trunk to a VM with the native linux bridge, and thus do not need Openvswich in my project any more. Your mail will be helpful to others in the future. ftr, one needs to define the VLANs on the hosts as well, and the VLAN definition needs to be on the _bridge_, not the ethernet. I guess that the Linux bridge code uses the VLANs defined on the bridge as kind of VLAN filter for the poor. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
On Tue, Jul 21, 2015 at 09:42:38PM +0200, Michael Biebl wrote: Have a look at the openvpn package in Debian. It implements something like you have in mind. There are multiple openvpn@.service instances and a single openvpn.service which can be used by the admin to start/stop/restart them. That uses a generator, which is somewhat oversized for the question at hand. And it's a service with ExecStart=/bin/true which is a hackish workaround. But if that's the way to go, I'm fine with it. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
On Tue, Jul 21, 2015 at 02:20:39PM +0100, Dimitri John Ledkov wrote: And then people can do e.g.: systemctl enable nifty@4.service nifty@6.service systemctl start nifty@*.service systemctl stop nifty@*.service As I mentioned in my original mail, this is explictly not wanted, as most users will have to start and stop both instances together. We cannot make our lives simpler at the cost of our users. And yes, this is true for both systemd upstream and software packagers, a transitive relationship. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, Jun 09, 2015 at 01:02:43PM +0200, Lennart Poettering wrote: On Mon, 01.06.15 22:43, Michael Biebl (mbi...@gmail.com) wrote: 2015-06-01 20:12 GMT+02:00 David Herrmann dh.herrm...@gmail.com: Hi As of today we've disabled git-push to fd.o. The official development git repository is now at github [1]. What about the bug tracker? Will it remain at fdo's bugzilla. I have to admit I'm not a huge fan of github's bug tracker. I am not a fan of bz either... I think for now we prefer github, but will leave bz open, and we will not migrate bugs. As it looks at the moment, freedesktop.org doesnt want new bugs to be filed in their Bugzilla. At least it is no longer possible to open new bugzilla requests for systemd there. Would you prefer bugzilla requests to be moved over to github issues by people interested in those requests/issues being addressed, or do old bugzilla requests have the same chance of being looked at by somebody able to address them as github issues? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to properly write an umbrella unit
Hi, I am trying to systemd'ize a daemon which is useful to be run in two instances. It is usually the case that both instances need to be started and stopped simultaneously, and the local admin would want a _single_ command to start and stop both instances. Therefore, an umbrella is needed. As a beginner, I have written: nifty.target: [Unit] Description=nifty Server (all protocols) After=network.target [Install] WantedBy=multi-user.target nifty-v4.service: [Unit] Description=nifty Server for IPv4 (niftyd4.conf) After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -4 -q -cf /etc/nifty/niftyd4.conf [Install] WantedBy=nifty.target nifty-v6.service: [Unit] Description=nifty Server for IPv6 After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -6 -q -cf /etc/nifty/niftyd6.conf [Install] WantedBy=nifty.target This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. Can I write my nifty.target as a service? I have seen in this case nifty.service files with Exec=/bin/true to basically create a no-op service, but that's ugly. If I move my service to a nifty@.service, how would I start two instances from a single shell command? How would one handle this situation in the clear, recommended way? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
On Tue, Jul 21, 2015 at 01:40:31PM +0100, Colin Guthrie wrote: In this case, I'd perhaps recommend NOT including [Install] sections fir your two .service files and instead make your make install action write symlinks into /usr/lib/systemd/system/nifty.target.wants.d/ thus the user could never disable the individual components of your daemon themselves and thus not need to rely on distro scripts to create them at install time. No, I'd like to give the local admin an option to disable parts of course. My work is about choice and robustness. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an umbrella unit
Hi Alexandre, thanks for your fast answer and correctly guessing my Distribution ,-) On Tue, Jul 21, 2015 at 02:13:12PM +0200, Alexandre Detiste wrote: Le mardi 21 juillet 2015, 13:43:48 Marc Haber a écrit : This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. Hi, Package-provided targets works well, but by default debhelper will try to enable everything. In my case, dh_systemd_enable doesn't install the file: dh_systemd_enable --verbose -pisc-dhcp-server --name=isc-dhcp-server.target echo # Automatically added by dh_systemd_enable debian/isc-dhcp-server.postinst.debhelper sed s/#UNITFILE#/isc-dhcp-server-v6.service/ /usr/share/debhelper/autoscripts/postinst-systemd-enable debian/isc-dhcp-server.postinst.debhelper echo '# End automatically added section' debian/isc-dhcp-server.postinst.debhelper echo # Automatically added by dh_systemd_enable debian/isc-dhcp-server.postinst.debhelper sed s/#UNITFILE#/isc-dhcp-server-v4.service/ /usr/share/debhelper/autoscripts/postinst-systemd-enable debian/isc-dhcp-server.postinst.debhelper echo '# End automatically added section' debian/isc-dhcp-server.postinst.debhelper echo # Automatically added by dh_systemd_enable debian/isc-dhcp-server.postinst.debhelper sed s/#UNITFILE#/isc-dhcp-server-v4-old.service/ /usr/share/debhelper/autoscripts/postinst-systemd-enable debian/isc-dhcp-server.postinst.debhelper echo '# End automatically added section' debian/isc-dhcp-server.postinst.debhelper echo # Automatically added by dh_systemd_enable debian/isc-dhcp-server.postrm.debhelper.new sed s/#UNITFILES#/isc-dhcp-server-v6.service isc-dhcp-server-v4.service isc-dhcp-server-v4-old.service/ /usr/share/debhelper/autoscripts/postrm-systemd debian/isc-dhcp-server.postrm.debhelper.new echo '# End automatically added section' debian/isc-dhcp-server.postrm.debhelper.new cat debian/isc-dhcp-server.postrm.debhelper debian/isc-dhcp-server.postrm.debhelper.new mv debian/isc-dhcp-server.postrm.debhelper.new debian/isc-dhcp-server.postrm.debhelper (grep -s -v misc:Depends debian/isc-dhcp-server.substvars; echo misc:Depends=debconf (= 0.5) | debconf-2.0, init-system-helpers (= 1.18~)) debian/isc-dhcp-server.substvars.new mv debian/isc-dhcp-server.substvars.new debian/isc-dhcp-server.substvars dh_installinit -Nisc-dhcp-server install -d debian/isc-dhcp-relay/etc/init.d install -p -m755 debian/isc-dhcp-relay.init.d debian/isc-dhcp-relay/etc/init.d/isc-dhcp-relay echo # Automatically added by dh_installinit debian/isc-dhcp-relay.postinst.debhelper sed s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit \$?/ /usr/share/debhelper/autoscripts/postinst-init debian/isc-dhcp-relay.postinst.debhelper echo '# End automatically added section' debian/isc-dhcp-relay.postinst.debhelper echo # Automatically added by dh_installinit debian/isc-dhcp-relay.prerm.debhelper sed s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit \$?/ /usr/share/debhelper/autoscripts/prerm-init debian/isc-dhcp-relay.prerm.debhelper echo '# End automatically added section' debian/isc-dhcp-relay.prerm.debhelper echo # Automatically added by dh_installinit debian/isc-dhcp-relay.postrm.debhelper.new sed s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit \$?/ /usr/share/debhelper/autoscripts/postrm-init debian/isc-dhcp-relay.postrm.debhelper.new echo '# End automatically added section' debian/isc-dhcp-relay.postrm.debhelper.new cat debian/isc-dhcp-relay.postrm.debhelper debian/isc-dhcp-relay.postrm.debhelper.new mv debian/isc-dhcp-relay.postrm.debhelper.new debian/isc-dhcp-relay.postrm.debhelper dh_installinit -pisc-dhcp-server --error-handler=true #dh_systemd_start isc-dhcp-server.target and dh_systemd_enable's code specialcasing service, socket, and tmpfile, but not target, gave me the impression that target files are unsupported. My debian/rules is: override_dh_installinit: dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-server-v4 dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-server-v4-old dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-server-v6 dh_systemd_enable --verbose -pisc-dhcp-server --name=isc-dhcp-server.target dh_installinit -Nisc-dhcp-server dh_installinit -pisc-dhcp-server --error-handler=true what is wrong here? (if this is off-topic in systemd-devel, which I suspect, please feel free to reply in private mail instead). Greetings Marc -- - Marc Haber | I don't trust Computers
[systemd-devel] Policy Routing on a machine using systemd-networkd
Hi, I would like to do policy routing on a router with ~ 10 interfaces running Debian Linux and systemd. Networking is managed with ferm and systemd-networkd. I now need Policy Routing. What is the recommended way to handle the usual knot of iptables, ip rule and ip route statement in a clear and beautiful way in a systemd environment? As far as I know, systemd-network has not yet implemented policy routing, so the canonical way (for me, as a systemd newbie) to implement this would be a sysv init script containing the needed commands. What would be the "correct" way to do this in a systemd setup? Actually, I need something that does the following: o prevent a default route from being present in the main table (either by preventing it from being set in the first place or removing it idempotently) o Establish a number of iptables rules to set fwmarks o Establish a number of extra routing tables with a set of rules o Establish a number of ip rule rules regarding source IP ranges or fwmarks. How would I do that in systemd? Am I doing ok with a Type=oneshot service unit with a bunch of ExecStart Options? Or is there another recommended way? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On Mon, Dec 21, 2015 at 11:14:43PM +0100, Kai Krakow wrote: > I cannot see anything here in the thread which would disallow continue > using non-systemd installations. The problem is that many concepts of systemd are really nice. Once wants to have things like that. The problem is that a minoriy of concepts and the attitude of the makers make working with systemd a constant source of increased blood pressure and a strong urge to break something expensive just to get rid of the aggression. -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On Mon, Dec 21, 2015 at 10:18:05PM +0100, Kai Krakow wrote: > Thus: Please maintainers and developers, remove it. Do not let Lennart > remove this useful option to force others into removing your shitty > cruft. This is exactly why systemd is the top one most hated piece of open source software. We are not here to be educated about the one and only right way of doing things. Unix used to be about choice. Too bad that we allowed this to be no longer the case. Linux is no longer about choice. Linux nowadays is about what the systemd people want. Too bad that we gave the systemd people the power of forcing us to run our systems their way. Man kann manchmal echt nicht genug essen wie man in dieser Welt kotzen möchte. Merry Christmas. -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On Sun, Dec 20, 2015 at 02:34:15PM +0100, Tomasz Torcz wrote: > On Sun, Dec 20, 2015 at 02:30:30PM +0100, Marc Haber wrote: > > On Fri, Dec 18, 2015 at 05:00:32PM +0100, Michael Biebl wrote: > > > and then tell admin to use systemctl edit > > > [Unit] > > > Environment=OPTS=-baz > > > > How would I do the equivalent of systemctl edit with a declarative > > configuration management tool like puppet? > > You have to make sure directory /etc/systemd/system/nfs-ganesha.service.d/ > exists, then inside you create something.conf file with above content. Is that the documented interface equivalent to systemctl edit? Does the stability promise apply? > Afterwards you need to issue "systemctl daemon-reload" (or send signal > to PID1) to have the changes read. That's a regression over the old-fashioned way, but doable. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On Fri, Dec 18, 2015 at 05:00:32PM +0100, Michael Biebl wrote: > and then tell admin to use systemctl edit > [Unit] > Environment=OPTS=-baz How would I do the equivalent of systemctl edit with a declarative configuration management tool like puppet? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Policy Routing on a machine using systemd-networkd
*nudge* Is there really no option about this rather common issue? Greetings Marc On Tue, Dec 15, 2015 at 01:20:34PM +0100, Marc Haber wrote: > I would like to do policy routing on a router with ~ 10 interfaces > running Debian Linux and systemd. Networking is managed with ferm and > systemd-networkd. > > I now need Policy Routing. What is the recommended way to handle the > usual knot of iptables, ip rule and ip route statement in a clear and > beautiful way in a systemd environment? > > As far as I know, systemd-network has not yet implemented policy > routing, so the canonical way (for me, as a systemd newbie) to > implement this would be a sysv init script containing the needed > commands. > > What would be the "correct" way to do this in a systemd setup? > > Actually, I need something that does the following: > > o prevent a default route from being present in the main table (either > by preventing it from being set in the first place or removing it > idempotently) > o Establish a number of iptables rules to set fwmarks > o Establish a number of extra routing tables with a set of rules > o Establish a number of ip rule rules regarding source IP ranges or > fwmarks. > > How would I do that in systemd? Am I doing ok with a Type=oneshot > service unit with a bunch of ExecStart Options? Or is there another > recommended way? -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On Tue, Dec 15, 2015 at 05:59:11PM +, Simon Peeters wrote: > Why not do like normal people and use configmanagement to put the > right apache config on the right host? > This whole "-D testserver" and "" looks like an > ugly workaround for a lacking configmanagment system. And what is your business in deliberately breaking those ugly setups? If you want to educate people, be a teacher. If you want to bully people into doing things your way, be a team leader. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On Fri, Dec 11, 2015 at 03:59:54PM +0100, Reindl Harald wrote: > EnvironmentFile is a great way to make units flexible with sane > defaults and i am *not* talking about upstream or distributions here > > so taking away that option gains you nothing but breaks things for > no valid reason - it would only confirm people which hesitate to > adopt systemd because the fear that they can't rely on capabilities > it brings now because they may flippantly disappear Amen. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?
On Fri, Jan 20, 2017 at 02:51:00PM +, Patrick Schleizer wrote: > I've learned about the kernel parameter and symlink ways to disable > predictable network interface names. What would be the "symlink way"? Will predictable network names still play nice with the old udev way? I cannot make my brain remember that my notebook has enp0s25 and wlp3s0, and would like to have eth0 and wlan0 again (or net0 and net1, or wired0 and wless0, if it is a bad idea to move the interfaces back to the kernel namespaces), while keeping the advantage of having predictable network names for USB network interfaces that I regularly plug in as well. Will placing a /etc/udev/rules.d/70-persistent-network.rules that renames enp0s25 to wired0 and wlp3s0 to wless0 play nice, it is that asking for trouble? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?
On Mon, Feb 06, 2017 at 09:56:30PM +0100, Lennart Poettering wrote: > On Sat, 21.01.17 21:20, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: > > On Fri, Jan 20, 2017 at 02:51:00PM +, Patrick Schleizer wrote: > > > I've learned about the kernel parameter and symlink ways to disable > > > predictable network interface names. > > > > What would be the "symlink way"? > > Linking the relevant .link file to /dev/null in /etc. What if there is no .link file and the Interfaces just come up as enp8s0 and wlp2s0 > However, if you pick your own names outside of the kernel's > namespaces, then all is good, and that's actually what we > recommend. (Though I'd do it by dropping in some .link files with the > right [Match] sections to make this happen, not bother with udev > rules, but either works) [2/5147]mh@swivel:~ $ cat /etc/systemd/network/lanc0.link [Match] MACAddress=f0:de:f1:b0:03:20 [Link] Name=lanc0 [3/5148]mh@swivel:~ $ ip --oneline link show | grep f0:de:f1:b0:03:20 2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000\link/ether f0:de:f1:b0:03:20 brd ff:ff:ff:ff:ff:ff [4/5149]mh@swivel:~ $ My ethernet is still enp0s25, what am I doing wrong? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing
On Sun, Nov 06, 2016 at 09:28:59AM +0300, Andrei Borzenkov wrote: > 1. The behavior that if filesystem from /etc/fstab fails to mount, boot > is stopped and administrator intervention is required existed long > before systemd. I have never seen this. > 2. Password is requested not by systemd, but by command that it starts > to present shell. Default is sulogin. You are free to override it with > anything you want, including /bin/sh. Again, sulogin was often default > in this case before systemd as well. Yes, that right. Before the systemd era, systems usually continued to boot in case (1) until they hit something hard and unmoving. systemd systems stop voluntarily. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing
On Sun, Sep 25, 2016 at 08:09:20PM -0400, Dave Reisner wrote: > Making bootup potentially interactive in this manner is strictly worse > than dumping you into emergency mode. At least with emergency mode, you > might be able to add dependencies to emergency.target such that, for > example, an sshd comes up and an admin can login to the remote box. Is there an example around for doing so? This looks way interesting. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing
On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote: > The emergency mode assumes console access, which requires physical access, > which is quiet difficult if the machine is remote. It does also assume knowledge of the root password, which is in enterprise environments not often the case. Enterprises usually have root passwords stowed away in a safe, behind a three-headed guard dog, requiring management approval, and > 2 eyes mechanisms, and usually have password-changing processes attached that touch other machines sharign the same root password as well (for example because the root password hash is stamped into the golden image). Many enterprise environments that I know have their processes geared in a way that the root password is not needed in daily operation. Login via ssh key, privilege escalation via sudo. systemd requiring the root password because some tertiary file system doesn't mount is a nuisance for those environments. Some sites have resorted to adding "nofail" to all fstab lines just to find themselves with the next issue since the initramfs of some distributions doesn't know this option yet. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?
Hi, On Mon, Feb 20, 2017 at 05:42:19PM +0100, Lennart Poettering wrote: > On Mon, 20.02.17 17:38, Lennart Poettering (lenn...@poettering.net) wrote: > > Consider naming the file 50-lanc0.link or so, so that it takes > > precedence over 99-default.link if that's shipped by your distro. If > > it isn't, please contact your downstream distro for help (see above). > > BTW, all of the above is documented in systemd.link(5). My > recommendation is always to check the documentation first. Just to put and end to this, with proper numbering things are just fine now. Having this part ot systemd working in lexical order was just a surprise, I didn't expect that. Btw, the word "link" is multiply used in IT, so one can expect people to think of the wrong meaning of the word if one uses it without more explanation. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to ensure a systemd unit waits for ntpd to sync before starting?
On Tue, Apr 02, 2019 at 12:32:58PM +0200, Lennart Poettering wrote: > I thought people have noticed by now that systemd is really about > removing unnecessary shell scripts from all clean system boot > codepaths. The problem is that millions of professional systems administrators do violently disagree. I have seen unit files full of bash -c and quoting hell. Your work. Be proud of it. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to ensure a systemd unit waits for ntpd to sync before starting?
On Tue, Apr 02, 2019 at 10:17:26AM +0200, Lennart Poettering wrote: > Well packaged NTP servers should have a separate .service unit that > waits until an NTP sync is reached. For example, systemd's own > systemd-timesyncd.service comes with a companion > systemd-time-wait-sync.service that does this. systemd-time-wait-sync.service invokes /lib/systemd/systemd-time-wait-sync do to the actual wait, which is an ELF binary. While this is a valid approach to do this, an interested used will now need to download the systemd souces, unpack them, search for the source for the binary just to find out what this service actually does. To adapt it to wait for something else, one needs to whack out a compiler. IMO, this is a classic case of "doing this scripted is way easier and more flexible". Please consider for the future. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] networkd - how to (partially) manage OpenVPN interfaces?
Hi, when I run an OpenVPN interface, OpenVPN manages the interface itself: It handles creation, destruction and assignment of the IP address. The IP address can be controlled by the remote site, so the OpenVPN daemon is kind of the only thing that can configured the Interface. I would, however, like systemd-resolved to ask DNS servers that are reachable over the VPN for certain domains, such as ka51.zugschlus.de. Dumping a tun0.network containing: [Match] Name=tun0 [Network] Domains=~ka51.zugschlus.de DNS=2a01:238:4071:3281::35:100 DNS=2a01:238:4071:328e::35:100 DHCP=no IPv6AcceptRA=no into /e/s/n doesn't work since that clears up the IP addresses that OpenVPN has correctly assigned. Can I have the advantages of systemd-resolved on an Interface that is not fully managed by systemd-networkd? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd - how to (partially) manage OpenVPN interfaces?
Hi Susant, On Wed, Sep 25, 2019 at 05:56:23PM +, Susant Sahani wrote: > On 22/09/19, 5:35 PM, "systemd-devel on behalf of Marc Haber" > mh+systemd-de...@zugschlus.de> wrote: > On Mon, Sep 16, 2019 at 12:54:23PM +0200, Marc Haber wrote: > > when I run an OpenVPN interface, OpenVPN manages the interface itself: > > It handles creation, destruction and assignment of the IP address. The > > IP address can be controlled by the remote site, so the OpenVPN daemon > > is kind of the only thing that can configured the Interface. > > > > I would, however, like systemd-resolved to ask DNS servers that are > > reachable over the VPN for certain domains, such as ka51.zugschlus.de. > > > > Dumping a tun0.network containing: > > [Match] > > Name=tun0 > > > > [Network] > > Domains=~ka51.zugschlus.de > > DNS=2a01:238:4071:3281::35:100 > > DNS=2a01:238:4071:328e::35:100 > > DHCP=no > > IPv6AcceptRA=no > > > > into /e/s/n doesn't work since that clears up the IP addresses that > > OpenVPN has correctly assigned. > > No hints? Is this behavior - maybe - a bug? > > Did you tried with KeepConfiguration=? That is not yet in the Man Page on my system. Is it alreay there in systemd 242? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd - how to (partially) manage OpenVPN interfaces?
On Thu, Sep 26, 2019 at 09:16:53AM +, Susant Sahani wrote: > On 26/09/19, 11:49 AM, "Marc Haber" wrote: > > > > Did you tried with KeepConfiguration=? > > That is not yet in the Man Page on my system. Is it alreay there in > systemd 242? > > This is in 243. I'll have to wait then. Thanks. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd - how to (partially) manage OpenVPN interfaces?
Hi, On Mon, Sep 16, 2019 at 12:54:23PM +0200, Marc Haber wrote: > when I run an OpenVPN interface, OpenVPN manages the interface itself: > It handles creation, destruction and assignment of the IP address. The > IP address can be controlled by the remote site, so the OpenVPN daemon > is kind of the only thing that can configured the Interface. > > I would, however, like systemd-resolved to ask DNS servers that are > reachable over the VPN for certain domains, such as ka51.zugschlus.de. > > Dumping a tun0.network containing: > [Match] > Name=tun0 > > [Network] > Domains=~ka51.zugschlus.de > DNS=2a01:238:4071:3281::35:100 > DNS=2a01:238:4071:328e::35:100 > DHCP=no > IPv6AcceptRA=no > > into /e/s/n doesn't work since that clears up the IP addresses that > OpenVPN has correctly assigned. No hints? Is this behavior - maybe - a bug? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unit dependencies for socket activated services
Hallo, when I want a normal service to be started only after the networks is ready, I put |[Unit] |After=network-online.target |Wants=network-online.target into the service unit. Now I have a socket activated service which I know won't properly start (but claim readiness) if started before the network is ready. Would I put those two lines into foo.service or foo.socket? Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] disable EDNS in systemd-resolved
On Fri, Dec 27, 2019 at 11:25:20AM +0200, Mantas Mikulėnas wrote: > On Fri, Dec 27, 2019 at 10:52 AM Marc Haber > wrote: > > how would I disable EDNS in systemd-resolved? Some recursive DNS servers > > (for example in public hotspots) choke on queries with EDNS options. > > > > I don't think there is a configuration option, but resolved *should* > automatically detect lack of EDNS support (grep the system log for > "feature"). Do the queries simply time out, or do they get rejected? > > Make sure you don't have DNSSEC support set to "yes", since it depends on > EDNS. The DNS recursor of the Hotsplots network that I will use in the next three days just returns an authoritative NXDOMAIN. Yes, that's broken. I still need my system to handle the situation. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] disable EDNS in systemd-resolved
Hi, how would I disable EDNS in systemd-resolved? Some recursive DNS servers (for example in public hotspots) choke on queries with EDNS options. I didn't find anything about this in the systemd-resolved or resolvectl manual pages for systemd 244. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Networkd - how to augment an already configured interface
Hi, for a rather complex tunneling setup on a system that uses systemd-networkd and OpenVPN, I am trying to use networkd to augment the Interface that has been configured by OpenVPN. In OpenVPN, a daemon is started with a service unit, which connects to a remote side and creates a tunX interface and configures it according to what the other side says. The other side can push basic configuration like IP address and routes that go into the main routing table, but I need a RoutingPolicyRule and addiitonal Routes pushed into the configuration. I tried writing the following tunX.network unit: [Match] Name=tun1 [Network] Description=tun1 tunnel to old torres DHCP=no IPForward=yes IPv6AcceptRA=no [Route] Destination=0::/0 Gateway=2a01:238:4071:3202::1 Table=202 [RoutingPolicyRule] Priority=32100 From=2a01:238:4071:3280::/59 Table=202 [RoutingPolicyRule] Priority=32101 From=2a01:238:4071:32b0::/62 Table=202 but it looks like networkd wants full control over the network interface and flushes the IP addresses from the working interface, leaving it in a non-functional state. Is there any way to (a) tell networkd to just add the configuration from the unit to the already interface without cleaning up first, or (b) to have part of systemd just execute a single .network unit, probably as a sidekick unit that I can use to add configuration to my OpenVPN configuration? Or am I better off by just taking things away from systemd-networkd completely and use an "up" script from the OpenVPN configuration? Hoping for your opinions and a good discussion, cheers, Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Networkd - how to augment an already configured interface
On Thu, Mar 12, 2020 at 06:24:48PM +, Susant Sahani wrote: > https://www.freedesktop.org/software/systemd/man/systemd.network.html#KeepConfiguration= Stupid me, I forgot that I already had this issue back last year. And I still don't have a later systemd. Please forget that I asked. Greetings Ma "this is now documented" rc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd router advertisement handling
Hello, I recently stumbled across the following section in the systemd-networkd documentation for IPv6AcceptRA=: "Note that kernel's implementation of the IPv6 RA protocol is always disabled, regardless of this setting. [...]" What does this mean in practice? Is the kernel's IPv6 RA implementation disabled (by setting accept_ra=0?) when systemd-networkd is started? Does it affect all network interfaces or just the ones managed (configured) by systemd-networkd? When I run other services in parallel like dhcpcd, how does networkd affect them? When dhcpcd binds to dhcpv6 client port 546, systemd-networkd fails to bind in case of a O-flag in the RA, but are they also interfering with received RAs? Thanks in advance for giving some insights. Best regards, Marc pEpkey.asc Description: application/pgp-keys ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Are Pathnames in /tmp/systemd-private-foo predictable?
Hi, I am wondering where the 32 xdigit number in pathnames like systemd-private-27aa635a15cf4da0a7ebda10f25c3950-chrony.service-9DShFi/ comes from. I always had the impression that it's the systemd/dbus machine id, but that does not seem to be the case. Is that just an arbitrary random number, or can it be predicted in a way? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Are Pathnames in /tmp/systemd-private-foo predictable?
On Mon, Jun 14, 2021 at 09:59:24AM +0200, Lennart Poettering wrote: > It's the boot ID, i.e. /proc/sys/kernel/random/boot_id. We include it > in the name so that we can distinguish such dirs of the current boot > from those of earlier boots (which can be retained because of abnormal > shutdown or so). In the latter case we can safely remove them to avoid > collecting left-over directories. Thanks for the explanation, I appreciate that. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] manually lading kernel modules and have created /dev/* in container?
Man says: " The host system cannot be rebooted and kernel modules may not be loaded from within the container. " https://lists.freedesktop.org/archives/systemd-devel/2015-February/027805.html said: " We nowadays explicitly disallow non-auto loading of kernel modules from containers, for security reasons. If you want to allow kernel modules, then you can do so by adding the CAP_SYS_MODULE capability set to the set of caps to retain in nspawn, by using its --capability= switch. " insmod .ko module works, the problem is that /dev/dahdi appears on host, not within the container. Is there something simple I missed or do I need to switch to vkvm or such to run maybe 8y old opensuse on current kernel ? Marc Weber ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] manually lading kernel modules and have created /dev/* in container?
> devtmpfs thanks. So I can modprobe (-r) the modules from both host/container, eg dahdi_transcode makes /dev/dahdi/transcode appear. But when mounting from container I can write / read from it (getting errors about channels not setup which is probably expected), but I when trying same from the container I just get operation not permitted. chmod 777 or such doesn't help. I am not using UID/-U id rewriting in any way. I run the container with --capability=all. Is there something else I am missing ? Marc Weber ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Getting rid of the /run/credentials mount
On Fri, Aug 26, 2022 at 07:28:37AM +0200, Marc Haber wrote: > On Thu, Aug 25, 2022 at 11:37:12PM +0300, Topi Miettinen wrote: > > On 25.8.2022 22.42, Marc Haber wrote: > > > on the system and sends an alert if things change on the system. In the > > > Debian package, this is done from cron. I would like to move that to a > > > systemd timer and in passing use some of systemd's security features. > > > Here is my service: > > > > > > What do I do to disable the credentials mechanism in my service? > > > > You could use TemporaryFileSystem=/run together with a few BindPaths= for > > the required directories. For example, on my setup the user doesn't see all > > cruft in global /run: > > $ ls /run > > dbus/ firejail/ systemd/ udev/ user/ > > > > See also > > https://github.com/systemd/systemd/pull/21748 > > for some thoughts on tentative new directive PrivateRun= or something > > similar. > > My intention is the opposite. I want (and need!) my process to see what > is actually in /run. Nothing should be hidden away. The process itself > doesn't use anything in /run, but I want it to be able to detect changes. I filed an enhancement issue, https://github.com/systemd/systemd/issues/24508 Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[systemd-devel] Getting rid of the /run/credentials mount
Hi, the aide (https://github.com/aide/aide) tool builds checksums of files on the system and sends an alert if things change on the system. In the Debian package, this is done from cron. I would like to move that to a systemd timer and in passing use some of systemd's security features. Here is my service: [Unit] Description=dailyaide check StartLimitIntervalSec=7200 StartLimitBurst=1 [Service] Type=oneshot User=root Group=root Environment="CREDENTIALS_DIRECTORY=/nonexistent" ProtectSystem=strict ProtectClock=yes ProtectKernelModules=no ProtectKernelLogs=yes ProtectControlGroups=yes PrivateDevices=no ProtectKernelTunables=yes ProtectControlGroups=yes ProtectHome=read-only ReadWritePaths=/run/aide /var/lib/aide /var/log/aide /var/spool/exim4 /var/log/exim4 /var/tmp /tmp RestrictRealtime=yes RestrictSUIDSGID=yes PrivateTmp=no ExecStartPre-=/bin/umount /run/credentials ExecStart=/usr/local/sbin/dailyaidecheck --systemdservice You might see that I have tried some things to get rid of the mount of /run/credentials which allows an attacker to hide something in /run/credentials without aide being able to see it because it gets some temporary filesystem mounted over that path. Unfortunately, neither of those tricks have worked, and my /run/credentials/foo that I created before starting my service remains undetected. What do I do to disable the credentials mechanism in my service? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] Getting rid of the /run/credentials mount
On Thu, Aug 25, 2022 at 11:37:12PM +0300, Topi Miettinen wrote: > On 25.8.2022 22.42, Marc Haber wrote: > > on the system and sends an alert if things change on the system. In the > > Debian package, this is done from cron. I would like to move that to a > > systemd timer and in passing use some of systemd's security features. > > Here is my service: > > > > What do I do to disable the credentials mechanism in my service? > > You could use TemporaryFileSystem=/run together with a few BindPaths= for > the required directories. For example, on my setup the user doesn't see all > cruft in global /run: > $ ls /run > dbus/ firejail/ systemd/ udev/ user/ > > See also > https://github.com/systemd/systemd/pull/21748 > for some thoughts on tentative new directive PrivateRun= or something > similar. My intention is the opposite. I want (and need!) my process to see what is actually in /run. Nothing should be hidden away. The process itself doesn't use anything in /run, but I want it to be able to detect changes. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[systemd-devel] bind-mount of /run/systemd for chrooted bind9/named
Hi, this is a user-level question from someone who wants to make use of systemd but has not quite grown the gut feeling about which way is the right way to go. I am running bind 9 on more than a handful of systems providing name services as recursive and/or authoritative name servers. As it has ben recommended for two decades, I run bind in a chroot, using its own feature to chroot itself after starting up (-t /path/to/chroot). In Debian bookworm, the systemd units that come with Debian's bind9 package have recently changed from Type=simple to Type=notify. Combined with named -t, this means that systemd will never notice that the name daemon has correctly started up unless systemd's notify socket is also reachable in the chroot. This in turn means that bind is continuosly restarted by systemd. As a quick fix, I issue moiunt --bind /run/systemd /path/to/chroot/run/systemd manually. I am currently wondering which way is the preferred way to achive this in a more clean way: (1) go fully systemd That would mean to get rid of bind's -t option completely but use systemd's RootDirectory directive instead. I have not tried this but I think that the bind community might be reluctant to support a setup like that. In advantage, I could use the BindReadOnlyPaths directive to directly manage the necessary bind mount to make the notify socket accessible. (2) try to preserve the classic setup That would probably mean having a /etc/systemd/system/var-local-bind-run-systemd.mount with the contents: | [Mount] | What=/run/systemd | Where=/var/local/bind/run/systemd | Type=none | Options=bind | | [Install] | WantedBy=bind9.service and adding a RequiresMountsFor=/var/local/bind/run/systemd to the bind9.service. This works as intended when I start up bind9, but when stopping the name daemon, the bind mount still lingers around. I have not fully understood the necessary systemd magic to have var-local-bind-run-systemd.mount stopped whenever bind9.service stops. How would I do that? How would you solve this issue? Method (1), Method (2), or one that I didn't think of yet? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] Securing bind with systemd methods (was: bind-mount of /run/systemd for chrooted bind9/named)
On Tue, Jul 18, 2023 at 01:10:16AM +0300, Mantas Mikulėnas wrote: > On Mon, Jul 17, 2023, 15:44 Marc Haber > wrote: > > # /lib is necessary here, or execve will fail without indication for > > # reason - that was a surprise and hard to debug because even strace > > # didnt hint me towards the real issue > > ExecPaths=/usr/sbin/named /usr/sbin/rndc /lib > > > > This one in particular is not a systemd issue: I never claimed it to be. > All dynamically linked > binaries are executed through /lib/ld-linux*.so as their "interpreter". > (`file` will show the exact path.) I wish that had a dedicated errno, > though. That would be /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 on my system (only output of find /lib /usr/lib -name 'ld-lin*'), and adding that to ExecPaths doesnt allow my Executable to run. So it must be something else (possibly in addition). Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named
Hi Lennart, thanks for this helpful answer. On Tue, Jul 04, 2023 at 10:37:55AM +0200, Lennart Poettering wrote: > On Mo, 03.07.23 20:52, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: > > (1) go fully systemd > > That would mean to get rid of bind's -t option completely but use > > systemd's RootDirectory directive instead. I have not tried this but I > > think that the bind community might be reluctant to support a setup like > > that. In advantage, I could use the BindReadOnlyPaths directive to > > directly manage the necessary bind mount to make the notify socket > > accessible. > > I'd generally advise this, as it means you can drop caps like > CAP_SYS_ADMIN and so on right-away, i.e. all the stuff that chroot() > means. That would, however, mean to have the bind binary and all libraries in the chroot as well, which means either a lot of copying or a lot of bind mounting into the chroot, introducing a number of challenges regarding updates etc. Using bind's -t option is charming here because it just needs configuration, persistent data and a few auxillary files in the chroot. This has become harder nowadays since bind loads some libraries with dlopen() after the chroot, so at least those .so files need to be in the chroot. > You don't need to explicitly mount the notify socket if you use this > btw, systemd will do this for you automatically if you combined > RootDirectory= and Type=notify. That is nice to know. > > (2) try to preserve the classic setup > > That would probably mean having a > > /etc/systemd/system/var-local-bind-run-systemd.mount with the contents: > > | [Mount] > > | What=/run/systemd > > | Where=/var/local/bind/run/systemd > > | Type=none > > | Options=bind > > | > > | [Install] > > | WantedBy=bind9.service > > and adding a RequiresMountsFor=/var/local/bind/run/systemd to the > > bind9.service. > > It should suffice bind mounting just the notify socket, not the full > dir. Is it intended behavior that an empty file is left at the "mount point" (what Where= points to) after the unit was stopped? > You could also use a hybrid approach: let systemd bind mount this for > your service (and thus set up a minimal namespaced env for your > service, but with the root where it normally is), and then still let > bind do its own chroot() thing inside of it). I do not quite understand exactly what that means, how would I do that? What is "this" in the "mount this" part of sentence? > Generally speaking: its typically a better idea to rely on proper fs > mount namespacing (i.e. decoupling mount tables of services and host) > rather than plain chroot() (where they aren't decoupled). If bind only > does chroot(), then I think using systemd's namespacing is the much > better choice. Where would I read up on systemd namespacing? Are you refering to what is explained in the "Sandboxing" chapter of systemd.exec(5), like ProtectSystem, ReadWritePaths etc? So I would basically set ProtectSystem=strict ReadWritePaths=/var/local/chroot/bind/pathlist (all paths that bind needs to actually write to) and then finally ExecStart=/path/to/bind -f -t /var/local/chroot/bind ? Is that what you mean? If I set ProtectHome=yes, how do I give the user that bind runs as access to its homedir? Is ReadWritePaths= the solution? > > This works as intended when I start up bind9, but when stopping the name > > daemon, the bind mount still lingers around. I have not fully understood > > the necessary systemd magic to have var-local-bind-run-systemd.mount > > stopped whenever bind9.service stops. How would I do that? > > You can do Wants= from bind to the mount unit. And then do > StopWhenUnneeded= in the mount unit, to release it when not needed. StopWhenUnneeded was what I needed. So I currently have: [7/5031]mh@drop:~ $ sudo systemctl cat named # /lib/systemd/system/named.service [Unit] Description=BIND Domain Name Server Documentation=man:named(8) After=network.target Wants=nss-lookup.target Before=nss-lookup.target RequiresMountsFor=/var/local/chroot/bind/run/systemd [Service] Type=notify EnvironmentFile=-/etc/default/named ExecStart=/usr/sbin/named -f $OPTIONS ExecReload=/usr/sbin/rndc reload ExecStop=/usr/sbin/rndc stop Restart=on-failure [Install] WantedBy=multi-user.target Alias=bind9.service [8/5030]mh@drop:~ $ and 1 [9/5031]mh@drop:~ $ sudo systemctl cat var-local-chroot-bind-run-systemd.mount # /etc/systemd/system/var-local-chroot-bind-run-systemd.mount [Unit] StopWhenUnneeded=true [Mount] What=/run/systemd Where=/var/local/chroot/bind/run/systemd Type=none Options=bind [10/5032]mh@drop:~ $ (test system, I don't usually edit files in /lib/systemd, I know about the override mechanisms). Again, thanks for helping, that is highly ap
Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named
Hi Lennart,
On Mon, Jul 10, 2023 at 10:28:52AM +0200, Lennart Poettering wrote:
> On So, 09.07.23 20:14, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
>
> > > It should suffice bind mounting just the notify socket, not the full
> > > dir.
> >
> > Is it intended behavior that an empty file is left at the "mount point"
> > (what Where= points to) after the unit was stopped?
>
> We need an inode we can overmount, and given that this is in /run/
> (hence inherently ephemeral) and a fixed path it shouldn't matter.
So this is intended. Good to know. I stumbled upon that.
> > If I set ProtectHome=yes, how do I give the user that bind runs as
> > access to its homedir? Is ReadWritePaths= the solution?
>
> ProtectHome= is about /home/ only, i.e. regular ("human") users, not
> about system users (i.e. uid < 1K). Your bind should *not* run as
> regular user, but as a system user of course, hence ProtectHome= is
> something you can just set, and don't need to be concerned about the
> system user's home dir.
In Debian, bind runs as user bind, which gets created as a system user
(uid < 1K, yes), and with /var/cache/bind as its home directory, which
is the directory where, for example, slave zone files get written to.
So, the running process needs to be able to access its "home directory"
during its operation even after dropping root.
> > [Mount]
> > What=/run/systemd
> > Where=/var/local/chroot/bind/run/systemd
> > Type=none
> > Options=bind
>
> Note that /run/ should always be a tmpfs, hence unless you mount a
> tmpfs to /var/local/chroot/bind/run/ first, the above is a bit ugly.
>
> Instead of this .mount unit, consider using in the .service file:
>
> TemporaryFileSystem=/var/local/chroot/bind/run
> BindPaths=/run/systemd/notify:/var/local/chroot/bind/run/systemd/notify
Ah, of course. I obviously didn't read BindPath's documentation
thoroughly enough. That is of course way better. Thanks for helping me
to read the docs.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named
On Mon, Jul 10, 2023 at 12:11:01PM +0200, Lennart Poettering wrote: > ProtectHome= protects /home/, nothing else. Hence you can use it, and > it should not collide with bind's use of the home dir, because it's > not in /home. > > Actually, correcting myself: use ReadOnlyBindPaths= for this. clients > cann still connect to sockets on read-only fs just fine, but you take > the privs away to chmod() or chown() the inode that way. So you get > another line of defense that way. Thank you, all my questions are answered for the time being. Your help is appreciated. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[systemd-devel] Securing bind with systemd methods (was: bind-mount of /run/systemd for chrooted bind9/named)
o I had to template _that_ for my Banana Pi. SystemCallFilter=~@mount @swap @raw-ip @resources @reboot @privileged @obsolete @module @debug @cpu-emulation @clock SystemCallFilter=chroot setuid SystemCallArchitectures=native [Install] WantedBy=multi-user.target # strangely, this alias only holds if the unit is enabled. If the unit # is disabled, the alias is not available which was kind of a surprise. Alias=bind9.service Generally, the error messages I received during the debugging phase were not very helpful. I frequently had to resort to strace -p 1 to find out what exactly went wrong trying to start named. For example, there is no exact feedback when the daemon is being terminated because of a SystemCallFilter violation, I'd like the system call in question to be part of the log. The same applies to directives regarding sandboxing, when paths are given in the directive. My way to debug was either randomly removing some of the directives to narrow down the possible error range, or stracing again to find out what my daemon tried before it was terminated. Those things might be out of scope for systemd, I simply don't know. With this unit, systemd-analyze security named is now down to "1.9 OK", I think it was > 9 with the standard unit. Thanks for your help, I wanted to give something back. I'll probably suggest this unit for the Debian package once it has reached some stability. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named
On Mon, Jul 03, 2023 at 11:21:22PM +0200, Silvio Knizek wrote: > why is it suggested to run `named` within its own chroot? For security > reasons? This can be achieved much easier with systemd native options. That feature is two decades older than systemd, and name server operators are darn conservative. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: atop package
On Thu, Dec 14, 2023 at 11:10:14AM +0530, jai wrote: > *root@dummyhost:~# systemctl status atopacct.service● atopacct.service - > Atop process accounting daemon Loaded: loaded > (/lib/systemd/system/atopacct.service; enabled; vendor preset: enabled) > Active: failed (Result: protocol) since Thu 2023-12-14 12:10:00 WIB; 49s > ago Docs: man:atopacctd(8)Dec 14 12:10:00 smartpesantren2 systemd[1]: > Starting Atop process accounting daemon...Dec 14 12:10:00 smartpesantren2 > atopacctd[367437]: /run/pacct_shadow.d: File existsDec 14 12:10:00 > smartpesantren2 systemd[1]: atopacct.service: Can't open PID file > /run/atopacctd.pid (yet?) after start: No such file or directoryDec 14 > 12:10:00 smartpesantren2 systemd[1]: atopacct.service: Failed with result > 'protocol'.Dec 14 12:10:00 smartpesantren2 systemd[1]: Failed to start Atop > process accounting daemon.* This formatting is completely mangled, what are you doing there? > The systemctl status shows error that /run/atopacctd.pid is missing. > I executed "ln -s /run/atop.pid /run/atopacctd.pid" to create symlink of > atopacctd.pid from atop.pid and then restarted the atopacct.service which > fixed the problem. atop and atopacctd are different daemons that happen to come from the same package. Symlinking one pidfile to the other is like to cause other problems than the one you seem to "solve". > But is this the proper way to solve this issue? The proper way would be to ask the maintainers of the atop package you're using, and not to complain on the _development_ mailing list of a nearly unrelated upstream project. It would at least help if you mention the version of the package you're using. Greetings Marc P.S.: I happen to be the maintainer of the atop package in Debian, the distribution that Ubuntu uses as a technical base. The package you're using is likely to closely resemble what I built for Debian, but I never saw that kind of misbehavior. -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[systemd-devel] [PATCH] Don't use class in public headers
--- src/systemd/sd-login.h | 2 +- src/systemd/sd-resolve.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/systemd/sd-login.h b/src/systemd/sd-login.h index 87ebafb..c539dd8 100644 --- a/src/systemd/sd-login.h +++ b/src/systemd/sd-login.h @@ -178,7 +178,7 @@ int sd_seat_can_tty(const char *seat); int sd_seat_can_graphical(const char *seat); /* Return the class of machine */ -int sd_machine_get_class(const char *machine, char **class); +int sd_machine_get_class(const char *machine, char **clazz); /* Get all seats, store in *seats. Returns the number of seats. If * seats is NULL only returns number of seats. */ diff --git a/src/systemd/sd-resolve.h b/src/systemd/sd-resolve.h index 3c1d482..a02be7d 100644 --- a/src/systemd/sd-resolve.h +++ b/src/systemd/sd-resolve.h @@ -103,13 +103,13 @@ int sd_resolve_getnameinfo_done(sd_resolve_query* q, char **ret_host, char **ret * compatible with the ones of libc's res_query(3). The function returns a new * query object. When the query is completed you may retrieve the results using * sd_resolve_res_done(). */ -int sd_resolve_res_query(sd_resolve *resolve, sd_resolve_query **q, const char *dname, int class, int type); +int sd_resolve_res_query(sd_resolve *resolve, sd_resolve_query **q, const char *dname, int clazz, int type); /** Issue an resolver query on the specified session. The arguments are * compatible with the ones of libc's res_search(3). The function returns a new * query object. When the query is completed you may retrieve the results using * sd_resolve_res_done(). */ -int sd_resolve_res_search(sd_resolve *resolve, sd_resolve_query **q, const char *dname, int class, int type); +int sd_resolve_res_search(sd_resolve *resolve, sd_resolve_query **q, const char *dname, int clazz, int type); /** Retrieve the results of a preceding sd_resolve_res_query() or * resolve_res_search call. The query object q is destroyed by this -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fix in_addr_prefix_intersect for 32bits
shifting from a non fixed number of bits = to the size of the type
leads to weird results, handle the special case of 32 to fix it.
This was causing a test failure from test-socket-util:
Assertion 'in_addr_prefix_intersect(f, ua, apl, ub, bpl) == result' failed at
/var/tmp/paludis/build/sys-apps-systemd-scm/work/systemd-scm/src/test/test-socket-util.c:147,
function
test_in_addr_prefix_intersect_one(). Aborting.
Minimal reproducer:
paludisbuild@Lou /tmp $ cat test.c
static void test(unsigned m) {
unsigned nm = 0xUL (32-m);
printf(%u: %x\n, m, nm);
}
int main (void) {
test(1);
test(0);
return 0;
}
paludisbuild@Lou /tmp $ gcc -m32 -std=gnu99 test.c -o test32
paludisbuild@Lou /tmp $ ./test32
1: 8000
0:
paludisbuild@Lou /tmp $ gcc -std=gnu99 test.c -o test64
paludisbuild@Lou /tmp $ ./test64
1: 8000
0: 0
---
src/shared/socket-util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/shared/socket-util.c b/src/shared/socket-util.c
index f8c6795..6f49798 100644
--- a/src/shared/socket-util.c
+++ b/src/shared/socket-util.c
@@ -695,7 +695,7 @@ int in_addr_prefix_intersect(
uint32_t x, nm;
x = be32toh(a-in.s_addr ^ b-in.s_addr);
-nm = 0xUL (32 - m);
+nm = (m == 0) ? 0 : 0xUL (32 - m);
return (x nm) == 0;
}
--
2.0.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] test-compress-benchmark: silence warnings
and btw make it pass for 32bits where size_t != uint64_t
---
src/journal/test-compress-benchmark.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/journal/test-compress-benchmark.c
b/src/journal/test-compress-benchmark.c
index 0a23bd1..a346447 100644
--- a/src/journal/test-compress-benchmark.c
+++ b/src/journal/test-compress-benchmark.c
@@ -42,12 +42,12 @@ static char* make_buf(size_t count) {
static void test_compress_decompress(const char* label,
compress_t compress, decompress_t
decompress) {
-usec_t n, n2;
+usec_t n, n2 = 0;
float dt;
_cleanup_free_ char *text, *buf;
_cleanup_free_ void *buf2 = NULL;
-size_t buf2_allocated = 0;
+uint64_t buf2_allocated = 0;
size_t skipped = 0, compressed = 0, total = 0;
text = make_buf(MAX_SIZE);
@@ -57,7 +57,7 @@ static void test_compress_decompress(const char* label,
n = now(CLOCK_MONOTONIC);
for (size_t i = 1; i = MAX_SIZE; i += (i 2048 ? 1 : 217)) {
-size_t j = 0, k = 0;
+uint64_t j = 0, k = 0;
int r;
r = compress(text, i, buf, j);
@@ -72,7 +72,7 @@ static void test_compress_decompress(const char* label,
assert(j 0);
if (j = i)
-log_error(%s \compressed\ %zu - %zu, label, i, j);
+log_error(%s \compressed\ %zu - PRIu64, label,
i, j);
r = decompress(buf, j, buf2, buf2_allocated, k, 0);
assert(r == 0);
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] test-compress-benchmark: silence warnings
On 16 July 2014 10:30, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Wed, Jul 16, 2014 at 03:29:15AM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Jul 16, 2014 at 10:13:06AM +0900, Marc-Antoine Perennou wrote: and btw make it pass for 32bits where size_t != uint64_t Do they still make those? ;) Will apply. Actually please apply it yourself. Looks good. Zbyszek Don't have push access, so I'll let you apply when you have time. Marc-Antoine ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] cgroups: chown user slices
When creating the cgroup hierarchy for a user slice,
chown this slice to the user uid.
Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
---
src/shared/cgroup-label.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/shared/cgroup-label.c b/src/shared/cgroup-label.c
index 574a7be..1891c9a 100644
--- a/src/shared/cgroup-label.c
+++ b/src/shared/cgroup-label.c
@@ -41,6 +41,7 @@
int cg_create(const char *controller, const char *path) {
_cleanup_free_ char *fs = NULL;
+uid_t uid = (uid_t) -1;
int r;
r = cg_get_path_and_check(controller, path, NULL, fs);
@@ -59,6 +60,13 @@ int cg_create(const char *controller, const char *path) {
return -errno;
}
+r = cg_path_get_owner_uid(path, uid);
+if (r 0 r != -ENOENT)
+return r;
+
+if (uid != (uid_t) -1)
+chown(fs, uid, (gid_t) -1);
+
return 1;
}
--
1.8.3.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd[725]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
The patch I mailed a few hours ago about chowning cgroups solved this issue here. On 6 July 2013 05:57, Kok, Auke-jan H auke-jan.h@intel.com wrote: On Thu, Jul 4, 2013 at 6:30 PM, Kay Sievers k...@vrfy.org wrote: On Fri, Jul 5, 2013 at 2:35 AM, Cristian Rodríguez crrodrig...@opensuse.org wrote: Since systemd 205, Im getting this scary warning Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Starting user-1000.slice. Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Created slice user-1000.slice. Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Starting User Manager for 1000... Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Starting Session 1 of user crrodriguez. Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd-logind[423]: New session 1 of user crrodriguez. Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd-logind[423]: Linked /tmp/.X11-unix/X0 to /run/user/1000/X11-display. Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[1]: Started Session 1 of user crrodriguez. Jul 04 19:55:36 xps9000.cristianrodriguez.net systemd[725]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted We are just not there, systemd --user is not started at the moment, the cgroup sub-tree for the user's session is not accessible for the systemd --user process running under the user's uid. Nothing really to worry about, the message should be ignored for now, we will get there soon ... does the old method of manually starting user@.service at least still work? I haven't had any time to track the latest release yet... Auke ___ 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
[systemd-devel] [PATCH] build: allow specifying a custom pam session name
for distribution now wanting to use systemd-shared
Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
---
Makefile.am| 1 +
configure.ac | 10 ++
units/u...@.service.in | 2 +-
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index d013dfd..8030c5f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -4072,6 +4072,7 @@ substitutions = \
'|udevlibexecdir=$(udevlibexecdir)|' \
'|SUSHELL=$(SUSHELL)|' \
'|DEBUGTTY=$(DEBUGTTY)|' \
+ '|PAM_NAME=$(PAM_NAME)|' \
'|KILL=$(KILL)|' \
'|KMOD=$(KMOD)|' \
'|MKDIR_P=$(MKDIR_P)|' \
diff --git a/configure.ac b/configure.ac
index 759073a..c1d2dac 100644
--- a/configure.ac
+++ b/configure.ac
@@ -404,6 +404,15 @@ AC_SUBST(PAM_LIBS)
AM_CONDITIONAL([HAVE_PAM], [test x$have_pam != xno])
#
--
+AC_ARG_WITH([pam-name],
+AS_HELP_STRING([--with-pam-name=NAME],
+[Specify the PAM session name to set up a session as]),
+[PAM_NAME=$withval],
+[PAM_NAME=systemd-shared])
+
+AC_SUBST(PAM_NAME)
+
+#
--
AC_ARG_ENABLE([acl],
AS_HELP_STRING([--disable-acl],[Disable optional ACL support]),
[case ${enableval} in
@@ -1027,6 +1036,7 @@ AC_MSG_RESULT([
Installation Python: ${PYTHON_BINARY}
firmware path: ${FIRMWARE_PATH}
PAM modules dir: ${with_pamlibdir}
+PAM session name:${with_pam_name}
D-Bus policy dir:${with_dbuspolicydir}
D-Bus session dir: ${with_dbussessionservicedir}
D-Bus system dir:${with_dbussystemservicedir}
diff --git a/units/u...@.service.in b/units/u...@.service.in
index 8f9a3b3..ce53d31 100644
--- a/units/u...@.service.in
+++ b/units/u...@.service.in
@@ -11,7 +11,7 @@ After=systemd-user-sessions.service
[Service]
User=%I
-PAMName=systemd-shared
+PAMName=@PAM_NAME@
Type=notify
ExecStart=-@rootlibexecdir@/systemd --user
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket
--
1.8.3.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: allow specifying a custom pam session name
On 26 July 2013 01:10, Tom Gundersen t...@jklm.no wrote: On Fri, Jul 26, 2013 at 12:28 AM, Marc-Antoine Perennou marc-anto...@perennou.com wrote: for distribution now wanting to use systemd-shared Could you explain a bit more why this needs to be configurable? What's the usecase? Cheers, Tom Oh, there is obviously a typo, it should be not and not now. It will allow distribution to use their already available pam session, like login-local or such, for example. + I don't think systemd-shared is really an explicit name for a pam session ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kernel-install questions
On 26 September 2013 00:20, Tom Gundersen t...@jklm.no wrote: On Wed, Sep 25, 2013 at 4:37 PM, Kay Sievers k...@vrfy.org wrote: On Wed, Sep 25, 2013 at 3:35 PM, Tom Gundersen t...@jklm.no wrote: *) With /boot on fat, 'add' fails for me due to not being able to use cp --preserve. How is this meant to work (or was it just not tested on fat)? Dropping --preserve makes it work for me. Hmm, no problems here: # cp --preserve /etc/hostname /boot; echo $? 0 # rpm -q coreutils coreutils-8.21-11.fc19.x86_64 Hm, interesting. I'll figure out what's going wrong here. FYI, here it fails with my kernel compiled as standards user and kernel-install ran as root. If I first copy the ekrnel as root and then kernel-install my root-owned copy, it works. With the below kernel patch make install just works. It's on our TODO list for long, but we haven't done it so far. Ok. Good to know. Was there a reason for the different interface, or would you be open to adding compatibility with the kernel script? What would compat mean? A symlink to kernel-install from installkernel and checking argv[0]? Precisely. (I could of course just ship a shim script, but I'd rather not). We thought of letting the kernel Makefile look for kernel-install first and fall back to installkernel, but we haven't look into details so far. That would be fine for the future, but it would still be useful to make stuff just work with old kernel builds for doing bisects and stuff like that. -t ___ 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] tree-wide conversion from libdbus to libsystemd-bus
On 30 October 2013 11:48, Kay Sievers k...@vrfy.org wrote: On Wed, Oct 23, 2013 at 1:22 AM, Kay Sievers k...@vrfy.org wrote: [update] To avoid any duplication of work, here are the tools which still need conversion. Please reply to this mail, in case you decide to work on anything in that area. - timedatectl - systemd-logind - loginctl Peeters Simon: I'll take ... (probably loginctl afterwards) - localectl Kay will do that next - hostnamectl - pam_systemd Zbigniew: I'll do pam_systemd - systemctl - systemd ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel I have some work in progress for hostnamectl ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tree-wide conversion from libdbus to libsystemd-bus
On 31 October 2013 07:10, Kay Sievers k...@vrfy.org wrote: On Wed, Oct 30, 2013 at 5:36 AM, Marc-Antoine Perennou marc-anto...@perennou.com wrote: On 30 October 2013 11:48, Kay Sievers k...@vrfy.org wrote: On Wed, Oct 23, 2013 at 1:22 AM, Kay Sievers k...@vrfy.org wrote: [update] To avoid any duplication of work, here are the tools which still need conversion. Please reply to this mail, in case you decide to work on anything in that area. I have some work in progress for hostnamectl Simon Peeters sent this to the list, but you probably noticed that already. Thanks, Kay Yep, saw that. I'll do systemctl if noone else wants to. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tree-wide conversion from libdbus to libsystemd-bus
On Sunday, November 3, 2013, Daniel Mack wrote: On 10/30/2013 03:48 AM, Kay Sievers wrote: On Wed, Oct 23, 2013 at 1:22 AM, Kay Sievers k...@vrfy.orgjavascript:; wrote: [update] To avoid any duplication of work, here are the tools which still need conversion. Please reply to this mail, in case you decide to work on anything in that area. - timedatectl - systemd-logind - loginctl Peeters Simon: I'll take ... (probably loginctl afterwards) - localectl Kay will do that next - hostnamectl - pam_systemd Zbigniew: I'll do pam_systemd - systemctl I'll have a look at systemctl. Seems like a good way to get familiar with the new API. Might take me some days to finish it though. Daniel Yep, I've goy it nearly half finished by now, should be done by next week end. Marc-Antoine ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] bus: add sd_bus_message_end_of_container
Useful to check whether there are still things to read or not,
in order to be able not to allocate when not needed, when reading
arrays or such.
Will soon be used in systemctl
Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
---
src/libsystemd-bus/bus-message.c | 22 +++---
src/systemd/sd-bus.h | 1 +
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/src/libsystemd-bus/bus-message.c b/src/libsystemd-bus/bus-message.c
index 1050151..d683d70 100644
--- a/src/libsystemd-bus/bus-message.c
+++ b/src/libsystemd-bus/bus-message.c
@@ -1906,6 +1906,14 @@ int sd_bus_message_open_container(
return 0;
}
+int sd_bus_message_end_of_container(sd_bus_message *m) {
+struct bus_container *c;
+
+c = message_get_container(m);
+
+return !c-signature || c-signature[c-index] == 0;
+}
+
int sd_bus_message_close_container(sd_bus_message *m) {
struct bus_container *c;
@@ -2654,7 +2662,7 @@ int sd_bus_message_read_basic(sd_bus_message *m, char
type, void *p) {
c = message_get_container(m);
-if (!c-signature || c-signature[c-index] == 0)
+if (sd_bus_message_end_of_container(m))
return -ENXIO;
if (message_end_of_array(m, m-rindex))
@@ -2817,7 +2825,7 @@ static int bus_message_enter_array(
if (alignment 0)
return alignment;
-if (!c-signature || c-signature[c-index] == 0)
+if (sd_bus_message_end_of_container(m))
return 0;
if (c-signature[c-index] != SD_BUS_TYPE_ARRAY)
@@ -2870,7 +2878,7 @@ static int bus_message_enter_variant(
if (*contents == SD_BUS_TYPE_DICT_ENTRY_BEGIN)
return -EINVAL;
-if (!c-signature || c-signature[c-index] == 0)
+if (sd_bus_message_end_of_container(m))
return 0;
if (c-signature[c-index] != SD_BUS_TYPE_VARIANT)
@@ -2917,7 +2925,7 @@ static int bus_message_enter_struct(
if (!signature_is_valid(contents, false))
return -EINVAL;
-if (!c-signature || c-signature[c-index] == 0)
+if (sd_bus_message_end_of_container(m))
return 0;
l = strlen(contents);
@@ -2955,7 +2963,7 @@ static int bus_message_enter_dict_entry(
if (c-enclosing != SD_BUS_TYPE_ARRAY)
return -ENXIO;
-if (!c-signature || c-signature[c-index] == 0)
+if (sd_bus_message_end_of_container(m))
return 0;
l = strlen(contents);
@@ -3031,7 +3039,7 @@ int sd_bus_message_enter_container(sd_bus_message *m,
char type, const char *con
c = message_get_container(m);
-if (!c-signature || c-signature[c-index] == 0)
+if (sd_bus_message_end_of_container(m))
return -ENXIO;
if (message_end_of_array(m, m-rindex))
@@ -3132,7 +3140,7 @@ int sd_bus_message_peek_type(sd_bus_message *m, char
*type, const char **content
c = message_get_container(m);
-if (!c-signature || c-signature[c-index] == 0)
+if (sd_bus_message_end_of_container(m))
goto eof;
if (message_end_of_array(m, m-rindex))
diff --git a/src/systemd/sd-bus.h b/src/systemd/sd-bus.h
index 1a1cce9..34bd663 100644
--- a/src/systemd/sd-bus.h
+++ b/src/systemd/sd-bus.h
@@ -200,6 +200,7 @@ int sd_bus_message_read_array(sd_bus_message *m, char type,
const void **ptr, si
int sd_bus_message_read_strv(sd_bus_message *m, char ***ptr);
int sd_bus_message_skip(sd_bus_message *m, const char *types);
int sd_bus_message_enter_container(sd_bus_message *m, char type, const char
*contents);
+int sd_bus_message_end_of_container(sd_bus_message *m);
int sd_bus_message_exit_container(sd_bus_message *m);
int sd_bus_message_peek_type(sd_bus_message *m, char *type, const char
**contents);
int sd_bus_message_verify_type(sd_bus_message *m, char type, const char
*contents);
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] analyze: split out bus util functions
They will soon be used in systemctl
Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
---
src/analyze/analyze.c | 80 +++
src/libsystemd-bus/bus-util.c | 46 +
src/libsystemd-bus/bus-util.h | 17 +
3 files changed, 67 insertions(+), 76 deletions(-)
diff --git a/src/analyze/analyze.c b/src/analyze/analyze.c
index e278a64..ecbba95 100644
--- a/src/analyze/analyze.c
+++ b/src/analyze/analyze.c
@@ -87,19 +87,6 @@ struct boot_times {
usec_t unitsload_finish_time;
};
-struct unit_info {
-const char *id;
-const char *description;
-const char *load_state;
-const char *active_state;
-const char *sub_state;
-const char *following;
-const char *unit_path;
-uint32_t job_id;
-const char *job_type;
-const char *job_path;
-};
-
struct unit_times {
char *name;
usec_t activating;
@@ -172,71 +159,12 @@ static void free_unit_times(struct unit_times *t,
unsigned n) {
free(t);
}
-static int bus_parse_unit_info(sd_bus_message *message, struct unit_info *u) {
-int r = 0;
-
-assert(message);
-assert(u);
-
-r = sd_bus_message_read(message, (ssouso), u-id,
- u-description,
- u-load_state,
- u-active_state,
- u-sub_state,
- u-following,
- u-unit_path,
- u-job_id,
- u-job_type,
- u-job_path);
-if (r 0) {
-log_error(Failed to parse message as unit_info.);
-return -EIO;
-}
-
-return r;
-}
-
-static int bus_get_unit_property_strv(sd_bus *bus, const char *unit_path,
const char *prop, char ***strv) {
-_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
-_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
-int r;
-const char *s;
-
-r = sd_bus_get_property(
-bus,
-org.freedesktop.systemd1,
-unit_path,
-org.freedesktop.systemd1.Unit,
-prop,
-error,
-reply,
-as);
-if (r 0) {
-log_error(Failed to get unit property: %s %s, prop,
bus_error_message(error, -r));
-return r;
-}
-
-r = sd_bus_message_enter_container(reply, SD_BUS_TYPE_ARRAY, s);
-if (r 0)
-return r;
-
-while ((r = sd_bus_message_read(reply, s, s)) 0) {
-r = strv_extend(strv, s);
-if (r 0) {
-log_oom();
-return r;
-}
-}
-
-return r;
-}
-
static int acquire_time_data(sd_bus *bus, struct unit_times **out) {
_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
int r, c = 0, n_units = 0;
struct unit_times *unit_times = NULL;
-struct unit_info u;
+struct unit_info u = {};
r = sd_bus_call_method(
bus,
@@ -256,7 +184,7 @@ static int acquire_time_data(sd_bus *bus, struct unit_times
**out) {
if (r 0)
goto fail;
-while ((r = bus_parse_unit_info(reply, u)) 0) {
+while ((r = bus_message_read_unit_info(reply, u)) 0) {
struct unit_times *t;
if (r 0)
@@ -1041,8 +969,8 @@ static int graph_one(sd_bus *bus, const struct unit_info
*u, char *patterns[]) {
static int dot(sd_bus *bus, char* patterns[]) {
_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+struct unit_info u = {};
int r;
-struct unit_info u;
r = sd_bus_call_method(
bus,
@@ -1064,7 +992,7 @@ static int dot(sd_bus *bus, char* patterns[]) {
printf(digraph systemd {\n);
-while ((r = bus_parse_unit_info(reply, u)) 0) {
+while ((r = bus_message_read_unit_info(reply, u)) 0) {
r = graph_one(bus, u, patterns);
if (r 0)
return r;
diff --git a/src/libsystemd-bus/bus-util.c b/src/libsystemd-bus/bus-util.c
index eec70ed..aa57677 100644
--- a/src/libsystemd-bus/bus-util.c
+++ b/src/libsystemd-bus/bus-util.c
@@ -952,3 +952,49 @@ int
[systemd-devel] [PATCH 1/3] bus: add sd_bus_message_read_strv
It will be useful to have that in the public API
Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
---
src/libsystemd-bus/bus-message.c | 15 +++
src/systemd/sd-bus.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/src/libsystemd-bus/bus-message.c b/src/libsystemd-bus/bus-message.c
index 7a4c65d..1050151 100644
--- a/src/libsystemd-bus/bus-message.c
+++ b/src/libsystemd-bus/bus-message.c
@@ -4510,6 +4510,21 @@ int bus_message_read_strv_extend(sd_bus_message *m, char
***l) {
return 0;
}
+int sd_bus_message_read_strv(sd_bus_message *m, char ***l) {
+char **strv = NULL;
+int r;
+
+assert(m);
+assert(l);
+
+r = bus_message_read_strv_extend(m, strv);
+if (r 0)
+return r;
+
+*l = strv;
+return 0;
+}
+
const char* bus_message_get_arg(sd_bus_message *m, unsigned i) {
int r;
const char *t = NULL;
diff --git a/src/systemd/sd-bus.h b/src/systemd/sd-bus.h
index e0a6041..1a1cce9 100644
--- a/src/systemd/sd-bus.h
+++ b/src/systemd/sd-bus.h
@@ -197,6 +197,7 @@ int sd_bus_message_copy(sd_bus_message *m, sd_bus_message
*source, int all);
int sd_bus_message_read(sd_bus_message *m, const char *types, ...);
int sd_bus_message_read_basic(sd_bus_message *m, char type, void *p);
int sd_bus_message_read_array(sd_bus_message *m, char type, const void **ptr,
size_t *size);
+int sd_bus_message_read_strv(sd_bus_message *m, char ***ptr);
int sd_bus_message_skip(sd_bus_message *m, const char *types);
int sd_bus_message_enter_container(sd_bus_message *m, char type, const char
*contents);
int sd_bus_message_exit_container(sd_bus_message *m);
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] bus: fix bus_print_property with strv
---
src/libsystemd-bus/bus-util.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/src/libsystemd-bus/bus-util.c b/src/libsystemd-bus/bus-util.c
index 3bb1fb7..93e79e9 100644
--- a/src/libsystemd-bus/bus-util.c
+++ b/src/libsystemd-bus/bus-util.c
@@ -545,33 +545,28 @@ int bus_print_property(const char *name, sd_bus_message
*property, bool all) {
case SD_BUS_TYPE_ARRAY:
if (streq(contents, s)) {
-bool space = false;
-char tp;
-const char *cnt;
+bool first = true;
+const char *str;
r = sd_bus_message_enter_container(property,
SD_BUS_TYPE_ARRAY, contents);
if (r 0)
return r;
-r = sd_bus_message_peek_type(property, tp, cnt);
+while((r = sd_bus_message_read_basic(property,
SD_BUS_TYPE_STRING, str)) 0) {
+if (first)
+printf(%s=, name);
+
+printf(%s%s, first ? : , str);
+
+first = false;
+}
if (r 0)
return r;
-if (all || cnt) {
-const char *str;
-
+if (first all)
printf(%s=, name);
-
-while((r = sd_bus_message_read_basic(property,
SD_BUS_TYPE_STRING, str)) = 0) {
-printf(%s%s, space ? : , str);
-
-space = true;
-}
-if (r 0)
-return r;
-
+if (!first || all)
puts();
-}
r = sd_bus_message_exit_container(property);
if (r 0)
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] bus: fix bus_message_read_strv
message_read_strv_extend returns 0 on success
---
src/libsystemd-bus/bus-message.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd-bus/bus-message.c b/src/libsystemd-bus/bus-message.c
index 698c7c4..f228b44 100644
--- a/src/libsystemd-bus/bus-message.c
+++ b/src/libsystemd-bus/bus-message.c
@@ -4420,7 +4420,7 @@ int sd_bus_message_read_strv(sd_bus_message *m, char
***l) {
assert_return(l, -EINVAL);
r = bus_message_read_strv_extend(m, strv);
-if (r = 0) {
+if (r 0) {
strv_free(strv);
return r;
}
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] bus: allow reading empty arrays
You can disregard these three patches, they will be part of the systemctl porting. Marc-Antoine ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 5/7] bus: mark sd_bus_message_at_end public
---
src/libsystemd-bus/bus-message.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd-bus/bus-message.c b/src/libsystemd-bus/bus-message.c
index 16b2201..cc62050 100644
--- a/src/libsystemd-bus/bus-message.c
+++ b/src/libsystemd-bus/bus-message.c
@@ -2415,7 +2415,7 @@ static bool message_end_of_array(sd_bus_message *m,
size_t index) {
return index = c-begin + BUS_MESSAGE_BSWAP32(m, *c-array_size);
}
-int sd_bus_message_at_end(sd_bus_message *m, int complete) {
+_public_ int sd_bus_message_at_end(sd_bus_message *m, int complete) {
assert_return(m, -EINVAL);
assert_return(m-sealed, -EPERM);
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/7] bus: allow reading empty arrays
---
src/libsystemd-bus/bus-message.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/src/libsystemd-bus/bus-message.c b/src/libsystemd-bus/bus-message.c
index 9543ae3..0fd9aa1 100644
--- a/src/libsystemd-bus/bus-message.c
+++ b/src/libsystemd-bus/bus-message.c
@@ -3567,15 +3567,20 @@ _public_ int sd_bus_message_read_array(sd_bus_message
*m,
if (r = 0)
return r;
-c = message_get_container(m);
-sz = BUS_MESSAGE_BSWAP32(m, *c-array_size);
+if (message_end_of_array(m, m-rindex)) {
+p = NULL;
+sz = 0;
+} else {
+c = message_get_container(m);
+sz = BUS_MESSAGE_BSWAP32(m, *c-array_size);
-r = message_peek_body(m, m-rindex, align, sz, p);
-if (r 0)
-goto fail;
-if (r == 0) {
-r = -EBADMSG;
-goto fail;
+r = message_peek_body(m, m-rindex, align, sz, p);
+if (r 0)
+goto fail;
+if (r == 0) {
+r = -EBADMSG;
+goto fail;
+}
}
r = sd_bus_message_exit_container(m);
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/7] bus: fix bus_print_property with strv
---
src/libsystemd-bus/bus-util.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/src/libsystemd-bus/bus-util.c b/src/libsystemd-bus/bus-util.c
index 13ad444..2a9cd4f 100644
--- a/src/libsystemd-bus/bus-util.c
+++ b/src/libsystemd-bus/bus-util.c
@@ -545,33 +545,28 @@ int bus_print_property(const char *name, sd_bus_message
*property, bool all) {
case SD_BUS_TYPE_ARRAY:
if (streq(contents, s)) {
-bool space = false;
-char tp;
-const char *cnt;
+bool first = true;
+const char *str;
r = sd_bus_message_enter_container(property,
SD_BUS_TYPE_ARRAY, contents);
if (r 0)
return r;
-r = sd_bus_message_peek_type(property, tp, cnt);
+while((r = sd_bus_message_read_basic(property,
SD_BUS_TYPE_STRING, str)) 0) {
+if (first)
+printf(%s=, name);
+
+printf(%s%s, first ? : , str);
+
+first = false;
+}
if (r 0)
return r;
-if (all || cnt) {
-const char *str;
-
+if (first all)
printf(%s=, name);
-
-while((r = sd_bus_message_read_basic(property,
SD_BUS_TYPE_STRING, str)) = 0) {
-printf(%s%s, space ? : , str);
-
-space = true;
-}
-if (r 0)
-return r;
-
+if (!first || all)
puts();
-}
r = sd_bus_message_exit_container(property);
if (r 0)
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/7] systemctl: port to libsystemd-bus
This serie of patches ports systemctl to libsystemd-bus and fixes
a couple of issues encountered while porting it.
Note that curerently systemctl --user doesn't work.
Actually, systemd-analyze --user doesn't work either, so there seem
to be an issue regarding this in libsystemd-bus.
The error message is:
Failed to parse reply: Process org.freedesktop.systemd1 exited with status 1
Marc-Antoine Perennou (7):
bus: allow reading empty arrays
bus: fix bus_message_read_strv
bus: fix bus_print_property with strv
bus: rename sd_bus_get_property_{trivial,basic}
bus: mark sd_bus_message_at_end public
analyze: split out bus util functions
systemctl: port to libsystemd-bus
Makefile.am |6 +-
src/analyze/analyze.c | 82 +-
src/libsystemd-bus/bus-convenience.c |4 +-
src/libsystemd-bus/bus-message.c | 25 +-
src/libsystemd-bus/bus-util.c | 75 +-
src/libsystemd-bus/bus-util.h | 17 +
src/libsystemd-bus/libsystemd-bus.sym |2 +-
src/systemctl/systemctl.c | 2301 -
src/systemd/sd-bus.h |2 +-
9 files changed, 961 insertions(+), 1553 deletions(-)
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 6/7] analyze: split out bus util functions
They will soon be used in systemctl
---
src/analyze/analyze.c | 80 +++
src/libsystemd-bus/bus-util.c | 46 +
src/libsystemd-bus/bus-util.h | 17 +
3 files changed, 67 insertions(+), 76 deletions(-)
diff --git a/src/analyze/analyze.c b/src/analyze/analyze.c
index 522e618..34fea28 100644
--- a/src/analyze/analyze.c
+++ b/src/analyze/analyze.c
@@ -89,19 +89,6 @@ struct boot_times {
usec_t unitsload_finish_time;
};
-struct unit_info {
-const char *id;
-const char *description;
-const char *load_state;
-const char *active_state;
-const char *sub_state;
-const char *following;
-const char *unit_path;
-uint32_t job_id;
-const char *job_type;
-const char *job_path;
-};
-
struct unit_times {
char *name;
usec_t activating;
@@ -174,71 +161,12 @@ static void free_unit_times(struct unit_times *t,
unsigned n) {
free(t);
}
-static int bus_parse_unit_info(sd_bus_message *message, struct unit_info *u) {
-int r = 0;
-
-assert(message);
-assert(u);
-
-r = sd_bus_message_read(message, (ssouso), u-id,
- u-description,
- u-load_state,
- u-active_state,
- u-sub_state,
- u-following,
- u-unit_path,
- u-job_id,
- u-job_type,
- u-job_path);
-if (r 0) {
-log_error(Failed to parse message as unit_info.);
-return -EIO;
-}
-
-return r;
-}
-
-static int bus_get_unit_property_strv(sd_bus *bus, const char *unit_path,
const char *prop, char ***strv) {
-_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
-_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
-int r;
-const char *s;
-
-r = sd_bus_get_property(
-bus,
-org.freedesktop.systemd1,
-unit_path,
-org.freedesktop.systemd1.Unit,
-prop,
-error,
-reply,
-as);
-if (r 0) {
-log_error(Failed to get unit property: %s %s, prop,
bus_error_message(error, -r));
-return r;
-}
-
-r = sd_bus_message_enter_container(reply, SD_BUS_TYPE_ARRAY, s);
-if (r 0)
-return r;
-
-while ((r = sd_bus_message_read(reply, s, s)) 0) {
-r = strv_extend(strv, s);
-if (r 0) {
-log_oom();
-return r;
-}
-}
-
-return r;
-}
-
static int acquire_time_data(sd_bus *bus, struct unit_times **out) {
_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
int r, c = 0, n_units = 0;
struct unit_times *unit_times = NULL;
-struct unit_info u;
+struct unit_info u = {};
r = sd_bus_call_method(
bus,
@@ -258,7 +186,7 @@ static int acquire_time_data(sd_bus *bus, struct unit_times
**out) {
if (r 0)
goto fail;
-while ((r = bus_parse_unit_info(reply, u)) 0) {
+while ((r = bus_message_read_unit_info(reply, u)) 0) {
struct unit_times *t;
if (r 0)
@@ -1042,8 +970,8 @@ static int graph_one(sd_bus *bus, const struct unit_info
*u, char *patterns[]) {
static int dot(sd_bus *bus, char* patterns[]) {
_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+struct unit_info u = {};
int r;
-struct unit_info u;
r = sd_bus_call_method(
bus,
@@ -1065,7 +993,7 @@ static int dot(sd_bus *bus, char* patterns[]) {
printf(digraph systemd {\n);
-while ((r = bus_parse_unit_info(reply, u)) 0) {
+while ((r = bus_message_read_unit_info(reply, u)) 0) {
r = graph_one(bus, u, patterns);
if (r 0)
return r;
diff --git a/src/libsystemd-bus/bus-util.c b/src/libsystemd-bus/bus-util.c
index 2a9cd4f..d026487 100644
--- a/src/libsystemd-bus/bus-util.c
+++ b/src/libsystemd-bus/bus-util.c
@@ -947,3 +947,49 @@ int bus_property_get_uid(
return
[systemd-devel] [PATCH 2/7] bus: fix bus_message_read_strv
message_read_strv_extend returns 0 on success
---
src/libsystemd-bus/bus-message.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd-bus/bus-message.c b/src/libsystemd-bus/bus-message.c
index 0fd9aa1..16b2201 100644
--- a/src/libsystemd-bus/bus-message.c
+++ b/src/libsystemd-bus/bus-message.c
@@ -4438,7 +4438,7 @@ _public_ int sd_bus_message_read_strv(sd_bus_message *m,
char ***l) {
assert_return(l, -EINVAL);
r = bus_message_read_strv_extend(m, strv);
-if (r = 0) {
+if (r 0) {
strv_free(strv);
return r;
}
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 4/7] bus: rename sd_bus_get_property_{trivial, basic}
--- src/analyze/analyze.c | 2 +- src/libsystemd-bus/bus-convenience.c | 4 ++-- src/libsystemd-bus/libsystemd-bus.sym | 2 +- src/systemd/sd-bus.h | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/analyze/analyze.c b/src/analyze/analyze.c index 22bf076..522e618 100644 --- a/src/analyze/analyze.c +++ b/src/analyze/analyze.c @@ -123,7 +123,7 @@ static int bus_get_uint64_property(sd_bus *bus, const char *path, const char *in _cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL; int r; -r = sd_bus_get_property_trivial( +r = sd_bus_get_property_basic( bus, org.freedesktop.systemd1, path, diff --git a/src/libsystemd-bus/bus-convenience.c b/src/libsystemd-bus/bus-convenience.c index 0ccc259..db15fdd 100644 --- a/src/libsystemd-bus/bus-convenience.c +++ b/src/libsystemd-bus/bus-convenience.c @@ -270,7 +270,7 @@ _public_ int sd_bus_get_property( return 0; } -_public_ int sd_bus_get_property_trivial( +_public_ int sd_bus_get_property_basic( sd_bus *bus, const char *destination, const char *path, @@ -285,7 +285,7 @@ _public_ int sd_bus_get_property_trivial( assert_return(bus, -EINVAL); assert_return(isempty(interface) || interface_name_is_valid(interface), -EINVAL); assert_return(member_name_is_valid(member), -EINVAL); -assert_return(bus_type_is_trivial(type), -EINVAL); +assert_return(bus_type_is_basic(type), -EINVAL); assert_return(ptr, -EINVAL); assert_return(BUS_IS_OPEN(bus-state), -ENOTCONN); assert_return(!bus_pid_changed(bus), -ECHILD); diff --git a/src/libsystemd-bus/libsystemd-bus.sym b/src/libsystemd-bus/libsystemd-bus.sym index 5eecfa1..01a0c8a 100644 --- a/src/libsystemd-bus/libsystemd-bus.sym +++ b/src/libsystemd-bus/libsystemd-bus.sym @@ -141,7 +141,7 @@ global: /* Convenience calls */ sd_bus_call_method; sd_bus_get_property; -sd_bus_get_property_trivial; +sd_bus_get_property_basic; sd_bus_set_property; sd_bus_reply_method_return; sd_bus_reply_method_error; diff --git a/src/systemd/sd-bus.h b/src/systemd/sd-bus.h index 48edc59..e38f4a4 100644 --- a/src/systemd/sd-bus.h +++ b/src/systemd/sd-bus.h @@ -212,7 +212,7 @@ int sd_bus_message_rewind(sd_bus_message *m, int complete); int sd_bus_call_method(sd_bus *bus, const char *destination, const char *path, const char *interface, const char *member, sd_bus_error *error, sd_bus_message **reply, const char *types, ...); int sd_bus_get_property(sd_bus *bus, const char *destination, const char *path, const char *interface, const char *member, sd_bus_error *error, sd_bus_message **reply, const char *type); -int sd_bus_get_property_trivial(sd_bus *bus, const char *destination, const char *path, const char *interface, const char *member, sd_bus_error *error, char type, void *ptr); +int sd_bus_get_property_basic(sd_bus *bus, const char *destination, const char *path, const char *interface, const char *member, sd_bus_error *error, char type, void *ptr); int sd_bus_set_property(sd_bus *bus, const char *destination, const char *path, const char *interface, const char *member, sd_bus_error *error, const char *type, ...); int sd_bus_reply_method_return(sd_bus *bus, sd_bus_message *call, const char *types, ...); int sd_bus_reply_method_error(sd_bus *bus, sd_bus_message *call, const sd_bus_error *e); -- 1.8.4.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 1/2] analyze: split out bus util functions
They will soon be used in systemctl
---
src/analyze/analyze.c | 68 +++
src/libsystemd-bus/bus-util.c | 49 +++
src/libsystemd-bus/bus-util.h | 17 +++
3 files changed, 70 insertions(+), 64 deletions(-)
diff --git a/src/analyze/analyze.c b/src/analyze/analyze.c
index e149b15..19e6508 100644
--- a/src/analyze/analyze.c
+++ b/src/analyze/analyze.c
@@ -89,19 +89,6 @@ struct boot_times {
usec_t unitsload_finish_time;
};
-struct unit_info {
-const char *id;
-const char *description;
-const char *load_state;
-const char *active_state;
-const char *sub_state;
-const char *following;
-const char *unit_path;
-uint32_t job_id;
-const char *job_type;
-const char *job_path;
-};
-
struct unit_times {
char *name;
usec_t activating;
@@ -146,31 +133,6 @@ static int bus_get_uint64_property(sd_bus *bus, const char
*path, const char *in
return 0;
}
-static int bus_get_unit_property_strv(sd_bus *bus, const char *path, const
char *property, char ***strv) {
-_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
-int r;
-
-assert(bus);
-assert(path);
-assert(property);
-assert(strv);
-
-r = sd_bus_get_property_strv(
-bus,
-org.freedesktop.systemd1,
-path,
-org.freedesktop.systemd1.Unit,
-property,
-error,
-strv);
-if (r 0) {
-log_error(Failed to get unit property %s: %s, property,
bus_error_message(error, -r));
-return r;
-}
-
-return 0;
-}
-
static int compare_unit_time(const void *a, const void *b) {
return compare(((struct unit_times *)b)-time,
((struct unit_times *)a)-time);
@@ -205,34 +167,12 @@ static void free_unit_times(struct unit_times *t,
unsigned n) {
free(t);
}
-static int bus_parse_unit_info(sd_bus_message *message, struct unit_info *u) {
-int r = 0;
-
-assert(message);
-assert(u);
-
-r = sd_bus_message_read(message, (ssouso), u-id,
- u-description,
- u-load_state,
- u-active_state,
- u-sub_state,
- u-following,
- u-unit_path,
- u-job_id,
- u-job_type,
- u-job_path);
-if (r 0)
-return bus_log_parse_error(r);
-
-return r;
-}
-
static int acquire_time_data(sd_bus *bus, struct unit_times **out) {
_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
int r, c = 0, n_units = 0;
struct unit_times *unit_times = NULL;
-struct unit_info u;
+struct unit_info u = {};
r = sd_bus_call_method(
bus,
@@ -253,7 +193,7 @@ static int acquire_time_data(sd_bus *bus, struct unit_times
**out) {
goto fail;
}
-while ((r = bus_parse_unit_info(reply, u)) 0) {
+while ((r = bus_message_read_unit_info(reply, u)) 0) {
struct unit_times *t;
if (r 0)
@@ -1027,8 +967,8 @@ static int graph_one(sd_bus *bus, const struct unit_info
*u, char *patterns[]) {
static int dot(sd_bus *bus, char* patterns[]) {
_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+struct unit_info u = {};
int r;
-struct unit_info u;
r = sd_bus_call_method(
bus,
@@ -1050,7 +990,7 @@ static int dot(sd_bus *bus, char* patterns[]) {
printf(digraph systemd {\n);
-while ((r = bus_parse_unit_info(reply, u)) 0) {
+while ((r = bus_message_read_unit_info(reply, u)) 0) {
r = graph_one(bus, u, patterns);
if (r 0)
return r;
diff --git a/src/libsystemd-bus/bus-util.c b/src/libsystemd-bus/bus-util.c
index ae9733d..3959972 100644
--- a/src/libsystemd-bus/bus-util.c
+++ b/src/libsystemd-bus/bus-util.c
@@ -958,3 +958,52 @@ int bus_log_parse_error(int r) {
log_error(Failed to parse message: %s, strerror(-r));
return r;
}
+
+int bus_get_unit_property_strv(sd_bus *bus, const char *path, const char
Re: [systemd-devel] [PATCH V2 2/2] systemctl: port to libsystemd-bus
On Friday, November 8, 2013, Lennart Poettering wrote: On Fri, 08.11.13 10:34, Marc-Antoine Perennou (marc-anto...@perennou.com) wrote: Heya! I already rebased the previous version you posted, and then applied with some changes. Is this reposting of yours more than just a rebase? I merged both commits into one, and made a couple of changes: I didn't like the log_method_call_failed() thing, because I'd much prefer having good explanatory error messages which usually require format strings and stuff. I did like log_message_creation_failed() though and moved it to bus-util.c as bus_log_create_error(). sd-bus.h is a public API, where we try to avoid everything that is not C89. bool is C99. The message parser/append calls hence assume that booleans are ints, as in traditional C, in glib or even the old libdbus1. However, bool and int have different sizes, which means taking a pointer of a bool and passing that to sd_bus_message_read() or so for parsing a bool will explode. C can be ugly like hell sometimes. Anyway, fixed those. The bus transport generalization doesn't do direct PID1 connections anymore, I will add this in a alter commit. Thanks a lot for the patch! We are now down to only PID 1 left in libdus-1 land! Lennart -- Lennart Poettering, Red Hat Was mostly a rebase + trivial cleanups, nothing important. Thanks for the hints and fixes! Marc-Antoine ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] shared: add missing include
Needed for socketpair, recv --- src/shared/logs-show.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c index c99fc75..0e3fd3d 100644 --- a/src/shared/logs-show.c +++ b/src/shared/logs-show.c @@ -23,6 +23,7 @@ #include assert.h #include errno.h #include sys/poll.h +#include sys/socket.h #include string.h #include fcntl.h -- 1.8.5.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] rtnl: fix for 32bits
Commit 0a0dc69b655cfb10cab39133f5d521e7b35ce3d5 broke tests for 32 bits --- src/libsystemd-rtnl/rtnl-message.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libsystemd-rtnl/rtnl-message.c b/src/libsystemd-rtnl/rtnl-message.c index 264cca0..c62eca9 100644 --- a/src/libsystemd-rtnl/rtnl-message.c +++ b/src/libsystemd-rtnl/rtnl-message.c @@ -601,7 +601,7 @@ int sd_rtnl_message_append_ether_addr(sd_rtnl_message *m, unsigned short type, c return -ENOTSUP; } -r = add_rtattr(m, type, data, sizeof(data)); +r = add_rtattr(m, type, data, ETH_ALEN); if (r 0) return r; -- 1.8.5.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/4] bus: driverd: don't remove twice a match from the list
match_free already does it
---
src/bus-driverd/bus-driverd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/bus-driverd/bus-driverd.c b/src/bus-driverd/bus-driverd.c
index 44172c4..b423420 100644
--- a/src/bus-driverd/bus-driverd.c
+++ b/src/bus-driverd/bus-driverd.c
@@ -129,10 +129,8 @@ static int match_new(Client *c, struct bus_match_component
*components, unsigned
first = hashmap_get(c-matches, m-match);
LIST_PREPEND(matches, first, m);
r = hashmap_replace(c-matches, m-match, first);
-if (r 0) {
-LIST_REMOVE(matches, first, m);
+if (r 0)
goto fail;
-}
m-client = c;
c-n_matches++;
--
1.8.5.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/4] bus: driverd: don't attempt to remove from empty list
---
src/bus-driverd/bus-driverd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/bus-driverd/bus-driverd.c b/src/bus-driverd/bus-driverd.c
index b423420..1fdea7e 100644
--- a/src/bus-driverd/bus-driverd.c
+++ b/src/bus-driverd/bus-driverd.c
@@ -90,10 +90,10 @@ static void match_free(Match *m) {
Match *first;
first = hashmap_get(m-client-matches, m-match);
-LIST_REMOVE(matches, first, m);
-if (first)
+if (first) {
+LIST_REMOVE(matches, first, m);
assert_se(hashmap_replace(m-client-matches,
m-match, first) = 0);
-else
+} else
hashmap_remove(m-client-matches, m-match);
m-client-n_matches--;
--
1.8.5.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/4] bus: driverd: don't attempt to remove from empty list
On 28 December 2013 13:54, Marc-Antoine Perennou
marc-anto...@perennou.com wrote:
---
src/bus-driverd/bus-driverd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/bus-driverd/bus-driverd.c b/src/bus-driverd/bus-driverd.c
index b423420..1fdea7e 100644
--- a/src/bus-driverd/bus-driverd.c
+++ b/src/bus-driverd/bus-driverd.c
@@ -90,10 +90,10 @@ static void match_free(Match *m) {
Match *first;
first = hashmap_get(m-client-matches, m-match);
-LIST_REMOVE(matches, first, m);
-if (first)
+if (first) {
+LIST_REMOVE(matches, first, m);
assert_se(hashmap_replace(m-client-matches,
m-match, first) = 0);
-else
+} else
hashmap_remove(m-client-matches, m-match);
m-client-n_matches--;
--
1.8.5.2
Any news on this one?
Without it, every startup I get
#0 0x7ffcebc5f339 in raise () from /usr/lib64/libc.so.6
No symbol table info available.
#1 0x7ffcebc60738 in abort () from /usr/lib64/libc.so.6
No symbol table info available.
#2 0x0042e743 in log_assert_failed (text=text@entry=0x4308af
*_head == _item, file=file@entry=0x4303c0
/var/tmp/paludis/build/sys-apps-systemd-scm/work/systemd-scm/src/bus-driverd/bus-driverd.c,
line=line@entry=93, func=func@entry=0x430bf4
__PRETTY_FUNCTION__.10834 match_free) at
/var/tmp/paludis/build/sys-apps-systemd-scm/work/systemd-scm/src/shared/log.c:725
No locals.
#3 0x004038cb in match_free (m=0x1a99ba0) at
/var/tmp/paludis/build/sys-apps-systemd-scm/work/systemd-scm/src/bus-driverd/bus-driverd.c:93
_head = synthetic pointer
_item = 0x1a99ba0
first = optimized out
__PRETTY_FUNCTION__ = match_free
#4 0x004041c0 in client_free (c=0x1a54db0) at
/var/tmp/paludis/build/sys-apps-systemd-scm/work/systemd-scm/src/bus-driverd/bus-driverd.c:166
m = optimized out
__PRETTY_FUNCTION__ = client_free
#5 0x004047bd in on_name_owner_changed (bus=optimized out,
m=optimized out, userdata=optimized out, error=optimized out) at
/var/tmp/paludis/build/sys-apps-systemd-scm/work/systemd-scm/src/bus-driverd/bus-driverd.c:180
c = optimized out
__PRETTY_FUNCTION__ = on_name_owner_changed
#6 0x0041e328 in bus_match_run (bus=bus@entry=0x197b180,
node=0x1aa7e60, m=m@entry=0x1a3a8a0) at
/var/tmp/paludis/build/sys-apps-systemd-scm/work/systemd-scm/src/libsystemd-bus/bus-match.c:292
error_buffer = {name = 0x0, message = 0x0, _need_free = 0}
test_str = 0x0
test_u8 = 0 '\000'
r = optimized out
__PRETTY_FUNCTION__ = bus_match_run
#7 0x0041e2bf in bus_match_run (bus=bus@entry=0x197b180,
node=0x1aa7e10, m=m@entry=0x1a3a8a0) at
/var/tmp/paludis/build/sys-apps-systemd-scm/work/systemd-scm/src/libsystemd-bus/bus-match.c:273
test_str = 0x0
test_u8 = 0 '\000'
r = optimized out
__PRETTY_FUNCTION__ = bus_match_run
#8 0x0041e47d in bus_match_run (bus=bus@entry=0x197b180,
node=0x197f3e0, m=m@entry=0x1a3a8a0) at
/var/tmp/paludis/build/sys-apps-systemd-scm/work/systemd-scm/src/libsystemd-bus/bus-match.c:355
found = optimized out
test_str = 0x7ffcec40f000 :1.76
test_u8 = 0 '\000'
r = optimized out
__PRETTY_FUNCTION__ = bus_match_run
#9 0x0041e2bf in bus_match_run (bus=bus@entry=0x197b180,
node=0x197f370, m=m@entry=0x1a3a8a0) at
/var/tmp/paludis/build/sys-apps-systemd-scm/work/systemd-scm/src/libsystemd-bus/bus-match.c:273
test_str = 0x0
test_u8 = 0 '\000'
r = optimized out
__PRETTY_FUNCTION__ = bus_match_run
#10 0x0041e47d in bus_match_run (bus=bus@entry=0x197b180,
node=0x197f320, m=m@entry=0x1a3a8a0) at
/var/tmp/paludis/build/sys-apps-systemd-scm/work/systemd-scm/src/libsystemd-bus/bus-match.c:355
found = optimized out
test_str = 0x1a58e68 /org/freedesktop/DBus
test_u8 = 0 '\000'
r = optimized out
__PRETTY_FUNCTION__ = bus_match_run
#11 0x0041e2bf in bus_match_run (bus=bus@entry=0x197b180,
node=0x197f2b0, m=m@entry=0x1a3a8a0) at
/var/tmp/paludis/build/sys-apps-systemd-scm/work/systemd-scm/src/libsystemd-bus/bus-match.c:273
test_str = 0x0
test_u8 = 0 '\000'
r = optimized out
__PRETTY_FUNCTION__ = bus_match_run
#12 0x0041e47d in bus_match_run (bus=bus@entry=0x197b180,
node=0x197f260, m=m@entry=0x1a3a8a0) at
/var/tmp/paludis/build/sys-apps-systemd-scm/work/systemd-scm/src/libsystemd-bus/bus-match.c:355
found = optimized out
test_str = 0x1a58ea8 NameOwnerChanged
test_u8 = 0 '\000'
r = optimized out
__PRETTY_FUNCTION__ = bus_match_run
#13 0x0041e2bf in bus_match_run (bus=bus@entry=0x197b180,
node=0x197f1f0, m=m@entry=0x1a3a8a0) at
/var/tmp/paludis/build/sys-apps
Re: [systemd-devel] [PATCH][V3] systemd-analyze: rewrite in C.
On 4 February 2013 22:33, Peeters Simon peeters.si...@gmail.com wrote: 2013/2/4 Lennart Poettering lenn...@poettering.net: On Mon, 04.02.13 21:32, Simon Peeters (peeters.si...@gmail.com) wrote: Written by Peeters Simon peeters.si...@gmail.com. Makefile stuff and cleaned up a bit by Auke Kok auke-jan.h@intel.com. --- Hmm, how does this relate to this work: https://bugzilla.freedesktop.org/show_bug.cgi?id=60112 hmm, did not yet see this. Can we merge both approaches? I will look at it further but my current toughts: - the bus_parse_unit_info functions seems a good idea. - his bus_get_uint64_property is slightly nicer than mine. - it still uses cairo to write the plot which i think is not so nice. (since it is overkill for writing svg) - it seems like a more literal translation in some places. - repeats some bugs that were in the original python version but fixed in my version. - it does not print bars for firmware and loader into the svg output. - it prints more informational text on the svg. - quiet unfortunate that these patches did not end up on the mailing list. (and apparently the poster did not see my patches on the list either) so I propose I try to merge the best of both patch-sets. any other comments with regards to this? I indeed did not see your patches, unfortunately. I did not think about the mailing list for that, my mistake. It is indeed a quite literal translation for the most of it. I like better your svg approach getting rid of cairo. Feel free to merge both patch-sets and to yell at me if you need some help to do so. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 5/6] Add hexstr function
On 12 February 2013 00:14, Oleksii Shevchuk alx...@gmail.com wrote:
Function that converts byte array to hex string
---
src/shared/util.c | 23 +++
src/shared/util.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/src/shared/util.c b/src/shared/util.c
index 24f9e7e..6dbfe29 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -1368,6 +1368,29 @@ char hexchar(int x) {
return table[x 15];
}
+char * hexstr (const uint8_t *in, size_t count)
+{
+char *r, *i = NULL;
+
+if (!in || !count)
+goto finish;
+
+r = i = new(char, count * 2 + 1);
+if (! r)
+goto finish;
+
+while (count--) {
+*i++ = hexchar(*in 4);
+*i++ = hexchar(*in);
+++in;
+}
+
+*i = '\0';
+
+ finish:
+return r;
+}
+
int unhexchar(char c) {
if (c = '0' c = '9')
diff --git a/src/shared/util.h b/src/shared/util.h
index cd13457..fe85fa8 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -211,6 +211,7 @@ int get_process_uid(pid_t pid, uid_t *uid);
int get_process_gid(pid_t pid, gid_t *gid);
char hexchar(int x);
+char * hexstr (const uint8_t *in, size_t count);
int unhexchar(char c);
char octchar(int x);
int unoctchar(char c);
--
1.8.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Hi,
I think you may be returning an unitialized r with your first goto
finish, you should set it to NULL like you do for i
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] kernel-install: don't make unused parameter mandatory
We only use the image name in the case we're adding a kernel
Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
---
src/kernel-install/kernel-install | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/kernel-install/kernel-install
b/src/kernel-install/kernel-install
index 16c06e0..9f3a523 100644
--- a/src/kernel-install/kernel-install
+++ b/src/kernel-install/kernel-install
@@ -62,7 +62,7 @@ usage()
} 2
}
-if ! ( [[ $COMMAND ]] [[ $KERNEL_VERSION ]] [[ $KERNEL_IMAGE ]] ); then
+if ! ( [[ $COMMAND ]] [[ $KERNEL_VERSION ]] ); then
usage
exit 1
fi
@@ -101,6 +101,10 @@ readarray -t PLUGINS (
case $COMMAND in
add)
+if [[ -z $KERNEL_IMAGE ]]; then
+usage
+exit 1
+fi
mkdir -p $BOOT_DIR_ABS || exit 1
for f in ${PLUGINS[@]}; do
--
1.8.1.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
