[systemd-devel] failed to change interface name (systemd-networkd)
Hello, Hoping someone can point me in the right direction. I'm attempting to change the interface name (eth0 -> wired) on one of my servers. Here's the output from the journal: ~# journalctl --no-pager | grep -i wired Sep 23 17:11:15 vivid systemd-udevd[399]: error changing net interface name 'eth0' to 'wired0': Device or resource busy Sep 23 17:11:15 vivid systemd-udevd[399]: could not rename interface '2' from 'eth0' to 'wired0': Device or resource busy Sep 23 17:11:17 vivid sh[566]: Unknown interface wired0 Sep 23 17:11:17 vivid systemd[1]: Started ifup for wired0. Sep 23 17:11:17 vivid systemd[1]: Starting ifup for wired0... Here's what the .link contains: # cat 10-ethernet.link [Match] MACAddress=fa:16:3e:31:7a:4b [Link] Name=wired0 MACAddress=fa:15:33:55:33:44 And the .network: # cat 20-ethernet.network [Match] Name=wired* [Network] DNS=8.8.8.8 DNS=8.8.4.4 [Address] Address=10.1.1.190/24 [Route] Destination=0.0.0.0/0 Gateway=10.1.1.1 The MAC address of the interface changes properly, so I know that the unit is at least being read and parsed. As an aside, this is happening on Ubuntu 15.04. I've disabled NetworkManager and am relying, obviously, on systemd-networkd and systemd-resolved. I've also temporarily disabled dhcpd thinking that may have had something to do with the interface being busy, to no avail. Any thoughts on why the interface is busy resulting in the name change failing? Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] failed to change interface name (systemd-networkd)
Hello, just following up to see if there were any ideas on what may be causing this. Any thoughts appreciated. On Wed, Sep 23, 2015 at 10:17 PM, James wrote: > Hello, > > Hoping someone can point me in the right direction. I'm attempting to > change the interface name (eth0 -> wired) on one of my servers. > > Here's the output from the journal: > > ~# journalctl --no-pager | grep -i wired > Sep 23 17:11:15 vivid systemd-udevd[399]: error changing net interface > name 'eth0' to 'wired0': Device or resource busy > Sep 23 17:11:15 vivid systemd-udevd[399]: could not rename interface > '2' from 'eth0' to 'wired0': Device or resource busy > Sep 23 17:11:17 vivid sh[566]: Unknown interface wired0 > Sep 23 17:11:17 vivid systemd[1]: Started ifup for wired0. > Sep 23 17:11:17 vivid systemd[1]: Starting ifup for wired0... > > Here's what the .link contains: > > # cat 10-ethernet.link > [Match] > MACAddress=fa:16:3e:31:7a:4b > [Link] > Name=wired0 > MACAddress=fa:15:33:55:33:44 > > And the .network: > > # cat 20-ethernet.network > [Match] > Name=wired* > [Network] > DNS=8.8.8.8 > DNS=8.8.4.4 > [Address] > Address=10.1.1.190/24 > [Route] > Destination=0.0.0.0/0 > Gateway=10.1.1.1 > > The MAC address of the interface changes properly, so I know that the > unit is at least being read and parsed. > > As an aside, this is happening on Ubuntu 15.04. I've disabled > NetworkManager and am relying, obviously, on systemd-networkd and > systemd-resolved. I've also temporarily disabled dhcpd thinking that > may have had something to do with the interface being busy, to no > avail. > > Any thoughts on why the interface is busy resulting in the name change > failing? > > Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] failed to change interface name (systemd-networkd)
Thanks Kay - that jives with what I was thinking, as well. Is there a good way to tell? I've used systemd-analyze critical-chain to see if there is something being kicked off by systemd before the network scripts can run, but alas it appears that none of the systemd units are the culprit here. I'm running into this issue on Ubuntu 15.04 (Vivid). If there are any pointers on how to best determine the script / root cause I'd be very much appreciative. Thank you. On Thu, Oct 1, 2015 at 2:31 PM, Kay Sievers wrote: > On Thu, Oct 1, 2015 at 7:21 PM, James wrote: >> Hello, just following up to see if there were any ideas on what may be >> causing this. >> >> Any thoughts appreciated. >> >> On Wed, Sep 23, 2015 at 10:17 PM, James wrote: >>> Hello, >>> >>> Hoping someone can point me in the right direction. I'm attempting to >>> change the interface name (eth0 -> wired) on one of my servers. >>> >>> Here's the output from the journal: >>> >>> ~# journalctl --no-pager | grep -i wired >>> Sep 23 17:11:15 vivid systemd-udevd[399]: error changing net interface >>> name 'eth0' to 'wired0': Device or resource busy >>> Sep 23 17:11:15 vivid systemd-udevd[399]: could not rename interface >>> '2' from 'eth0' to 'wired0': Device or resource busy >>> Sep 23 17:11:17 vivid sh[566]: Unknown interface wired0 >>> Sep 23 17:11:17 vivid systemd[1]: Started ifup for wired0. >>> Sep 23 17:11:17 vivid systemd[1]: Starting ifup for wired0... >>> >>> Here's what the .link contains: >>> >>> # cat 10-ethernet.link >>> [Match] >>> MACAddress=fa:16:3e:31:7a:4b >>> [Link] >>> Name=wired0 >>> MACAddress=fa:15:33:55:33:44 >>> >>> And the .network: >>> >>> # cat 20-ethernet.network >>> [Match] >>> Name=wired* >>> [Network] >>> DNS=8.8.8.8 >>> DNS=8.8.4.4 >>> [Address] >>> Address=10.1.1.190/24 >>> [Route] >>> Destination=0.0.0.0/0 >>> Gateway=10.1.1.1 >>> >>> The MAC address of the interface changes properly, so I know that the >>> unit is at least being read and parsed. >>> >>> As an aside, this is happening on Ubuntu 15.04. I've disabled >>> NetworkManager and am relying, obviously, on systemd-networkd and >>> systemd-resolved. I've also temporarily disabled dhcpd thinking that >>> may have had something to do with the interface being busy, to no >>> avail. >>> >>> Any thoughts on why the interface is busy resulting in the name change >>> failing? > > Most likely you have some other daemon running, or a script executed > by udev, or the interface is found by some init script, something that > brings the interface up before the attempt to rename it by > udev/networkd. > > Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ordering services issue. Trying to start ptp4l in bonding setup fails as bonding appears to take a while.
On 12/1/21 07:20, Brian Hutchinson wrote: ... In .system file I tried all I know to ensure the required interfaces were created before starting ptp4l in attempt to give bonding enough time to finish but binding to things like sys-subsystem-net-devices-bond1.device wasn't enough. Is it also possible to use carrier state in .service file? I see sys/devices/virtual/net/bond1/carrier but not sure how to only attempt to start my ptp4l service after carrier state is "1". I welcome your ideas and suggestions on how to start a service after a bond interface is really up. With systemd, the proper way to setup network bonding is to establish ordering with the use of "target" files, which can be added to /etc/systemd/system. The target files themselves need not contain anything, though I have these with simply: [Unit] Documentation= man:systemd.target(5) My configuration provides automatic bonding and bridging for removable/pluggable and fixed hardwired, wireless, and virtual interfaces, using hardlinked template files and a separate network configuration file, as /etc/conf.d/network, though you are only looking for bonding here. The big advantage with using systemd as the network configuration system, compared to alternatives, is that it "just works", and doesn't break after someone else's "upgrade". The essential idea with configuring virtual network interfaces using systemd target files derives from noting that network service clients and servers must run After bridge and bond master interfaces are working, which implies After configuration of their respective slave interfaces, and that hardware devices can only be enslaved After the master interfaces have been created. These constraints imply the following ordering: 1) master interfaces 2) enslaved interfaces 3) network services The systemd target files are then inferred between these three stages: a) master interfaces b) "go.target" c) enslaved interfaces d) "ll.target" e) network services The target file naming is arbitrary, of course. I use these names from arbitrarily choosing the point of view from the template file used to configure each slave device to each master, where finally "ip link set %P master %I". You could use the terminology "director" and "executive", from corporate structure lingo, instead of "master" and "slave", if preferred, but the ip command still uses the the terms "master" and "slave". A hardware network device Requires go.target and the master interface service file "master@.service" runs Before go.target: Requires= go.target Before= go.target Plugging network hardware, then, will trigger the entire chain of configuration events. BindsTo= sys-subsystem-net-devices-%i.device Similarly, for the enslaved interface service file "enslaved@.service": Requires= go.target After= go.target Before= ll.target And finally, for the various network services service template files: PartOf= ll.target Requires= ll.target After= ll.target That's the basic idea. Of course, there are plenty of "housekeeping" details in practice. In particular, "Requisite" fails to recognize device units, and instead, ConditionPathExists= /sys/class/net/%I is necessary. This appears to me to be an unjustified bug with "Requisite", but - you know - Lennart. Altogether, to trigger configuration of both master and slave devices from "enslaved@.service": BindsTo= sys-subsystem-net-devices-%p.device ConditionPathExists= /sys/class/net/%P BindsTo= sys-subsystem-net-devices-%i.device It is useful to impose an arbitrary but strict naming convention with these files, to allow use of systemd specifiers and template files. In your case, you might simply hard-code what you want, if you are not looking for a generic solution, and all you want is bonding on a couple of interfaces. Still, when properly setup, you can individually "start" and "stop" any of the target units or network service units and get correct behavior. James
Re: [systemd-devel] Ordering services issue. Trying to start ptp4l in bonding setup fails as bonding appears to take a while.
On 12/1/21 13:27, Brian Hutchinson wrote: Maybe I'm missing something here but I don't see any way for me to "add targets" to this problem to solve it ... Well, of course, that's a problem. Maybe you can take the construction step by step. First, do you have *five* different unit files, the three different service files and the two target files? Second, reviewing your service file, we see references to "systemd-networkd". That suggests some confusion. "systemd-networkd" is a systemd hosted network management system, but it is NOT the same thing as using systemd AS the network management system. They are two completely different things. Choose one or the other. If you choose to use systemd-networkd, I cannot help you, and you are left to appeal to the systemd-networkd developers. Personally, this was the circumstance that I very much wanted to avoid, and is the motivation for using systemd directly, instead of systemd-networkd, or any other "canned" network management systems. When those systems break, you get to keep both pieces. If you choose to use systemd directly as the network management system, then you may have to build the system one step at a time. And if, in fact, there is some function needed that is fundamentally missing from systemd itself, that is a systemd bug that should be addressed specifically. For now, I don't know that that is the case here. Still, I have not tried yet to understand exactly what you mean by "use carrier state". But, there is another problem. It is not quite clear to me what your issue is here. On the one hand, you are asking about network bonding, and on the the other, you are referencing the Precision Time Protocol Boundary Clock and Ordinary Clock client service, ptp4l. Are you having a problem with network bonding? Or a problem with your ptp4l? James
Re: [systemd-devel] Ordering services issue. Trying to start ptp4l in bonding setup fails as bonding appears to take a while.
On 12/2/21 08:41, Brian Hutchinson wrote: Yup, I'm using systemd-networkd ... I think I have to in order to leverage network-online.target etc., and set up my network (bonding in this case) with .netdev and .network files in /etc/systemd/network. You don't "have" to do anything. It is a choice. Other network managers you might consider include: ConnMan netctl NetworkManager Wicd What kind of platform are you on? PC, embedded? Just Arch Linux on various PCs, but, if you are already running systemd, I don't expect that the hardware makes any difference. Can you give an example of what this would look like? I could, but, unless you want to abandon systemd-networkd for some reason, and also not consider some of the other popular network management systems, there would be no point. ... but I can also check carrier of my interfaces ... The kernel bonding module is its own thing, and automatically monitors the state of its slave devices and manages the state of its virtual interface. I don't know why you would want to bother with the carrier state of - presumably - an ethernet device, or whatever. If there were a problem with the bonding module, that would be an entirely separate issue. Of course, this all presupposes that you have actually selected and configured the correct options to the kernel bonding module, to provide the functionality you want with the hardware you are using. But that is nothing to do with systemd or with ptp4l. My issue is with systemd starting PTP before the bond is fully set up. As I mentioned, I cannot help you with systemd-networkd. I cannot find any author attributions in or to the systemd-networkd source, and none of the actual developers here appears to have volunteered any insight - and good luck with that. Still, you might read here for clues: https://wiki.archlinux.org/title/Systemd-networkd though, you will have to disregard the reference to "Wireless bonding", which was originally written by me, but is now quite obsolete, without updates, having been subsequently "vandalized" by a rather persistent inexperienced and arrogant user. James
[systemd-devel] systemd-journald namespace persistence
How do I create a persistent systemd-journald namespace? I have a backup service that is run by a systemd timer. I would like that to use it's own namespace. I can create the namespace manually using systemctl start systemd-journald@mynamespace.service. However I cannot find a way to do that successfully at boot time. I have tried a RequiredBy and a Requires in the timer unit but neither seem to work. Here are the relevant unit files. /etc/systemd/journ...@backup-and-csv.conf.d/backup-and-csv.conf [Journal] SystemMaxUse=1G SystemKeepFree=5G MaxRetentionSec=1day MaxFileSec=1week /etc/systemd/system/backup-and-csv.service [Unit] Description=InfluxDB incremental backup and csv service [Service] Type=oneshot User=pi WorkingDirectory=~ ExecStart=/home/pi/bin/backup-and-csv /etc/systemd/system/backup-and-csv.timer [Unit] Description=backup-and-csv timer Requires=systemd-journald@backup-and-csv.service After=systemd-journald@backup-and-csv.service [Timer] OnBootSec=8min OnUnitActiveSec=10min [Install] WantedBy=timers.target #RequiredBy=systemd-journald@backup-and-csv.service Any ideas?
[systemd-devel] Unit Names and Environment File Variable Names - Inconsistent Character Sets and Shortcomings with Unit Name Specifiers
cify, for instance, "bridge0STP= 'on'" and bridge1STP= 'off'" for some Template Unit File named "bridge@.service", for each instance of "bridge@bridge0.service" and "bridge@bridge1.service". I had considered resolving the problem with accessing the initial string in the Unit File name prefix by parsing the *entire* prefix string given by the "%p" specifier for the initial string, before the first dash "-" character. However, to retain the convention of matching the specifier "%p" and the Environment File Variable prefix naming just described, the Environment Variable prefix must then include the dash character "-", as implied in systemd.unit(5), for the "%p" specifier, "For instantiated units, this refers to the string before the first "@" character of the unit name", meaning the *entire* prefix string. This case might result, for example, from using some Unit File named "sit1-bridge@wlan0.service", where the matching "%p" Environment File Variable Name prefix becomes "sit1-bridge". However, attempting this, an error message will be encountered immediately: "Ignoring invalid environment assignment". Why is that? We take note of the Environment File variable name character set described in the man page systemd.exec(5), and also, the Unit Name character set described in systemd.unit(5): systemd.exec The names of the variables can contain ASCII letters, digits, and the underscore character. Variable names cannot be empty or start with a digit. systemd.unit The "unit prefix" must consist of one or more valid characters (ASCII letters, digits, ":", "-", "_", ".", and "\"). This character list for the Unit Name there is incomplete, due to the over specific reference to "unit prefix". The man page goes on to say: 'The name of the full unit is formed by inserting the instance name between "@" and the unit type suffix'. So the complete Unit Name character set then includes also the character "@". Of course, that is the cause of the "invalid environment assignment" error. The dash "-" character, which is allowed and required in the Unit Name character set, is *not* included or allowed in the Environment File character set. Why is that? That seems like a pointless and unnecessary limitation, having an Environment File Variable Name character set *different from* the Unit Name character set. Furthermore, notice that the "escaping" name specifiers, "%P", "%J", and "%I", cannot be used with the Environment File variable names generally, and cannot be used to work-around the dash "-" character limitation, because the backslash "\" character is also required and used with systemd String Escaping in Unit Names, and is also *not* included or allowed in the Environment File Variable Name character set. So, finally, unless there is some use case that can be discovered prohibiting this, it would be best to conform the Unit Name and the Environment File Variable Name character sets, by simply expanding the Environment File Variable Name character set to include and allow those additional characters, ":", "-", ".", "\", and "@", from the Unit Name character set. James
Re: [systemd-devel] Requires and After
On 1/2/19 3:21 AM, Reindl Harald wrote: > it's > pretty obvious when i REQUIRE something that it should be there when i > get started Not only is it not "obvious" that "something should be there", it is not true. You are confusing "Requires=" and "Requisite=". Some developers and some users are not native English speakers. In some cases, systemd terminology can be ... less than optimal, while, in other situations, users will simply misunderstand the conventional meaning of words. And, as I mentioned, "Requisite=" is broken in systemd, so that is a different issue. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires and After
On 1/2/19 12:50 AM, Olaf van der Spek wrote: > Activation by itself guarantees basically nothing. "Activation" guarantees activation. Activating, for instance, a service unit is quite a bit more significant than "nothing". >> Because, as far as I know, "Requisite=" is completely broken in systemd. > How is it broken? In the case of a service unit Requisite upon the existence of a device unit, systemd will completely ignore the dependency and merrily start the service unit anyway, which, in this case, uselessly attempts to operate upon a nonexistent device. Of course, the service unit will fail, outright, or after time-out, wasting compute resources, and producing lots of otherwise avoidable error messages. I have not really tested Requisite= with other unit type interactions, but then, I also don't know of anyone actually using Requisite= with any other use case. As far as I know, Requisite= is effectively a "no op". In the past, systemd developers have not been especially motivated to fix Requisite=, though without actually declaring "Won't Fix" - more of a "Never Used It Myself, Don't Really Care". ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires and After
On 1/2/19 5:38 PM, Tom H wrote: >> Some developers and some users are not native English speakers. In >> some cases, systemd terminology can be ... less than optimal, while, >> in other situations, users will simply misunderstand the conventional >> meaning of words. > You might not like how "Requisite=" is defined in systemd but that > doesn't mean that it's wrong or "less than optimal." Sorry, I did not mean to imply that *I* had an issue with the term "Requisite". Personally, my "pet peeve" is with the use of the term "Dead" to refer to units which are in an inactive state but which will become active in the future, as, for instance, logrotate.service. These states may be viewed with "systemctl list-units". For me, "dead" connotes a permanent state, in the same sense as "failed", in contrast to the terms "dormant", "sleeping", or "suspended". Something "dormant" may re-awaken. Something that is "dead" is not going to "wake-up" again - except in horror movies. I can only guess that Lennart wanted to create a more robust "hommage" to horror movies than that provided by the unix term "zombie". A unix zombie process has no chance of being re-animated. > What Reindl Harald was saying was that "Requires" should have an > implicit "After" because it wouldn't make sense for a.service to > require b.service but to start before b.service. I understand that Reindl has said that. But, just because Reindl does not have a use case in which a.service requires b.service *and* also starts before b.service, is no reason to prohibit other people from configuring such a use case. That would be the purview of religious zealots and political fundamentalists. Reindl might be uncomfortable with other people being "insane" and acting with "wild and crazy abandon", but, ... well, it's a big world out there. In my case, for instance, I have a service unit which I use, in combination, to configure hot-plug network interfaces. The service unit makes use of a target unit to sequence stages in the configuration process. This service unit Requires the target unit *and* must be run *Before* the target unit. With accumulated experience, people will learn new ways to use their tools. It's just going to take time. > You could even replace "Wants=" by "Requires=" if a.service can launch without b.service being up but cannot function without b.service being up. Often, the reason to choose between Wants= and Requires= is based upon the way units must be shut-down, not because of the way they start-up. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hibernator generator does not function on default Fedora install
On 15 May 2016 at 08:11, James Hogarth wrote: > > On 15 May 2016 06:32, "Andrei Borzenkov" wrote: > > > > 15.05.2016 06:36, Chris Murphy пишет: > > > On Thu, May 12, 2016 at 12:38 PM, James Hogarth < > james.hoga...@gmail.com> wrote: > > >> > > >> On 2 May 2016 18:58, "James Hogarth" wrote: > > >>> > > >>> > > >>> On 24 Apr 2016 21:31, "poma" wrote: > > >>>> > > >>>> On 20.04.2016 22:42, Chris Murphy wrote: > > >>>>> On Wed, Apr 20, 2016 at 1:50 PM, Tobias Hunger > > >>>>> wrote: > > >>>> > > >>>> [...] > > >>>> > > >>>>> Anyway, the most complete solution for BIOS, UEFI, and UEFI Secure > > >>>>> Boot systems, is fast startups as possible (which helps all kinds > of > > >>>>> use cases not just desktops), and then encourage DE's and app > makers > > >>>>> to support apps that save their own state without users having to > > >>>>> manually save files, and default to power off in low battery cases. > > >>>>> > > >>>>> I guess opensuse has some patches that aren't upstream yet that > > >>>>> support signed hibernation images for UEFI Secure Boot? Maybe > there's > > >>>>> a way forward at some point. But right now I'm just not seeing it. > > >>>>> There's some kind of brick wall in every direction with > hibernation. > > >>>>> > > >>>> > > >>>> :) > > >>>> "Lacus Hiemalis Edictum" patch-set actually existed for several > years. > > >>>> > > >>>> ... > > >>> > > >>> > > >>> > > >>> There is something that can be done in systemd to avoid the data loss > > >>> issue without having to add complexity to the generator. > > >>> > > >>> Add to the logind conditions for suspend-to-disk an additional one > to the > > >>> existing ones to ensure resume= is in the kernel cmdline. > > >>> > > >>> If it's not there refuse the hibernate and shutdown instead. At > least then > > >>> the processes would get shutdown properly with a TERM and not have a > power > > >>> cord pull situation (with sync) on them. > > >>> > > >>> That would be minimal change from present but avoid writing a resume > image > > >>> that will never be read. > > >> > > >> Since this seemed a nice solution to the problem, and it appeared to > make > > >> sense to validate the kernel argument would be there ready for the > generator > > >> for the resume before allowing the hibernate through logind there's > patches > > >> for Fedora and upstream systemd on this bug: > > >> > > >> https://bugzilla.redhat.com/show_bug.cgi?id=1332266 > > >> > > >> I've tested the F23 build with the patch on my laptop and it behaves > as I'd > > >> expect for an invalid resume=, no resume= and as valid resume= > > > > > > Seems like resume= should be checked to make sure the specified device > > > exists/is-valid for holding a hibernation image; just as important as > > > checking /sys/power/state and /sys/power/disk. > > > > > > > Both dracut and initramfs-tools can embed resume device information into > > initrd and do not require resume= on kernel command line. Refusing > > hibernation in this case will break these configurations. > > Perhaps a configuration entry in logind.conf in the event the kernel docs > of resume= aren't going to be used, such as in the dracut or > initramfs-tools examples you give? > > Those who don't want to use the systemd hibernate generator to resume can > disable the resume= check using that? > Okay following this line of thought there is now a pull request which defaults to validating resume= (since it seems sane to assume a system shipping systemd may use the systemd hibernation generator) but has systemd-sleep.conf with a config option to disable this validation: https://github.com/systemd/systemd/pull/3278 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] proposal to more precisely articulate the meaning of start and stop dependencies
his unit will be deactivated. [ X Starts Y and X StoppedBy Y ] Requisite Similar to Requires=. [ If one of the other units gets deactivated or its activation fails, this unit will be deactivated. ] However, if the units listed here are not started already, they will not be started and the transaction will fail immediately. [ Not currently working as documented. ] [ X StoppedBy Y ] BindsTo declares that this unit is stopped when any of the units listed suddenly disappears. [ X Starts Y and X StopppedBy Disappearing Y ] Conflicts If a unit has a Conflicts= setting on another unit, starting the former will stop the latter and vice versa. [ X Stops Y and X StoppedBy Starting Y ] Forward Stop RequiredBy See the description of ... Requires= in the [Unit] section for details. [ but with roles reversed ] [ If this unit gets deactivated or its activation fails, the other units will be deactivated. ] [ X StartedBy Y and X Stops Y ] Conflicts If a unit has a Conflicts= setting on another unit, starting the former will stop the latter ... [ X Stops Y and X StoppedBy Starting Y ] For instance, a proposed simple Forward Stop: Stops If this unit gets deactivated, the units listed here will be deactivated as well. [ X Stops Y ] [ Accepts a space-separated list of unit names. Note that a "Stops" dependency does not influence the order in which services are started, stopped, or restarted. This has to be configured independently with the After= or Before= options. When systemd restarts this unit, a "Stops" dependency will not interfere with the stop and start ordering of the listed units.] "Stops=" becomes important when working with a *related group* of unit files. Currently, systemd restricts passing unit names with "enable" template files, allowing only two parameters to be passed, to resolve template unit names. Either unit A declares "A Stops B", or unit B declares "B Stopped By A". For instance, "PartOf" can be used as a kind of "reverse reverse" stop, but then the unit file must "know" the name of the unit which is to initiate the stopping of "this" unit, which would imply possibly undesired customization of this unit file. It is at times preferable to write template unit file A with knowledge about the name of template unit B, instead of writing unit file B with knowledge about the name of template unit A. In that case, RequiredBy can be used. Other than this, of course, PartOf and RequiredBy are not "simple", in the sense that they impose additional functions, other than just "B Stops A" or "A Stops B". It is often easier to "think" in terms of simple functions. James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Clarification on unit state meanings
Hey all,
I noticed some odd ways `systemctl status` reports the status of units when
they're enabled via symlinks in target.{wants,requires} directories in /usr. In
particular, units with Install sections enabled this way show as disabled,
although they start with the target as expected.
I've done some work on a patch to fix this (also taking into account symlinks to
/dev/null in target.{wants,requires} directories) but I'm not entirely sure what
the exact correct behavior is. Apparently the table explaining unit states in
systemctl's manpage is out of date; is there a more complete listing anywhere of
what scenarios correspond to what states? If not, what's the expected behavior
here?
--
Thanks,
James Forcier
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Reading an "ao" signature message with the sdbus c library?
Hello,
Can someone please point me to the correct method for reading an "ao"
signature dbus message using the sd_bus C api?
I am trying to read all the network devices with the following call:
result = sd_bus_get_property(m_bus, "org.freedesktop.NetworkManager",
"/org/freedesktop/NetworkManager",
"org.freedesktop.NetworkManager",
"AllDevices", &error,
&msgCall, "ao");
I have tried:
char * ptr;
size_t size;
result = sd_bus_message_read_array(msgCall, 'o', &ptr, &size);
as well as:
result = sd_bus_message_read(msgCall, "ao", ptr);
but these both return an error. I am not sure what method to use to parse
the returned message when it is an array of path objects.
Please note this interface gives me the following when executed via the
busctl command:
[jjohnson@macbookpro]$ busctl --verbose get-property
org.freedesktop.NetworkManager /org/freedesktop/NetworkManager
org.freedesktop.NetworkManager AllDevices
ARRAY "o" {
OBJECT_PATH "/org/freedesktop/NetworkManager/Devices/1";
OBJECT_PATH "/org/freedesktop/NetworkManager/Devices/3";
OBJECT_PATH "/org/freedesktop/NetworkManager/Devices/11";
OBJECT_PATH "/org/freedesktop/NetworkManager/Devices/12";
};
Thanks!
Jimmy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reading an "ao" signature message with the sdbus c library?
Hello,
It looks like I figured out my problem, I have to use:
result = sd_bus_message_enter_container(msgCall, 'a', "o");
before I try reading the array with :
result = sd_bus_message_read(msgCall, "o", &ptr);
Thanks,
Jimmy
On Thu, Aug 17, 2017 at 1:43 PM, James Johnson
wrote:
> Hello,
>
> Can someone please point me to the correct method for reading an "ao"
> signature dbus message using the sd_bus C api?
>
> I am trying to read all the network devices with the following call:
>
> result = sd_bus_get_property(m_bus, "org.freedesktop.NetworkManager",
> "/org/freedesktop/NetworkManager",
> "org.freedesktop.NetworkManager",
> "AllDevices", &error,
> &msgCall, "ao");
> I have tried:
>
> char * ptr;
> size_t size;
>
> result = sd_bus_message_read_array(msgCall, 'o', &ptr, &size);
>
> as well as:
>
> result = sd_bus_message_read(msgCall, "ao", ptr);
>
> but these both return an error. I am not sure what method to use to parse
> the returned message when it is an array of path objects.
>
> Please note this interface gives me the following when executed via the
> busctl command:
>
> [jjohnson@macbookpro]$ busctl --verbose get-property
> org.freedesktop.NetworkManager /org/freedesktop/NetworkManager
> org.freedesktop.NetworkManager AllDevices
> ARRAY "o" {
> OBJECT_PATH "/org/freedesktop/NetworkManager/Devices/1";
> OBJECT_PATH "/org/freedesktop/NetworkManager/Devices/3";
> OBJECT_PATH "/org/freedesktop/NetworkManager/Devices/11";
> OBJECT_PATH "/org/freedesktop/NetworkManager/Devices/12";
> };
>
>
> Thanks!
> Jimmy
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Wireless mesh networks and link_carrier_gained
Hello, I have been testing the uses of systemd-networkd to configure wireless mesh networks, and have encountered a problem which manifests itself as a failure to correctly configure the additional dchp options offered by the inbuilt dhcpv4 server. This is related to the following commit. https://github.com/systemd/systemd/commit/45a9eac9a0c85c0c76b46388a530edd335ae44af#diff-12a3ecdf5af7aa9f8583c27ac442ca43 This commit makes an assumption that carrier has been lost before it can be gained. Mesh networks require configuration by external agents such as wpa_supplicant, hostapd or other command line tools. These can/will cause the carrier gained event to be generated. In the current code this causes an assertion which aborts further address configuration on the link. I have attempted to fix this by checking whether the dhcp server is running before starting it again. This has opened a can of worms regarding the use of carrier state in relation to the configuration state of the link, when in fact they are entirely unrelated. I think this has already been debated elsewhere, but I cannot find the reference. I am happy to share my code if anyone is interested. Roger ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Wireless mesh networks and link_carrier_gained
Hi, I will try to comply:-). I have been building forward from a raspbian stretch 232 version for my test nodes. But I should be able to switch to and ubuntu bionic system to test this. I would like to test in a fakeroot, container or stick; so I am thinking that I need look at mkosi. Any pointers on this paricular learning curve would be greatly appreciated. Roger ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires and After
> It's about Requires and After. I think a unit in Requires should imply > that unit in After too, otherwise the requirement isn't really met. > Is there a use case for Requires but not After? Olaf, previously, on GitHub, you had said: >> I think I understand Requires and After ... and, I would suggest that, no - or you would not be asking this question. systemd has two different classes of "dependencies": 1) "activation" dependencies, and 2) "ordering" dependencies. An activation dependency does not, a priori, have to obey any rules about ordering. There are not, automatically, any promises or guarantees about in what order service units, for instance, might be queued for execution, based upon a Requires= dependency. "Ordering" is an independent characteristic from "Activation". "Activation" only promises to enqueue a unit, and then, only if the unit is some kind of unit that can be "executed", such as a timer or service unit. In contrast, for instance, systemd is only a "passive observer" of a device unit. "enqueuing" a device unit for "activation" would make no sense in this context. A *service* unit that *creates* a device unit could be enqueued for activation, but not the device unit itself. If "A Requires B", and you don't like that "A" *might* get enqueued, or get executed, before "B", then add an "ordering" dependency. "Ordering dependencies", then, create guarantees about unit activation *ordering*. Are you sure that you were not wondering about "Requisite=", instead of "Requires="? Because, as far as I know, "Requisite=" is completely broken in systemd. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires and After
On 1/1/19 8:33 PM, Reindl Harald wrote: > "After" is a soft dependency, if that unit isn't enabled or don#t exist > at all it don't matter > > "Requires" is a hard dependency and it makes no sense not imply ordering And then, what do you mean by "soft dependency" and "hard dependency"? It sounds like you are calling an ordering dependency "soft" and an activation dependency "hard". I'm sorry, I do not understand what you mean by "makes no sense not imply ordering". Do you mean "to not imply ordering makes no sense"? In which case, are you saying that "an activation dependency must imply an ordering"? That would not be true. Activating a unit does not automatically imply or require that that unit be activated or deactivated in any particular order relative to any other unit. Did you also mean to say "If a unit is not active or does not exist then the ordering of that unit does not matter"? Well, the "ordering" of a nonexistent unit would not have any meaning. However there is also the case of an active unit that may become inactive, in addition to the case of an inactive unit that may become active. While the order of activation or deactivation, relative to other units, of a unit that exists has meaning, that order may not, a priori, be of any importance or consequence. But I would not go so far as to say that the order of activation of an inactive unit does not matter. The order of activation of an inactive unit may actually be important, in which case, an ordering dependency can be specified. So, I think that I am missing your point, with respect to "soft" and "hard" dependencies. Maybe you could express your meaning in another way? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] socket activated services and correct dependency mapping
Hi, I'm in the process of adding systemd native sockets to a service (rather than using inetd compatibility) and am trying to get my head around the proper way to configure the unit files so that the socket is optional rather than required but allowing restarting of the socket unit. https://github.com/yrutschle/sslh/pull/56 [root@hoglaptop ~]# systemctl cat sslh.socket # /etc/systemd/system/sslh.socket [Socket] ListenStream=10.81.60.229:443 ListenStream=10.81.60.229:444 ListenStream=10.81.60.229:445 ListenStream=10.81.60.229:446 ListenStream=10.81.60.229:447 FreeBind=true [Install] WantedBy=sockets.target [root@hoglaptop ~]# systemctl cat sslh.service # /etc/systemd/system/sslh.service [Service] ExecStart=/home/hogarthj/workspace/github-sslh/sslh-fork -v -f --ssh 127.0.0.1:22 KillMode=process I want a user to be able to systemctl start sslh and use listening addresses in /etc/sslh.cfg as always (so I'm reluctant to put a straight Sockets= in the service unit file) but as it stands the lazy activation of sslh works a treat however once the service is activated it is listening on the sockets so it's not possible to systemctl restart sslh.socket to change an IP or add a port without stopping sslh.service first ... Is what I'm trying to do flat out a bad idea and impossible or is there a way of ordering this in such a way that a restart of sslh.socket stops sslh.service in the process ... or something to attain the goal of a restartable socket unit and an associated that has not explicit need of the socket? Regards, James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] socket activated services and correct dependency mapping
On 24 July 2015 at 10:38, James Hogarth wrote: > Hi, > > I'm in the process of adding systemd native sockets to a service > (rather than using inetd compatibility) and am trying to get my head > around the proper way to configure the unit files so that the socket > is optional rather than required but allowing restarting of the socket > unit. > > https://github.com/yrutschle/sslh/pull/56 > > [root@hoglaptop ~]# systemctl cat sslh.socket > # /etc/systemd/system/sslh.socket > [Socket] > ListenStream=10.81.60.229:443 > ListenStream=10.81.60.229:444 > ListenStream=10.81.60.229:445 > ListenStream=10.81.60.229:446 > ListenStream=10.81.60.229:447 > FreeBind=true > > [Install] > WantedBy=sockets.target > > [root@hoglaptop ~]# systemctl cat sslh.service > # /etc/systemd/system/sslh.service > [Service] > ExecStart=/home/hogarthj/workspace/github-sslh/sslh-fork -v -f --ssh > 127.0.0.1:22 > KillMode=process > > I want a user to be able to systemctl start sslh and use listening > addresses in /etc/sslh.cfg as always (so I'm reluctant to put a > straight Sockets= in the service unit file) but as it stands the lazy > activation of sslh works a treat however once the service is activated > it is listening on the sockets so it's not possible to systemctl > restart sslh.socket to change an IP or add a port without stopping > sslh.service first ... > > Is what I'm trying to do flat out a bad idea and impossible or is > there a way of ordering this in such a way that a restart of > sslh.socket stops sslh.service in the process ... or something to > attain the goal of a restartable socket unit and an associated that > has not explicit need of the socket? > > Regards, > > James And for the sake of google searches and the archives within 5 minutes of sending the email I worked out my answer ... Adding Before=sslh.service to the socket and PartOf=sslh.socket to the service gets me the behavior I was searching for. [root@hoglaptop ~]# systemctl cat sslh.service # /etc/systemd/system/sslh.service [Unit] PartOf=sslh.socket [Service] ExecStart=/usr/sbin/sslh -v -f --ssh 127.0.0.1:22 KillMode=process CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_NET_ADMIN CAP_SETGID CAP_SETUID PrivateTmp=true PrivateDevices=true ProtectSystem=full ProtectHome=true [root@hoglaptop ~]# systemctl cat sslh.socket # /etc/systemd/system/sslh.socket [Unit] Before=sslh.service [Socket] ListenStream=10.81.60.229:443 ListenStream=10.81.60.229:444 ListenStream=10.81.60.229:445 ListenStream=10.81.60.229:446 ListenStream=10.81.60.229:447 FreeBind=true [Install] WantedBy=sockets.target Which is great! Now I can start as a non-root user and not have to drop user after binding low ports. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] socket activated services and correct dependency mapping
On 24 Jul 2015 11:55, "Dimitri John Ledkov" wrote: > > On 24 July 2015 at 10:38, James Hogarth wrote: > > I want a user to be able to systemctl start sslh and use listening > > addresses in /etc/sslh.cfg as always (so I'm reluctant to put a > > straight Sockets= in the service unit file) but as it stands the lazy > > You can write a generator which will parse /etc/sshlh.cfg and drop e.g. > $1/sslh.socket.d/sshlh-cfg.conf > > with contents > [Socket] > ListenStream=... > > That way e.g. you can enforce that config file is still fully honoured > as canonical place to set ports. > > Checkout generators at > http://www.freedesktop.org/wiki/Software/systemd/Generators/ > > Or e.g. look at /run/systemd for things that got generated by various > stuff (e.g. like the fstab generator). > Oh I love that idea! It didn't even occur to me but it's perfect for it... The configuration file is designed to be read with libconfig anyway which is already on the system making it pretty trivial. Thanks for that reminder - will arrange this later on this week :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd hibernator generator does not function on default Fedora install
Hi all, There's been some discussion today about the impact of https://bugzilla.redhat.com/show_bug.cgi?id=1206936 and where the problem actually lies. The issue lies specifically with hibernate and affects all Fedora systems regardless of hardware (it's reproducible in a VM). The hibernate image gets written to swap correctly but hibernate-resume-generator.c looks specifically for 'resume' in /proc/cmdline to determine a) if any check shoudl even happen and b) which block device to check. When Fedora is installed anaconda does not write a resume= line to GRUB_CMDLINE_LINUX in /etc/default/grub or to the default kernel stanza for grubby to later duplicate. Dracut cmdline module does produce a resume= line but it appears this occurs too late for the generator to pick up. The end result is that without manual intervention to add an appropriate resume= line it's impossible to resume from hibernation on Fedora, and the critical battery behaviour (configured via /etc/Upower/Upower.conf and visible in upower -d) is to HybridSleep. Is it feasible for systemd to have the generator pick a swap image regardless of resume being present or not? If so the dracut cmdline coming later than the hibernate generator wouldn't be a problem. Cheers, James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hibernator generator does not function on default Fedora install
On 19 Apr 2016 04:53, "Andrei Borzenkov" wrote: > > 19.04.2016 01:19, James Hogarth пишет: > > Hi all, > > > > There's been some discussion today about the impact of > > https://bugzilla.redhat.com/show_bug.cgi?id=1206936 and where the problem > > actually lies. > > > > The issue lies specifically with hibernate and affects all Fedora systems > > regardless of hardware (it's reproducible in a VM). > > > > The hibernate image gets written to swap correctly > > but hibernate-resume-generator.c looks specifically for 'resume' in > > /proc/cmdline to determine a) if any check shoudl even happen and b) which > > block device to check. > > > > When Fedora is installed anaconda does not write a resume= line > > to GRUB_CMDLINE_LINUX in /etc/default/grub or to the default kernel stanza > > for grubby to later duplicate. > > > > Dracut cmdline module does produce a resume= line but it appears this > > occurs too late for the generator to pick up. > > > > dracut cmdline is internal to dracut, so external programs do not see it. > That would explain it, however it's somewhat confusing on the bug that dracut was pointed to as a place for a fix and the requests for dracut --print-cmdline if it had no affect. > > The end result is that without manual intervention to add an appropriate > > resume= line it's impossible to resume from hibernation on Fedora, and the > > critical battery behaviour (configured via /etc/Upower/Upower.conf and > > visible in upower -d) is to HybridSleep. > > > > Is it feasible for systemd to have the generator pick a swap image > > regardless of resume being present or not? If so the dracut cmdline coming > > later than the hibernate generator wouldn't be a problem. > > > > Well, TBH the simplest solution is really to add resume= to kernel > command line. Otherwise let dracut install own generator that does > exactly the same when resume= is missing as real kernel parameter. In > both cases I do not think it is something that needs to be implemented > in systemd. The generator and the actual resume is already in systemd and the anaconda folks on the bug did not think it should be with them and that adding resume= would not be the correct fix (of course that additionally has the issue if fixed there of the current broken installs and how anaconda only creates that file on install). Seeing as systemd decides the swap to hibernate to in the first place, can't the same logic be used to locate the swap to resume from? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hibernator generator does not function on default Fedora install
On 19 Apr 2016 08:05, "Andrei Borzenkov" wrote: > > On Tue, Apr 19, 2016 at 9:45 AM, James Hogarth wrote: > > > > > Seeing as systemd decides the swap to hibernate to in the first place, can't > > No, it does not. Device to hibernate to is set by previous attempt to > resume from. This device must come from somewhere. Last device someone > attempted to resume from will be used in subsequent attempt to > hibernate. > > So I would definitely be against anyone blindly poking around at every > available partition because later kernel will overwrite content of > this partition when hibernation is requested. > I agree that would be messy. What about the first hibernation when no previous resume has occurred? > > the same logic be used to locate the swap to resume from? > > There is no logic here. User decides where to resume from and later > the same device is used to hibernate to. > > systemd already has all needed knobs to configure this. Is there any > reason you refuse to use these knobs? Well it has to pick something the first time. I would urge you to read the bug and the relevant blocker discussion notes. I've added resume= to my cmdline and am happy with that, however every Fedora user who is not specifically aware of the need to do that has a broken hibernate, with the upower configuration being to hybrid sleep (so effectively hibernate) when battery levels are critical. The "broken default application behaviour" could be "fixed" by changing upower to shutdown instead. The user would then be notified of the shutdown and not that hibernate would happen. This would satisfy the Fedora release criteria but would still leave a broken systemctl hibernate with an unintuitive fix. It would also mean the big "don't change this file" warning in Upower.conf would put people off enabling that behaviour, but to be honest is out of the scope of this issue. It could also be fixed by anaconda adding resume= to the grub configuration like it already has to for the root device. The anaconda developers have already pushed against this and it would only fix fresh installs anyway. Dracut thought they'd fix it in cmdline but of course that doesn't act in a way any others can tell the changes. This leaves systemd as the component that has generator and the actual code that loads the resume image info the kernel. Although I'm fine I'd like to see other Fedora users not have a broken behaviour on their systems. Given your insights it would be valuable if you, or another systemd dev, would comment on the bug with the problem of "fixing the generator" so we can work out where the correct fix lies and the appropriate maintenance team to fix it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hibernator generator does not function on default Fedora install
On 20 Apr 2016 05:47, "Chris Murphy" wrote: > > On Tue, Apr 19, 2016 at 4:10 AM, Lennart Poettering > wrote: > > > > > So what precisely are you proposing? That we actively search for the > > swap partition in the hibernate-resume generator? > > I think the main thing James is after, I know I'm in this camp, is > understanding all the parts and how they interrelate. Fedora doesn't > support it at all, and James it trying to figure out why not, and > needs sufficient understanding of hibernation in order to determine > which groups need to do what to make it work reliably or at least fail > safe, neither of which appear to be true right now. > Nothing even as grandiose as that. I'm just looking for the best way to avoid Fedora laptop users unexpectedly losing their data. I spent some time reading through the kernel docs on this last night, as ultimately that's what we rely on. https://www.kernel.org/doc/Documentation/power/ Regardless of how the hibernate generator might potentially be changed to attempt to locate a valid swap partition with hibernate data, or how difficult that may be given the nature of running in an initrd and as a generator, we still need to follow the kernel requirements for suspend-to-disk. The documented way there is resume= so I feel that's the best way to direct the Fedora bug as it stands. If the anaconda guys disagree then I think the best course of action to avoid unexpected data loss is to have upower not default to HybridSleep but go straight to shutdown. I'll update the bug comments later today with the results of this thread. Thank you all for your input. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hibernator generator does not function on default Fedora install
On 20 April 2016 at 10:20, Lennart Poettering wrote: > On Wed, 20.04.16 08:00, James Hogarth (james.hoga...@gmail.com) wrote: > > > Regardless of how the hibernate generator might potentially be changed to > > attempt to locate a valid swap partition with hibernate data, or how > > difficult that may be given the nature of running in an initrd and as a > > generator, we still need to follow the kernel requirements for > > suspend-to-disk. > > > > The documented way there is resume= so I feel that's the best way to > direct > > the Fedora bug as it stands. > > > > If the anaconda guys disagree then I think the best course of action to > > avoid unexpected data loss is to have upower not default to HybridSleep > but > > go straight to shutdown. > > > > I'll update the bug comments later today with the results of this thread. > > I am still open to add searching for the resume swap partition to the > generator, but only where this may be done reliably, i.e. GPT, but not > MBR. And we should either define a new GPT partition type UUID for > "hibernation swap", or reuse the swap GPT partition type UUID but then > set a flag in it which marks it for use in resume= usage. > > Given that Windows mandates EFI in modern laptops (and thus GPT), I am > pretty sure you can cover large majority of systems with that. But > again, it won't be a 100% solution, since there are of course people > who still use MBR. > > > It seems like it'd be a good idea with the GPT type (though there would still be an issue of someone dualbooting between linux distros of course). There is a large Fedora user base without EFI of course, or with legacy boot enabled even if they have an EFI capable laptop so in terms of the bug itself we'll need a solution that will help them too. James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hibernator generator does not function on default Fedora install
On 24 Apr 2016 21:31, "poma" wrote: > > On 20.04.2016 22:42, Chris Murphy wrote: > > On Wed, Apr 20, 2016 at 1:50 PM, Tobias Hunger wrote: > > [...] > > > Anyway, the most complete solution for BIOS, UEFI, and UEFI Secure > > Boot systems, is fast startups as possible (which helps all kinds of > > use cases not just desktops), and then encourage DE's and app makers > > to support apps that save their own state without users having to > > manually save files, and default to power off in low battery cases. > > > > I guess opensuse has some patches that aren't upstream yet that > > support signed hibernation images for UEFI Secure Boot? Maybe there's > > a way forward at some point. But right now I'm just not seeing it. > > There's some kind of brick wall in every direction with hibernation. > > > > :) > "Lacus Hiemalis Edictum" patch-set actually existed for several years. > > ... There is something that can be done in systemd to avoid the data loss issue without having to add complexity to the generator. Add to the logind conditions for suspend-to-disk an additional one to the existing ones to ensure resume= is in the kernel cmdline. If it's not there refuse the hibernate and shutdown instead. At least then the processes would get shutdown properly with a TERM and not have a power cord pull situation (with sync) on them. That would be minimal change from present but avoid writing a resume image that will never be read. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] when/where was support for assigning "ethX" names removed?
> > On 12 May 2016 18:28, "Chris Friesen" wrote: > > > > Hi, > > > > Could someone point me to the commit that removed support for assigning "ethX" names based on MAC addresses? > > > > Alternately, can someone suggest a way to get equivalent behaviour (the ability to set "ethX" names based on MAC address) using the current infrastructure? (Preferably as of RHEL 7, so systemd 219 plus a bunch of patches.) > > > > The back story is that we've got a lot of scripts/tools that currently assume the "ethX" naming, and while we will eventually sort it out we really don't want to do it right now. The previous method of assigning "ethX" names was working well for our use-case (though I realize it had issues more generally). > > For future reference when dealing with EL systems it's best to check the Red Hat documentation in the first instance: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hibernator generator does not function on default Fedora install
On 2 May 2016 18:58, "James Hogarth" wrote: > > > On 24 Apr 2016 21:31, "poma" wrote: > > > > On 20.04.2016 22:42, Chris Murphy wrote: > > > On Wed, Apr 20, 2016 at 1:50 PM, Tobias Hunger < tobias.hun...@gmail.com> wrote: > > > > [...] > > > > > Anyway, the most complete solution for BIOS, UEFI, and UEFI Secure > > > Boot systems, is fast startups as possible (which helps all kinds of > > > use cases not just desktops), and then encourage DE's and app makers > > > to support apps that save their own state without users having to > > > manually save files, and default to power off in low battery cases. > > > > > > I guess opensuse has some patches that aren't upstream yet that > > > support signed hibernation images for UEFI Secure Boot? Maybe there's > > > a way forward at some point. But right now I'm just not seeing it. > > > There's some kind of brick wall in every direction with hibernation. > > > > > > > :) > > "Lacus Hiemalis Edictum" patch-set actually existed for several years. > > > > ... > > > > There is something that can be done in systemd to avoid the data loss issue without having to add complexity to the generator. > > Add to the logind conditions for suspend-to-disk an additional one to the existing ones to ensure resume= is in the kernel cmdline. > > If it's not there refuse the hibernate and shutdown instead. At least then the processes would get shutdown properly with a TERM and not have a power cord pull situation (with sync) on them. > > That would be minimal change from present but avoid writing a resume image that will never be read. Since this seemed a nice solution to the problem, and it appeared to make sense to validate the kernel argument would be there ready for the generator for the resume before allowing the hibernate through logind there's patches for Fedora and upstream systemd on this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1332266 I've tested the F23 build with the patch on my laptop and it behaves as I'd expect for an invalid resume=, no resume= and as valid resume= ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd hibernator generator does not function on default Fedora install
On 15 May 2016 06:32, "Andrei Borzenkov" wrote: > > 15.05.2016 06:36, Chris Murphy пишет: > > On Thu, May 12, 2016 at 12:38 PM, James Hogarth wrote: > >> > >> On 2 May 2016 18:58, "James Hogarth" wrote: > >>> > >>> > >>> On 24 Apr 2016 21:31, "poma" wrote: > >>>> > >>>> On 20.04.2016 22:42, Chris Murphy wrote: > >>>>> On Wed, Apr 20, 2016 at 1:50 PM, Tobias Hunger > >>>>> wrote: > >>>> > >>>> [...] > >>>> > >>>>> Anyway, the most complete solution for BIOS, UEFI, and UEFI Secure > >>>>> Boot systems, is fast startups as possible (which helps all kinds of > >>>>> use cases not just desktops), and then encourage DE's and app makers > >>>>> to support apps that save their own state without users having to > >>>>> manually save files, and default to power off in low battery cases. > >>>>> > >>>>> I guess opensuse has some patches that aren't upstream yet that > >>>>> support signed hibernation images for UEFI Secure Boot? Maybe there's > >>>>> a way forward at some point. But right now I'm just not seeing it. > >>>>> There's some kind of brick wall in every direction with hibernation. > >>>>> > >>>> > >>>> :) > >>>> "Lacus Hiemalis Edictum" patch-set actually existed for several years. > >>>> > >>>> ... > >>> > >>> > >>> > >>> There is something that can be done in systemd to avoid the data loss > >>> issue without having to add complexity to the generator. > >>> > >>> Add to the logind conditions for suspend-to-disk an additional one to the > >>> existing ones to ensure resume= is in the kernel cmdline. > >>> > >>> If it's not there refuse the hibernate and shutdown instead. At least then > >>> the processes would get shutdown properly with a TERM and not have a power > >>> cord pull situation (with sync) on them. > >>> > >>> That would be minimal change from present but avoid writing a resume image > >>> that will never be read. > >> > >> Since this seemed a nice solution to the problem, and it appeared to make > >> sense to validate the kernel argument would be there ready for the generator > >> for the resume before allowing the hibernate through logind there's patches > >> for Fedora and upstream systemd on this bug: > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=1332266 > >> > >> I've tested the F23 build with the patch on my laptop and it behaves as I'd > >> expect for an invalid resume=, no resume= and as valid resume= > > > > Seems like resume= should be checked to make sure the specified device > > exists/is-valid for holding a hibernation image; just as important as > > checking /sys/power/state and /sys/power/disk. > > > > Both dracut and initramfs-tools can embed resume device information into > initrd and do not require resume= on kernel command line. Refusing > hibernation in this case will break these configurations. Perhaps a configuration entry in logind.conf in the event the kernel docs of resume= aren't going to be used, such as in the dracut or initramfs-tools examples you give? Those who don't want to use the systemd hibernate generator to resume can disable the resume= check using that? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] gentoo openrc
>>>>> "RR" == Reno Reckling writes: RR> I am currently working on a way to extract the dependencies from RR> openrc init scripts to be able to support the automatic init.d RR> fallbacks in gentoo. RR> The extracting and bash scripting part was fairly easy as it mainly RR> includes a 100 lines bash script to parse the init script. IIRC, one of the points of the openrc work -- as posted to the lists -- was to eliminate the need for bash(1) during init. You should be able to parse the depend() functions w/o using a shell. The runscript(8) src might provide useful clues. At worst one could integrate code from something like dash(1) to parse the scripts and build up the depend graph. (Writing from memory of discussions promoting openrc over baselayout-1, I haven't looked at the openrc code in a *long* time) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] gentoo openrc
>>>>> "RR" == Reno Reckling writes: RR> So there is in fact some shellscript-calling involved. Perhaps the goal exagerated the eventual code. Or maybe the backlash changed the plans. (I'd forgotten until just now, but the init.d/net code, especially, was very bash-riented and they didn't want to have the change that fact.) RR> The main question is, whether i try to reuse the named shell script RR> and copy some portions of the openrc source, or whether i rewrite RR> the deptree handling code as the openrc code would bloat the systemd RR> tree. I have to agree with avoiding bloat. A closer look shows that you were most likely on the right track. (init.d/net.lo may make the heaviest usage of bashisms.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 'tasks' as first-order objects?
On 14 August 2010 01:38, Lennart Poettering wrote: > On Fri, 13.08.10 16:22, Adam Spragg (a...@spra.gg) wrote: > >> >> On Friday 13 Aug 2010 15:54:28 Lennart Poettering wrote: >> > On Fri, 13.08.10 00:18, Adam Spragg (a...@spra.gg) wrote: >> > > > > So [auditctl] would be something to set to "Type=finish" and >> > > > > "ValidNoProcess=no". >> > > > > >> > > > > (Oh, and if you have a better suggestion for a name of >> > > > > ValidNoProcess= I am all ears too!) >> > > >> > > 'RequiresProcess='? >> > >> > Hmm, that would turn around the logic. I'd rathe have an option that >> > defaults to "off", and when specified may be set on "on". >> >> Maybe. >> >> I have a long-ingrained dislike of boolean flags/variables/settings that >> include a "no" or "not" in them. "notfound" is a particular peeve of mine in >> a >> codebase I'm currently working on. Deciphering "!notfound" and "notfound" >> unnecessarily requires more brain cycles than "found" and "!found" would >> have. >> I have to stop and check I'm doing what I think I'm doing every time I come >> across it. I also have the same problem with UIs that have checkboxes marked >> "disable feature X". It's just *awkward* - more so than it needs to >> be. > > Yes, I share the same belief, which is one of the reasons I'd be happy > to rename this. How about "Processless="? -- James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Possible systemd segfault switching from 216 to 219 in fedora upgrade
Hi, I spent some time last night trying to track down the issue preventing fedup from fedora 21 to 22: https://bugzilla.redhat.org/show_bug.cgi?id=1185604 I'm pretty sure I've tracked it down to when switch-root is called and systemd-219 gets executed being passed the serialised state of systemd-216 in the process. Unfortunately when this occurs the whole system is brought to a halt making further debugging tricky. Any ideas on how I might reproduce on a reduced an BBS simplified testcase for the behaviour involved? There is strace of pid1 from just before the switch-root to the crash along with coredumps that have been generated on the bug. These tests were carried out with enforcing=0 at the kernel command line so I'm reasonably confident the bug is not SELinux related. Cheers, James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Possible systemd segfault switching from 216 to 219 in fedora upgrade
On 5 March 2015 at 15:10, Lennart Poettering wrote: > > > Right before switch rooting systemd will kill all remaining processes > of the initrd, including the strace, hence the strace logs aren't that > useful either, they end before the transition. > > Please boot with "systemd.log_level=debug systemd.log_target=kmsg" on > the kernel cmdline, which ensures the logs go to the kernel log > buffer. And then please provide the output this generates here. > > Also see: > > http://freedesktop.org/wiki/Software/systemd/Debugging/ > > Thanks Lennart - good point about the strace being killed before the interesting bit... This makes it annoyingly tricky to see what is happening as the systemd-219 binary gets loaded... Screenshot has been attached to the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1185604#c22 Doesn't show much though - just a SEGV reported by pid1 that immediately results in execution being halted. Tried to put together a reduced testcase via a yum installroot style container to switch-root into to see what that behaviour is like and do see a segfault - not certain if this is the same being seen during the fedup switch-root though... Any ideas to get a better grasp on this? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Possible systemd segfault switching from 216 to 219 in fedora upgrade
On 5 March 2015 at 17:07, James Hogarth wrote: > On 5 March 2015 at 15:10, Lennart Poettering wrote: >> >> >> Right before switch rooting systemd will kill all remaining processes >> of the initrd, including the strace, hence the strace logs aren't that >> useful either, they end before the transition. >> >> Please boot with "systemd.log_level=debug systemd.log_target=kmsg" on >> the kernel cmdline, which ensures the logs go to the kernel log >> buffer. And then please provide the output this generates here. >> >> Also see: >> >> http://freedesktop.org/wiki/Software/systemd/Debugging/ >> >> > > Thanks Lennart - good point about the strace being killed before the > interesting bit... > > This makes it annoyingly tricky to see what is happening as the > systemd-219 binary gets loaded... > > Screenshot has been attached to the bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=1185604#c22 > > Doesn't show much though - just a SEGV reported by pid1 that > immediately results in execution being halted. > > Tried to put together a reduced testcase via a yum installroot style > container to switch-root into to see what that behaviour is like and > do see a segfault - not certain if this is the same being seen during > the fedup switch-root though... > > Any ideas to get a better grasp on this? So it's actually slightly more complicated than I had originally thought (thanks #fedora-qa) after a brief chat with wwoods. The path taken in the process is the initrd used by fedup is built from the newer Fedora release (ie in the present testing this contains systemd-219). This starts up and then carries out a switch-root to the actual system which in this case has systemd-216. The reason for this is to simplify finding out where mount points are for a clean upgrade - it's been felt the easiest way is to just 'ask' the actual system to do this. After the mount points are all up switch-root is used to switch back to the initrd setup so that the upgrades can be carried out on teh non-running system... so we have a systemd-216 to 219 transition here. This naturally means that the serialization/deserialization needs to be forwards *and* backwards compatible between 216 and 219 for this to work. From the logs that I've pulled (see the various attachments in https://bugzilla.redhat.com/show_bug.cgi?id=1185604 for them) it would appear the 219 -> 216 process is fine but then switching back from 216 -> 219 is failing with the associated segfault. There appears to be a couple of options here: 1) Try to get a workable reduced test case or better debugging from the 216 -> 219 transition to work out why that is failing. 2) Have some sort of generator or call or similar that allows the systemd-newer in the initrd to parse the unit files and fstab of the installed system and carry out any mounting itself rather than using switch-root to the installed system and asking it to do so. This would then eliminate the jumping backwards and forwards between systemd versions during the upgrade process. Any thoughts on either of these options to try to get a way forwards... or is there any additional debugging or diagnostics that I can provide to help? Cheers, James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Possible systemd segfault switching from 216 to 219 in fedora upgrade
On 8 March 2015 at 22:32, Lennart Poettering wrote: > On Thu, 05.03.15 22:07, James Hogarth (james.hoga...@gmail.com) wrote: > >> > Tried to put together a reduced testcase via a yum installroot style >> > container to switch-root into to see what that behaviour is like and >> > do see a segfault - not certain if this is the same being seen during >> > the fedup switch-root though... >> > >> > Any ideas to get a better grasp on this? >> >> So it's actually slightly more complicated than I had originally >> thought (thanks #fedora-qa) after a brief chat with wwoods. >> >> The path taken in the process is the initrd used by fedup is built >> from the newer Fedora release (ie in the present testing this contains >> systemd-219). >> >> This starts up and then carries out a switch-root to the actual system >> which in this case has systemd-216. > > We don't support downgrades really. The reexec stuff should work fine > for upgrades, but downgrades is nothing we could even remotely test, > or even think/know about to work. fedup really shouldn't do that. > Chris Murphy's email highlights why this gets even trickier when considering n-2 or greater. The brief chat a few of us had on #fedora-qa revealed that generally the new->-old->new switching is not really liked but a quick brainstorm didn't give many other ideas to handle the issue behind it (see next response about that). >> The reason for this is to simplify finding out where mount points are >> for a clean upgrade - it's been felt the easiest way is to just 'ask' >> the actual system to do this. >> >> After the mount points are all up switch-root is used to switch back >> to the initrd setup so that the upgrades can be carried out on teh >> non-running system... so we have a systemd-216 to 219 transition here. >> >> This naturally means that the serialization/deserialization needs to >> be forwards *and* backwards compatible between 216 and 219 for this to >> work. > > Yeah, but no. Allowing uprgades is one thing, allowing downgrades a > completely different one, and nothing we want to support. > >> >From the logs that I've pulled (see the various attachments in >> https://bugzilla.redhat.com/show_bug.cgi?id=1185604 for them) it would >> appear the 219 -> 216 process is fine but then switching back from 216 >> -> 219 is failing with the associated segfault. >> >> There appears to be a couple of options here: >> >> 1) Try to get a workable reduced test case or better debugging from >> the 216 -> 219 transition to work out why that is failing. >> 2) Have some sort of generator or call or similar that allows the >> systemd-newer in the initrd to parse the unit files and fstab of the >> installed system and carry out any mounting itself rather than using >> switch-root to the installed system and asking it to do so. This would >> then eliminate the jumping backwards and forwards between systemd >> versions during the upgrade process. > > I am not really sure I follow here... > So the question and requirement that is attempting to be filled is: In the fedup initrd environment mount all filesystems the system being upgraded has. Given the mix between fstab, mount entries and GPT generated the tricky thing is how to ensure all relevant filesystems are mounted before the upgrade process is called to ensure that all files covered by the rpms do get updated and nothing get accidentally left out. Following along the idea of some sort of service to parse fstab, mount units and GPT type gets you to something approaching the already solved problem of how systemd handles mounts overall. So the approach taken was to just switch-root to the installed system's systemd and let it run it's generators and so on to handle the mounting itself and then after that is complete switch-root back out to the fedup environment to carry out the actual upgrade offline. I hope that explanation makes the thought process behind that clearer. So the question underlying this is what is a better way to handle checking these mount points - ideally in a way that avoids the switch-root shuffle? As an example my own thinking currently is along the lines of "Could systemd be passed a 'system is mounted here' option perhaps and have a systemd process started to carry out all mounting defined in the units/fstab/GPT relative to that?" >> Any thoughts on either of these options to try to get a way >> forwards... or is there any additional debugging or diagnostics that I >> can provide to help? > > Well, it might be possible to get coredump out of the thing, by > disab
[systemd-devel] Systemd-nspawn -- Unable to initialize virtual ethernet connection
Hello! I am trying to setup and play around with some of the private networking features of systemd, and one of the big thinks I'm trying to get working is the virtual ethernet links. For some reason though, I am unable to start a containder using a virtual ethernet link. My attempt is included below. --- [root@utility01 ~]# systemd-nspawn --network-veth -bD /home/proxy.ddwrt01 Spawning container proxy.ddwrt01 on /home/proxy.ddwrt01. Press ^] three times within 1s to kill container. Failed to add netlink interface name: Invalid argument --- Dropping the --network-veth option: --- [root@utility01 ~]# systemd-nspawn -bD /home/proxy.ddwrt01 Spawning container proxy.ddwrt01 on /home/proxy.ddwrt01. Press ^] three times within 1s to kill container. systemd 216 running in system mode. (+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN ) Detected virtualization 'systemd-nspawn'. Detected architecture 'arm'. Welcome to Arch Linux ARM! --- Some additional environment information: [root@utility01 ~]# uname -a Linux utility01 3.12.26-2-ARCH #1 PREEMPT Sun Aug 31 22:36:40 MDT 2014 armv6l GNU/Linux [root@utility01 ~]# pacman -Q systemd systemd 216-3 I'm happy to run any additional tests or provide any additional information needed to help try to reproduce. Thanks in advance for any help! -- James Lott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd -- Unable to create VLAN device
Hello again! I've been eager to play with networking features, in case you couldn't tell ;) This patricular issue seems separate from my first one though, so I thought it would be best to discuss separately. I am trying to use systemd-networkd to essentially replace vconfig. I am using eth0 as a trunked link and am trying to setup a pair of VLAN devices to receive the taged frames. It seems that the VLAN netdevs are silently failing to be created. Sep 19 09:47:34 utility01 systemd[1]: Starting Network Service... Sep 19 09:47:34 utility01 systemd-networkd[776]: [/etc/systemd/network/vlan1.network:6] VLAN could not be found, ignoring assignment: 1 Sep 19 09:47:34 utility01 systemd-networkd[776]: [/etc/systemd/network/vlan0.network:6] VLAN could not be found, ignoring assignment: 0 Sep 19 09:47:34 utility01 systemd-networkd[776]: [/etc/systemd/network/eth0.network:6] VLAN could not be found, ignoring assignment: 1 Sep 19 09:47:34 utility01 systemd-networkd[776]: [/etc/systemd/network/eth0.network:7] VLAN could not be found, ignoring assignment: 0 Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0.0 : gained carrier Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0: gained carrier Sep 19 09:47:34 utility01 systemd-networkd[776]: lo : gained carrier Sep 19 09:47:34 utility01 systemd[1]: Started Network Service. Although I strongly believe this to be an error I am making somewhere, I have read and re-read all of the systemd-networkd man pages, and cannot for the life of me figure out where I went wrong. Any help is much appreciated! Additional environment information is included below. [root@utility01 network]# uname -a Linux utility01 3.12.26-2-ARCH #1 PREEMPT Sun Aug 31 22:36:40 MDT 2014 armv6l GNU/Linux [root@utility01 network]# pacman -Q systemd systemd 216-3 [root@utility01 network]# lsmod | grep 8021q 8021q 20658 0 garp6303 1 8021q mrp 8249 1 8021q [root@utility01 network]# pwd /etc/systemd/network [root@utility01 network]# for f in *; do echo; echo "-- $f"; echo; cat $f; done -- eth0.network [Match] Name=eth0 [Network] DHCP=v4 VLAN=1 VLAN=0 -- vlan0.netdev [NetDev] Name=vlan0 Kind=vlan [VLAN] Id=0 -- vlan0.network [Match] Name=vlan0 [Network] DHCP=v4 VLAN=0 -- vlan1.netdev [NetDev] Name=vlan1 Kind=vlan [VLAN] Id=1 -- vlan1.network [Match] Name=vlan1 [Network] DHCP=v4 VLAN=1 [root@utility01 network]# ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: ifb0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32 link/ether 3e:ff:bc:28:42:cb brd ff:ff:ff:ff:ff:ff 3: ifb1: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 32 link/ether 3a:65:88:fc:ab:27 brd ff:ff:ff:ff:ff:ff 4: eth0: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff 5: wlan0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 64:66:b3:20:04:f5 brd ff:ff:ff:ff:ff:ff 6: eth0.0@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff NOTE: The existing eth0.0 was created using vconfig, which I created simply to get this machine back on the network while I troubleshooted my issue. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd -- Unable to create VLAN device
Holy smokes, that did it! Many thanks for taking time out of your day to help me find my silly mistake :) On Friday 19 September 2014 22:51:41 Tom Gundersen wrote: > On Fri, Sep 19, 2014 at 6:59 PM, James Lott wrote: > > Hello again! > > > > I've been eager to play with networking features, in case you couldn't > > tell ;) This patricular issue seems separate from my first one though, so > > I thought it would be best to discuss separately. > > > > I am trying to use systemd-networkd to essentially replace vconfig. I am > > using eth0 as a trunked link and am trying to setup a pair of VLAN > > devices to receive the taged frames. It seems that the VLAN netdevs are > > silently failing to be created. > > > > Sep 19 09:47:34 utility01 systemd[1]: Starting Network Service... > > Sep 19 09:47:34 utility01 systemd-networkd[776]: > > [/etc/systemd/network/vlan1.network:6] VLAN could not be found, ignoring > > assignment: 1 > > Sep 19 09:47:34 utility01 systemd-networkd[776]: > > [/etc/systemd/network/vlan0.network:6] VLAN could not be found, ignoring > > assignment: 0 > > Sep 19 09:47:34 utility01 systemd-networkd[776]: > > [/etc/systemd/network/eth0.network:6] VLAN could not be found, ignoring > > assignment: 1 > > Sep 19 09:47:34 utility01 systemd-networkd[776]: > > [/etc/systemd/network/eth0.network:7] VLAN could not be found, ignoring > > assignment: 0 > > Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0.0 : gained > > carrier > > Sep 19 09:47:34 utility01 systemd-networkd[776]: eth0: gained > > carrier > > Sep 19 09:47:34 utility01 systemd-networkd[776]: lo : gained > > carrier > > Sep 19 09:47:34 utility01 systemd[1]: Started Network Service. > > > > Although I strongly believe this to be an error I am making somewhere, I > > have read and re-read all of the systemd-networkd man pages, and cannot > > for the life of me figure out where I went wrong. Any help is much > > appreciated! Additional environment information is included below. > > > > [root@utility01 network]# uname -a > > Linux utility01 3.12.26-2-ARCH #1 PREEMPT Sun Aug 31 22:36:40 MDT 2014 > > armv6l GNU/Linux > > [root@utility01 network]# pacman -Q systemd > > systemd 216-3 > > [root@utility01 network]# lsmod | grep 8021q > > 8021q 20658 0 > > garp6303 1 8021q > > mrp 8249 1 8021q > > > > [root@utility01 network]# pwd > > /etc/systemd/network > > [root@utility01 network]# for f in *; do echo; echo "-- $f"; echo; > > cat $f; done > > > > -- eth0.network > > > > [Match] > > Name=eth0 > > > > [Network] > > DHCP=v4 > > VLAN=1 > > VLAN=0 > > This needs to be the names of your vlan interfaces, not their vlanid. I.e., > > VLAN=vlan0 > VLAN=vlan1 > > > -- vlan0.netdev > > > > [NetDev] > > Name=vlan0 > > Kind=vlan > > > > [VLAN] > > Id=0 > > > > -- vlan0.network > > > > [Match] > > Name=vlan0 > > > > [Network] > > DHCP=v4 > > VLAN=0 > > > > -- vlan1.netdev > > > > [NetDev] > > Name=vlan1 > > Kind=vlan > > > > [VLAN] > > Id=1 > > > > -- vlan1.network > > > > [Match] > > Name=vlan1 > > > > [Network] > > DHCP=v4 > > VLAN=1 > > [root@utility01 network]# ip link > > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode > > DEFAULT group default > > > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > > > 2: ifb0: mtu 1500 qdisc noop state DOWN mode DEFAULT > > group default qlen 32 > > > > link/ether 3e:ff:bc:28:42:cb brd ff:ff:ff:ff:ff:ff > > > > 3: ifb1: mtu 1500 qdisc noop state DOWN mode DEFAULT > > group default qlen 32 > > > > link/ether 3a:65:88:fc:ab:27 brd ff:ff:ff:ff:ff:ff > > > > 4: eth0: mtu 1500 qdisc pfifo_fast state > > UP mode DEFAULT group default qlen 1000 > > > > link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff > > > > 5: wlan0: mtu 1500 qdisc noop state DOWN mode > > DEFAULT > > group default qlen 1000 > > > > link/ether 64:66:b3:20:04:f5 brd ff:ff:ff:ff:ff:ff > > > > 6: eth0.0@eth0: mtu 1500 qdisc noqueue > > state UP mode DEFAULT group default > > > > link/ether b8:27:eb:9d:3a:06 brd ff:ff:ff:ff:ff:ff > > > > NOTE: The existing eth0.0 was created using vconfig, which I created > > simply to get this machine back on the network while I troubleshooted my > > issue. ___ > > 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] Systemd-nspawn -- Unable to initialize virtual ethernet connection
Thanks so much for debugging that! Your recommended work around, of course, works perfectly for me until the release hits the Arch repos (although my gentoo machines will happily and impatiently pull in the git snapshot ). Do you know what the version number for the next systemd release will be? I want to make sure I keep my eyes peeled for it! On Friday 19 September 2014 23:04:40 Tom Gundersen wrote: > On Fri, Sep 19, 2014 at 6:37 PM, James Lott wrote: > > I am trying to setup and play around with some of the private networking > > features of systemd, and one of the big thinks I'm trying to get working > > is > > the virtual ethernet links. For some reason though, I am unable to start a > > containder using a virtual ethernet link. My attempt is included below. > > This is a bug. Thanks for the report! > > I now pushed a fix: > <http://cgit.freedesktop.org/systemd/systemd/commit/?id=c00524c9cc7fb498c724 > 4350e25823b8352f078c>. > > The problem was that we were not correctly truncating the machine name > (by default taken from the folder name) when using it to create a veth > link. Until the fix lands in your distro, you can simply rename your > container instance to a shorter name using the "--machine" switch to > systemd-nspawn. > > Cheers, > > Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
Hello! With some help from the kind people on this list, I was able to get my basic network interfaces up and runnign with systemd-networkd. Now I've moved on to playing with some slightly more complex setups, and have run into some issues that as far as I can tell may be bugs (but I'm not quite ready to rule out user error, so I thought I'd start here before submitting to the bug tracker ;) ). I have configured a vlan interface to be a member of a bridge via the appropriate .netdev and .network files, and these interfaces get setup without any issues. However, when I try to acquire a dhcp lease through the bridge interface, I am unable to do so. Removing the bridge interface and re-adding it using brctl (as well as its vlan member) then allows me to gain a lease. Details are included below. This is on arch linux ARM, systemd 216-r3. As always, I'm happy to provide any additional information required! [root@host01 ~]# networkctl list [42/59] IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 ifb0 ether off unmanaged 3 ifb1 ether off unmanaged 4 eth0 ether carrier configured 5 wlan0wlan off unmanaged 6 switch1 ether carrier configured 7 switch0 ether off unmanaged 8 vlan0ether carrier configured 9 vlan1ether carrier configured 10 vb-0 ether carrier unmanaged 10 links listed [root@host01 ~]# brctl show bridge name bridge id STP enabled interfaces switch0 8000.4ec1ffd9d149 no vlan0 switch1 8000.42f3b831050d no vb-0 vlan1 [root@host01 ~]# ip l show switch0 7: switch0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default link/ether 4e:c1:ff:d9:d1:49 brd ff:ff:ff:ff:ff:ff [root@host01 ~]# cat /etc/systemd/network/switch0.netdev [NetDev] Description=Virtual switch for container instances Name=switch0 Kind=bridge [root@host01 ~]# dhcpcd switch0 [15/59] dhcpcd[324]: version 6.4.3 starting dhcpcd[324]: all: IPv6 kernel autoconf disabled dhcpcd[324]: switch0: IPv6 kernel autoconf disabled dhcpcd[324]: switch0: adding address fe80::4cc1::fed9:d149 dhcpcd[324]: if_addaddress6: Operation not supported dhcpcd[324]: switch0: waiting for carrier dhcpcd[324]: switch0: carrier acquired dhcpcd[324]: all: IPv6 kernel autoconf disabled dhcpcd[324]: switch0: IPv6 kernel autoconf disabled dhcpcd[324]: DUID 00:01:00:01:c7:92:cd:f9:e2:b2:c0:dd:be:4e dhcpcd[324]: switch0: IAID ff:d9:d1:49 dhcpcd[324]: switch0: soliciting a DHCP lease dhcpcd[324]: timed out dhcpcd[324]: exited [root@host01 ~]# ip l set switch0 down [root@host01 ~]# brctl delbr switch0 [root@host01 ~]# brctl addbr switch0 [root@host01 ~]# brctl addif switch0 vlan0 [root@host01 ~]# dhcpcd switch0 dhcpcd[370]: version 6.4.3 starting dhcpcd[370]: all: IPv6 kernel autoconf disabled dhcpcd[370]: switch0: IPv6 kernel autoconf disabled dhcpcd[370]: switch0: adding address fe80::1c28:afff:fec4:2bd6 dhcpcd[370]: if_addaddress6: Operation not supported dhcpcd[370]: switch0: waiting for carrier dhcpcd[370]: switch0: carrier acquired dhcpcd[370]: all: IPv6 kernel autoconf disabled dhcpcd[370]: switch0: IPv6 kernel autoconf disabled dhcpcd[370]: DUID 00:01:00:01:c7:92:cd:f9:e2:b2:c0:dd:be:4e dhcpcd[370]: switch0: IAID af:c4:2b:d6 dhcpcd[370]: switch0: soliciting a DHCP lease dhcpcd[370]: switch0: offered 192.168.0.115 from 192.168.0.1 dhcpcd[370]: switch0: leased 192.168.0.115 for 86400 seconds dhcpcd[370]: switch0: adding route to 192.168.0.0/24 dhcpcd[370]: switch0: adding default route via 192.168.0.1 dhcpcd[370]: forked to background, child pid 420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
Hello, There is no .network file for the bridge. Systemd-networkd is currently only in charge of setting up the interface. As you can see from the provided output in my original email, I am running the dhcpcd service directly from the command line (the output from each run of the dhcpcd service is included in that email as well). On Wednesday 24 September 2014 22:44:17 Leonid Isaev wrote: > Hi, > > On Wed, Sep 24, 2014 at 07:16:03PM -0700, James Lott wrote: > > However, when I try to acquire a dhcp lease through the bridge > > interface, I am unable to do so. Removing the bridge interface and > > re-adding it using brctl (as well as its vlan member) then allows me to > > gain a lease. > > > > Details are included below. This is on arch linux ARM, systemd 216-r3. As > > always, I'm happy to provide any additional information required! > > What does the .network file for the bridge do, i.e. what are its IP > settings? Also, how do you start dhcpcd? Via the stock ArchLinux > dhcpcd@.service? > > Cheers, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd-nspawn -- Canot add interface to container
Hello again! I'm having another issue with private networking in systemd-nspawn. This one I'm not so certain is a bug, but probably some kind of mistake on my part. Base on my reading of the systemd-nspawn man page though, I can't figure out what the problem is. Basically, all I'm tring to do is remove an interface from the host namespace and provide it to the container. Details are included below (This is systemd 216-r3 in Arch Linux ARM). [root@host01 ~]# systemd-nspawn --network-interface=wlan0 -M1 -bD /home/lanvpn/ Spawning container 1 on /home/lanvpn. Press ^] three times within 1s to kill container. Failed to move interface wlan0 to namespace: File exists Thanks in advance for any help! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container
Hi Marcel, Thanks for the help pointing that one out! With your guidance I was able to figure out that I'll need to run something like: iw phy phy0 set netns Unfortunately I'm having some trouble trying to figure out the network namespace PID to assign the phy0 interface to. Although I definitely have containers with private networking running, I can't view any information about their network namespaces [root@host01 lanvpn]# machinectl MACHINE CONTAINER SERVICE 0container nspawn lanvpn container nspawn 2 machines listed. [root@host01 lanvpn]# ps aux | grep -v grep | grep systemd-nspawn root 143 0.0 0.3 2884 728 ?Ss 08:42 0:00 /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/proxy -M 0 root 4438 0.0 0.6 2884 1128 pts/3S+ 09:15 0:00 systemd- nspawn --private-network [root@host01 lanvpn]# ip netns list [root@host01 lanvpn]# Any nudges in the right direction are welcome, and appreciated! On Thursday 25 September 2014 10:21:16 Marcel Holtmann wrote: > Hi James, > > > I'm having another issue with private networking in systemd-nspawn. This > > one I'm not so certain is a bug, but probably some kind of mistake on my > > part. Base on my reading of the systemd-nspawn man page though, I can't > > figure out what the problem is. Basically, all I'm tring to do is remove > > an interface from the host namespace and provide it to the container. > > Details are included below (This is systemd 216-r3 in Arch Linux ARM). > > > > [root@host01 ~]# systemd-nspawn --network-interface=wlan0 -M1 -bD > > /home/lanvpn/ > > Spawning container 1 on /home/lanvpn. > > Press ^] three times within 1s to kill container. > > Failed to move interface wlan0 to namespace: File exists > > actually netdev interfaces like wlan0 can not move into network namespaces > by themselves. With wireless hardware, the underlying physical device (for > example phy0) needs to move into the namespace. Which means that all netdev > that belong to a specific phyX will move with it into the namespace. > > Try using "iw phy set netns " to achieve this. > > Regards > > Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container
Hi Mantas, Thanks for the clarification. The first thing I tried actually was using the PID of the systemd-nspawn instance, like so [root@host01 lanvpn]# ps aux | grep -v grep | grep systemd-nspawn root 143 0.0 0.3 2884 728 ?Ss 08:42 0:00 /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/proxy -M 0 root 4564 0.7 0.6 2884 1124 pts/3S+ 10:38 0:00 systemd- nspawn --private-network [root@host01 lanvpn]# iw phy phy0 set netns 4564 Upon re-attaching to the container, I didn't see the interface [root@lanvpn ~]# ip l 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 [root@lanvpn ~]# iw list [root@lanvpn ~]# I suppose at this point I'm probably using the iw interface incorrectly and should seek help from a more appropriate channel to address that? On Thursday 25 September 2014 20:11:56 Mantas Mikulėnas wrote: > On Thu, Sep 25, 2014 at 7:49 PM, James Lott wrote: > > Hi Marcel, > > > > Thanks for the help pointing that one out! With your guidance I was able > > to > > figure out that I'll need to run something like: > > > > iw phy phy0 set netns > > > > Unfortunately I'm having some trouble trying to figure out the network > > namespace PID to assign the phy0 interface to. Although I definitely have > > containers with private networking running, I can't view any information > > about their network namespaces > > Generally, using the PID of /any/ process in the container (e.g. the > init) should work the same. > > `ip netns` only shows "persistent" namespaces which were given a name > using the same tool. Containers generally don't bother with that. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container
Hi Zbyszek, Thanks for all your help! This is a new concept to me though, as I have never tried to refer to a process inside of a container from outside of the container before (I did not realize this was possible). Since specifying PID 1 would obviously be referring to the host system's init process, would you be willing to give me an example that might help me understand how I can specify an in-container PID from the host system? Thanks again for taking the time to help me grasp all of this :) > On Sep 25, 2014, at 2:10 PM, Zbigniew Jędrzejewski-Szmek > wrote: > >> On Thu, Sep 25, 2014 at 10:40:42AM -0700, James Lott wrote: >> Hi Mantas, >> >> Thanks for the clarification. The first thing I tried actually was using the >> PID >> of the systemd-nspawn instance, like so >> >> [root@host01 lanvpn]# ps aux | grep -v grep | grep systemd-nspawn >> root 143 0.0 0.3 2884 728 ?Ss 08:42 0:00 >> /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/proxy -M 0 >> root 4564 0.7 0.6 2884 1124 pts/3S+ 10:38 0:00 systemd- >> nspawn --private-network >> [root@host01 lanvpn]# iw phy phy0 set netns 4564 > > systemd-nspawn is *outside* of the container. You should use the child of > systemd-nspawn, i.e. the init process, instead. > > Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-networkd -- Cannot acquire DHCP lease on bridge interface
Hi Leonid! > I asked because you could try and see if networkd can acquire a lease by > itself, without dhcpcd (I don't expect it to). Actually, the reason I am using dhcpcd fro mthe command line is as a debugging measure, because I originally setup a .network file for this interface to attempt to allow systemd-networkd to handle acquiring the DHCP lease. In line with your expectations, this failed, so I tried using dhcpcd to see if I could glean what was happening. I will happily provide the disabled .network file I tried using if you would like to review it, but I'm fairly confident it isn't the issue. > Also, could you run dhcpcd > with "-d -t 0" (debug output, no timeout) to see what it's doing? Always happy to gather more information! See the output below [root@host01 ~]# ip l show switch0 7: switch0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 4e:c1:ff:d9:d1:49 brd ff:ff:ff:ff:ff:ff [root@host01 ~]# dhcpcd -dd -t0 switch0 dhcpcd[361]: version 6.4.3 starting dhcpcd[361]: all: IPv6 kernel autoconf disabled dhcpcd[361]: switch0: IPv6 kernel autoconf disabled dhcpcd[361]: switch0: adding address fe80::4cc1::fed9:d149 dhcpcd[361]: if_addaddress6: Operation not supported dhcpcd[361]: switch0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' PREINIT dhcpcd[361]: switch0: executing `/usr/lib/dhcpcd/dhcpcd-run-hooks' CARRIER dhcpcd[361]: DUID 00:01:00:01:c7:92:cd:f9:e2:b2:c0:dd:be:4e dhcpcd[361]: switch0: IAID ff:d9:d1:49 dhcpcd[361]: switch0: delaying DHCP for 0.7 seconds dhcpcd[361]: switch0: using ClientID 01:4e:c1:ff:d9:d1:49 dhcpcd[361]: switch0: soliciting a DHCP lease dhcpcd[361]: switch0: sending DISCOVER (xid 0x79fe0186), next in 4.5 seconds dhcpcd[361]: switch0: sending DISCOVER (xid 0x79fe0186), next in 7.7 seconds dhcpcd[361]: switch0: sending DISCOVER (xid 0x79fe0186), next in 15.2 seconds dhcpcd[361]: switch0: sending DISCOVER (xid 0x79fe0186), next in 31.5 seconds > I have seen a similar issue with networkd and bonding of interfaces. It > turned out that the way networkd works with links is racy, so in ~70% of > boots dhcp lease attempts failed both via networkd and dhcpcd. The only > solution which I found was to use netctl (should be availabel on ALARM) > where you can explicitly specify a precise order in which links should be > managed. Yuck. I'm really not a fan of netctl, and would probably sooner hack together some oneshot service files that manually setup the interfaces and acquire leases. So it sounds like systemd-networkd is not quite ready for prime time when it comes to being a complete interface management solution. I guess that's what I get for living life on the edge ;) On Thursday 25 September 2014 18:23:47 Leonid Isaev wrote: > Hi, > > On Wed, Sep 24, 2014 at 08:14:55PM -0700, James Lott wrote: > > Hello, > > > > There is no .network file for the bridge. Systemd-networkd is currently > > only in charge of setting up the interface. As you can see from the > > provided output in my original email, I am running the dhcpcd service > > directly from the command line (the output from each run of the dhcpcd > > service is included in that email as well). > > I asked because you could try and see if networkd can acquire a lease by > itself, without dhcpcd (I don't expect it to). Also, could you run dhcpcd > with "-d -t 0" (debug output, no timeout) to see what it's doing? > > I have seen a similar issue with networkd and bonding of interfaces. It > turned out that the way networkd works with links is racy, so in ~70% of > boots dhcp lease attempts failed both via networkd and dhcpcd. The only > solution which I found was to use netctl (should be availabel on ALARM) > where you can explicitly specify a precise order in which links should be > managed. > > Cheers, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container
Shame on me for not spending more time trying to figure this out before responding. Please ignore my previous sad plea for help, I understand fully now exactly what you're saying, and was able to successfully move the phy0 interface into my container. At this point, my challenge is going to be coordinating the movement of this interface within a service file, so I don't need to do it manually when starting the container... but I suppose I can write an ExecStartPost script which can manage this. Thanks again for all your help! On Thursday 25 September 2014 16:25:02 James Lott wrote: > Hi Zbyszek, > > Thanks for all your help! This is a new concept to me though, as I have > never tried to refer to a process inside of a container from outside of the > container before (I did not realize this was possible). Since specifying > PID 1 would obviously be referring to the host system's init process, would > you be willing to give me an example that might help me understand how I > can specify an in-container PID from the host system? Thanks again for > taking the time to help me grasp all of this :) > > On Sep 25, 2014, at 2:10 PM, Zbigniew Jędrzejewski-Szmek wrote: > >> On Thu, Sep 25, 2014 at 10:40:42AM -0700, James Lott wrote: > >> Hi Mantas, > >> > >> Thanks for the clarification. The first thing I tried actually was using > >> the PID of the systemd-nspawn instance, like so > >> > >> [root@host01 lanvpn]# ps aux | grep -v grep | grep systemd-nspawn > >> root 143 0.0 0.3 2884 728 ?Ss 08:42 0:00 > >> /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/proxy -M 0 > >> root 4564 0.7 0.6 2884 1124 pts/3S+ 10:38 0:00 systemd- > >> nspawn --private-network > >> [root@host01 lanvpn]# iw phy phy0 set netns 4564 > > > > systemd-nspawn is *outside* of the container. You should use the child of > > systemd-nspawn, i.e. the init process, instead. > > > > Zbyszek > > ___ > 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] Systemd-nspawn -- Canot add interface to container
Hello again! Once again, thanks for all the help with getting my wireless interface moved into the container! Now I just have one more interface I'm having trouble with. I can't seem to move my ethernet interfaces into the container. I'm getting the same error, so I presume it's for the same reason. I can find the path to my physical devices in kernel space (they're both on a USB bus), but I can't figure out what device name I should pass to systemd-nspawn (or what other userspace program I could use to move one of the interfaces into a container's namespace). Thanks in advance for any pointers! [root@host01 lanvpn]# systemd-nspawn --network-interface=eth1 Spawning container lanvpn on /home/lanvpn. Press ^] three times within 1s to kill container. Failed to move interface eth1 to namespace: File exists [root@host01 lanvpn]# ls -lah /sys/class/net/ | egrep 'eth[0-1] ' lrwxrwxrwx 1 root root 0 Dec 31 1969 eth0 -> ../../devices/platform/bcm2708_usb/usb1/1-1/1-1.1/1-1.1:1.0/net/eth0 lrwxrwxrwx 1 root root 0 Dec 31 1969 eth1 -> ../../devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/net/eth1 On Thursday 25 September 2014 17:05:34 James Lott wrote: > Shame on me for not spending more time trying to figure this out before > responding. Please ignore my previous sad plea for help, I understand fully > now exactly what you're saying, and was able to successfully move the phy0 > interface into my container. > > At this point, my challenge is going to be coordinating the movement of this > interface within a service file, so I don't need to do it manually when > starting the container... but I suppose I can write an ExecStartPost script > which can manage this. > > Thanks again for all your help! > > On Thursday 25 September 2014 16:25:02 James Lott wrote: > > Hi Zbyszek, > > > > Thanks for all your help! This is a new concept to me though, as I have > > never tried to refer to a process inside of a container from outside of > > the > > container before (I did not realize this was possible). Since specifying > > PID 1 would obviously be referring to the host system's init process, > > would > > you be willing to give me an example that might help me understand how I > > can specify an in-container PID from the host system? Thanks again for > > taking the time to help me grasp all of this :) > > > > > On Sep 25, 2014, at 2:10 PM, Zbigniew Jędrzejewski-Szmek > > wrote: > > >> On Thu, Sep 25, 2014 at 10:40:42AM -0700, James Lott wrote: > > >> Hi Mantas, > > >> > > >> Thanks for the clarification. The first thing I tried actually was > > >> using > > >> the PID of the systemd-nspawn instance, like so > > >> > > >> [root@host01 lanvpn]# ps aux | grep -v grep | grep systemd-nspawn > > >> root 143 0.0 0.3 2884 728 ?Ss 08:42 0:00 > > >> /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/proxy -M 0 > > >> root 4564 0.7 0.6 2884 1124 pts/3S+ 10:38 0:00 > > >> systemd- > > >> nspawn --private-network > > >> [root@host01 lanvpn]# iw phy phy0 set netns 4564 > > > > > > systemd-nspawn is *outside* of the container. You should use the child > > > of > > > systemd-nspawn, i.e. the init process, instead. > > > > > > Zbyszek > > > > ___ > > 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 mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container
Figured out that 'ip link set netns ' works much the same as 'iw phy set netns ', but I still can't seem to figure out what types of interfaces --network-interface will accept. If anyone happens to have a good example of how to use it, I would love to take a look at it. > On Sep 26, 2014, at 4:28 PM, James Lott wrote: > > Hello again! > > Once again, thanks for all the help with getting my wireless interface moved > into the container! Now I just have one more interface I'm having trouble > with. I can't seem to move my ethernet interfaces into the container. I'm > getting the same error, so I presume it's for the same reason. I can find the > path to my physical devices in kernel space (they're both on a USB bus), but > I > can't figure out what device name I should pass to systemd-nspawn (or what > other userspace program I could use to move one of the interfaces into a > container's namespace). Thanks in advance for any pointers! > > [root@host01 lanvpn]# systemd-nspawn --network-interface=eth1 > Spawning container lanvpn on /home/lanvpn. > Press ^] three times within 1s to kill container. > Failed to move interface eth1 to namespace: File exists > [root@host01 lanvpn]# ls -lah /sys/class/net/ | egrep 'eth[0-1] ' > > > lrwxrwxrwx 1 root root 0 Dec 31 1969 eth0 -> > ../../devices/platform/bcm2708_usb/usb1/1-1/1-1.1/1-1.1:1.0/net/eth0 > lrwxrwxrwx 1 root root 0 Dec 31 1969 eth1 -> > ../../devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/net/eth1 > >> On Thursday 25 September 2014 17:05:34 James Lott wrote: >> Shame on me for not spending more time trying to figure this out before >> responding. Please ignore my previous sad plea for help, I understand fully >> now exactly what you're saying, and was able to successfully move the phy0 >> interface into my container. >> >> At this point, my challenge is going to be coordinating the movement of this >> interface within a service file, so I don't need to do it manually when >> starting the container... but I suppose I can write an ExecStartPost script >> which can manage this. >> >> Thanks again for all your help! >> >>> On Thursday 25 September 2014 16:25:02 James Lott wrote: >>> Hi Zbyszek, >>> >>> Thanks for all your help! This is a new concept to me though, as I have >>> never tried to refer to a process inside of a container from outside of >>> the >>> container before (I did not realize this was possible). Since specifying >>> PID 1 would obviously be referring to the host system's init process, >>> would >>> you be willing to give me an example that might help me understand how I >>> can specify an in-container PID from the host system? Thanks again for >>> taking the time to help me grasp all of this :) >>> >>>> On Sep 25, 2014, at 2:10 PM, Zbigniew Jędrzejewski-Szmek >> >> wrote: >>>>> On Thu, Sep 25, 2014 at 10:40:42AM -0700, James Lott wrote: >>>>> Hi Mantas, >>>>> >>>>> Thanks for the clarification. The first thing I tried actually was >>>>> using >>>>> the PID of the systemd-nspawn instance, like so >>>>> >>>>> [root@host01 lanvpn]# ps aux | grep -v grep | grep systemd-nspawn >>>>> root 143 0.0 0.3 2884 728 ?Ss 08:42 0:00 >>>>> /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/proxy -M 0 >>>>> root 4564 0.7 0.6 2884 1124 pts/3S+ 10:38 0:00 >>>>> systemd- >>>>> nspawn --private-network >>>>> [root@host01 lanvpn]# iw phy phy0 set netns 4564 >>>> >>>> systemd-nspawn is *outside* of the container. You should use the child >>>> of >>>> systemd-nspawn, i.e. the init process, instead. >>>> >>>> Zbyszek >>> >>> ___ >>> 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 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] Systemd-nspawn: Cannot create tun device in container
Hello, list! In some work I've been doing with systemd-nspawn containers, I've been trying to connect one of my containers to an openvpn network. This conteiner is being run with the --network-bridge flag to setup its networking, so according to the documentation, should retain CAP_NET_ADMIN capabilities. However, the container appears to be unable to create a new tun device [root@lanvpn ~]# ip tuntap add dev tun0 mode tun open: No such file or directory I tried retaining the CAP_MKNOD capability for this container using the -- capability flag as well, and this met with the same result. I also tried binding the /dev/net device directory from the parent to the /dev/net device directory of the child container, and added the following line to the systemd-nspawn service file of the container [root@host01 ~]# grep Device /etc/systemd/system/lanvpn.service DeviceAllow=/dev/net/tun rwm This resulted in the error [root@lanvpn ~]# ip tuntap add tun0 mode tun open: Operation not permitted Is there any way to run my containers which will allow them to create tun/tap devices? System is arch linux arm, running systemd 216-r3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd-nspawn: cannot add interfaces with --network-interface flag
Hello, A little bit back I wrote in about having some difficulties adding network devices to containers. With some help from the list, I figured out how to add my network devices to an already running container using 'iw phy' and 'ip link'. However, I have not yet successfully added an interface to a container by way of the --network-interface flag. Attempting to add any ethernet devices by this method meets with the error: [root@host01 lanvpn]# systemd-nspawn --network-interface=eth1 Spawning container lanvpn on /home/lanvpn. Press ^] three times within 1s to kill container. Failed to move interface eth1 to namespace: File exists According to the systemd-nspawn documentation, it seems like this invocation should work --network-interface= Assign the specified network interface to the container. This will remove the specified interface from the calling namespace and place it in the container. When the container terminates, it is moved back to the host namespace. Note that --network-interface= implies --private-network. This option may be used more than once to add multiple network interfaces to the container. If I'm doing something wrong, then it seems like the documentation may desire revisiting. If I'm not, then this could be unintended behavior. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn: Cannot create tun device in container
Does anyone have any feedback on this thread? If it's not possible for a container to create its own /dev/net/tun device (or use the host system's), I'll just move on to finding a less preferable solution. > On Oct 3, 2014, at 10:46 AM, James Lott wrote: > > Hello, list! > > In some work I've been doing with systemd-nspawn containers, I've been trying > to connect one of my containers to an openvpn network. This conteiner is > being > run with the --network-bridge flag to setup its networking, so according to > the > documentation, should retain CAP_NET_ADMIN capabilities. However, the > container appears to be unable to create a new tun device > > [root@lanvpn ~]# ip tuntap add dev tun0 mode tun > open: No such file or directory > > I tried retaining the CAP_MKNOD capability for this container using the -- > capability flag as well, and this met with the same result. > > I also tried binding the /dev/net device directory from the parent to the > /dev/net device directory of the child container, and added the following > line > to the systemd-nspawn service file of the container > > [root@host01 ~]# grep Device /etc/systemd/system/lanvpn.service > DeviceAllow=/dev/net/tun rwm > > This resulted in the error > > [root@lanvpn ~]# ip tuntap add tun0 mode tun > open: Operation not permitted > > Is there any way to run my containers which will allow them to create tun/tap > devices? System is arch linux arm, running systemd 216-r3 > ___ > 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] Systemd-nspawn: Cannot create tun device in container
Hey there Tom,
No problem! Many thanks for taking the time to check this out and write up a
patch!
I compiled the latest systemd with the patch you pushed, and my container is
now able to create a /dev/net/tun device with no problems. However, there
appears to be a problem with the container being able to actually utilize this
device. Trying to start up an openvpn connection yields the following error:
Thu Oct 9 15:01:52 2014 ERROR: Cannot open TUN/TAP dev /dev/net/tun:
Operation not permitted (errno=1)
As requested by Lennart, attached you will find an strace of the openvpn
process as it attempts to setup the connection. Please let me know if there's
anything else I can provide to be helpful, and thanks again for the help!
On Wednesday 08 October 2014 15:59:03 you wrote:
> On Fri, Oct 3, 2014 at 7:46 PM, James Lott wrote:
> > Hello, list!
> >
> > In some work I've been doing with systemd-nspawn containers, I've been
> > trying to connect one of my containers to an openvpn network. This
> > conteiner is being run with the --network-bridge flag to setup its
> > networking, so according to the documentation, should retain
> > CAP_NET_ADMIN capabilities. However, the container appears to be unable
> > to create a new tun device
>
> Hi James,
>
> Thanks for the report, and sorry for the late reply. I just pushed a
> fix to git which creates /dev/net/tun in the container (if it exists
> on the host) and it appears to work for me. Please let me know whether
> this solves your problem.
>
> Cheers,
>
> Tom
>
> > [root@lanvpn ~]# ip tuntap add dev tun0 mode tun
> > open: No such file or directory
> >
> > I tried retaining the CAP_MKNOD capability for this container using the --
> > capability flag as well, and this met with the same result.
> >
> > I also tried binding the /dev/net device directory from the parent to the
> > /dev/net device directory of the child container, and added the following
> > line to the systemd-nspawn service file of the container
> >
> > [root@host01 ~]# grep Device /etc/systemd/system/lanvpn.service
> >
> > DeviceAllow=/dev/net/tun rwm
> >
> > This resulted in the error
> >
> > [root@lanvpn ~]# ip tuntap add tun0 mode tun
> > open: Operation not permitted
> >
> > Is there any way to run my containers which will allow them to create
> > tun/tap devices? System is arch linux arm, running systemd 216-r3
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/systemd-devel
execve("/usr/bin/openvpn", ["/usr/bin/openvpn", "--config",
"/etc/openvpn/vpngate.conf"], [/* 16 vars */]) = 0
brk(0) = 0x181f000
uname({sys="Linux", node="lanvpn", ...}) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=23924, ...}) = 0
mmap2(NULL, 23924, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f4
close(3)= 0
open("/usr/lib/liblzo2.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\324\36\0\0004\0\0\0"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=116240, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb6f2
mmap2(NULL, 147604, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb6efb000
mprotect(0xb6f16000, 32768, PROT_NONE) = 0
mmap2(0xb6f1e000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b000) = 0xb6f1e000
close(3)= 0
open("/usr/lib/libssl.so.1.0.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\\\352\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=398287, ...}) = 0
mmap2(NULL, 377668, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb6e9e000
mprotect(0xb6eed000, 32768, PROT_NONE) = 0
mmap2(0xb6ef5000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4f000) = 0xb6ef5000
close(3)= 0
open("/usr/lib/libcrypto.so.1.0.0", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\200\260\3\0004\0\0\0"..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=1770726, ...}) = 0
mmap2(NULL, 1500716, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb6d2f000
mprotect(0xb6e7f000, 28672, PROT_NONE) = 0
mmap2(0xb6e86000, 86016, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14f000)
Re: [systemd-devel] Systemd-nspawn: cannot add interfaces with --network-interface flag
Hi Lennart! Thanks for your response! I observed this issue on Arch Linux ARM running systemd-216-3, which it appears uses sources from about a week before that patch was committed. Thanks for pointing out the commit! I'll compile from HEAD and test again On Wednesday 08 October 2014 14:08:07 Lennart Poettering wrote: > On Fri, 03.10.14 10:58, James Lott (ja...@lottspot.com) wrote: > > Hello, > > > > A little bit back I wrote in about having some difficulties adding network > > devices to containers. With some help from the list, I figured out how to > > add my network devices to an already running container using 'iw phy' and > > 'ip link'. > > > > However, I have not yet successfully added an interface to a container by > > way of the --network-interface flag. Attempting to add any ethernet > > devices by this method meets with the error: > > > > [root@host01 lanvpn]# systemd-nspawn --network-interface=eth1 > > Spawning container lanvpn on /home/lanvpn. > > Press ^] three times within 1s to kill container. > > Failed to move interface eth1 to namespace: File exists > > > > According to the systemd-nspawn documentation, it seems like this > > invocation should work > > > >--network-interface= > > > >Assign the specified network interface to the container. This > >will > > > > remove the specified interface from the calling namespace and place it in > > the container. > > > >When the container terminates, it is moved back to the host > > > > namespace. Note that --network-interface= implies --private-network. This > > option may be used more > > > >than once to add multiple network interfaces to the container. > > > > If I'm doing something wrong, then it seems like the documentation may > > desire revisiting. If I'm not, then this could be unintended behavior. > > Which version of systemd-nspawn are you trying this with? Note that > there was a recent fix in the code handling --network-interface=, that > might make work what you are trying to do: > > http://cgit.freedesktop.org/systemd/systemd/commit/src/nspawn/nspawn.c?id=31 > 25b3ef5db70d45882c7d6f617705802c5f939e > > Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn: cannot add interfaces with --network-interface flag
Whoops.. Meant to send the message: Installing the latest systemd from git fixed this issue. Thanks again for pointing that out! On Thursday 09 October 2014 15:14:18 James Lott wrote: > Hi Lennart! > > Thanks for your response! I observed this issue on Arch Linux ARM running > systemd-216-3, which it appears uses sources from about a week before that > patch was committed. Thanks for pointing out the commit! I'll compile from > HEAD and test again > > On Wednesday 08 October 2014 14:08:07 Lennart Poettering wrote: > > On Fri, 03.10.14 10:58, James Lott (ja...@lottspot.com) wrote: > > > Hello, > > > > > > A little bit back I wrote in about having some difficulties adding > > > network > > > devices to containers. With some help from the list, I figured out how > > > to > > > add my network devices to an already running container using 'iw phy' > > > and > > > 'ip link'. > > > > > > However, I have not yet successfully added an interface to a container > > > by > > > way of the --network-interface flag. Attempting to add any ethernet > > > devices by this method meets with the error: > > > > > > [root@host01 lanvpn]# systemd-nspawn --network-interface=eth1 > > > Spawning container lanvpn on /home/lanvpn. > > > Press ^] three times within 1s to kill container. > > > Failed to move interface eth1 to namespace: File exists > > > > > > According to the systemd-nspawn documentation, it seems like this > > > invocation should work > > > > > >--network-interface= > > > > > >Assign the specified network interface to the container. This > > >will > > > > > > remove the specified interface from the calling namespace and place it > > > in > > > the container. > > > > > >When the container terminates, it is moved back to the host > > > > > > namespace. Note that --network-interface= implies --private-network. > > > This > > > option may be used more > > > > > >than once to add multiple network interfaces to the > > >container. > > > > > > If I'm doing something wrong, then it seems like the documentation may > > > desire revisiting. If I'm not, then this could be unintended behavior. > > > > Which version of systemd-nspawn are you trying this with? Note that > > there was a recent fix in the code handling --network-interface=, that > > might make work what you are trying to do: > > > > http://cgit.freedesktop.org/systemd/systemd/commit/src/nspawn/nspawn.c?id= > > 31 25b3ef5db70d45882c7d6f617705802c5f939e > > > > Lennart > > ___ > 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] Systemd-nspawn: Cannot create tun device in container
I am using a setup which retains the CAP_NET_ADMIN capability inside the container and allows openvpn to setup the device. No persistent devices are involved. Below, I have included a snippet from a shell session which shows the command used to invoke nspawn and then the openvpn command executed within the container which fails. [root@host01 ~]# systemctl status lanvpn | grep -A1 CGroup CGroup: /system.slice/lanvpn.service `-2169 /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/lanvpn [root@host01 ~]# ssh lanvpn Last login: Thu Oct 9 15:01:42 2014 from host01.lottspot.vpn [root@lanvpn ~]# openvpn --config /etc/openvpn/vpngate.conf | tail -n2 Thu Oct 9 23:40:45 2014 ERROR: Cannot open TUN/TAP dev /dev/net/tun: Operation not permitted (errno=1) Thu Oct 9 23:40:45 2014 Exiting due to fatal error This same VPN configuration will successfully connect within the host environment. [root@lanvpn ~]# exit logout Connection to lanvpn closed. [root@host01 ~]# curl icanhazip.com 23.243.158.241 [root@host01 ~]# openvpn --daemon --config /home/lanvpn/etc/openvpn/vpngate.conf [root@host01 ~]# curl icanhazip.com 111.255.23.34 On Friday 10 October 2014 08:12:02 you wrote: > On Fri, Oct 10, 2014 at 12:13 AM, James Lott wrote: > > Trying to start up an openvpn connection yields the following error: > > > > Thu Oct 9 15:01:52 2014 ERROR: Cannot open TUN/TAP dev /dev/net/tun: > > Operation not permitted (errno=1) > > > > As requested by Lennart, attached you will find an strace of the openvpn > > process as it attempts to setup the connection. Please let me know if > > there's anything else I can provide to be helpful, and thanks again for > > the help! > Thanks. So to open /dev/net/tun you need either to have CAP_NET_ADMIN > (which depends on how you start nspawn, e.g. passing --network-veth > will give you this) or the tun device must be created persistently by > someone else and openvpn must have the right uid/gid to take control > of it. > > Which setup are you using? Could you send the commandline you used to > invoke nspawn and the openvpn config file you are using? (And also the > same for whatever method you are using to create the persistent tun > netdev, if this is what you do). > > Cheers, > > Tom -- James Lott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn: Cannot create tun device in container
Everything works great now, thanks for all of your help! > On Oct 10, 2014, at 2:13 AM, Lennart Poettering > wrote: > >> On Thu, 09.10.14 23:53, James Lott (ja...@lottspot.com) wrote: >> >> I am using a setup which retains the CAP_NET_ADMIN capability inside the >> container and allows openvpn to setup the device. No persistent devices are >> involved. Below, I have included a snippet from a shell session which shows >> the command used to invoke nspawn and then the openvpn command executed >> within >> the container which fails. > > The "devices" cgroup controller is used by nspawn to ensure code > running inside the container cannot freely create arbitrary device > nodes and then open them. What was missing here is to actually update > the policy for it to allow access to /dev/net/tun. I made that change > now, please check with the git version for nspawn if everything works > now. > > Lennart > > -- > Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
On Wed, 2013-08-21 at 11:51 +0200, Kay Sievers wrote: > On Wed, Aug 21, 2013 at 9:22 AM, Gao feng wrote: > > On 08/21/2013 03:06 PM, Eric W. Biederman wrote: > > >> I suspect libvirt should simply not share /run or any other normally > >> writable directory with the host. Sharing /run /var/run or even /tmp > >> seems extremely dubious if you want some kind of containment, and > >> without strange things spilling through. > > Right, /run or /var cannot be shared. It's not only about sockets, > many other things will also go really wrong that way. This is very narrow thinking about what a container might be and will cause trouble as people start to create novel uses for containers in the cloud if you try to impose this on our current infrastructure. One of the cgroup only container uses we see at Parallels (so no separate filesystem and no net namespaces) is pure apache load balancer type shared hosting. In this scenario, base apache is effectively brought up in the host environment, but then spawned instances are resource limited using cgroups according to what the customer has paid. Obviously all apache instances are sharing /var and /run from the host (mostly for logging and pid storage and static pages). The reason some hosters do this is that it allows much higher density simple web serving (either static pages from quota limited chroots or dynamic pages limited by database space constraints) because each "instance" shares so much from the host. The service is obviously much more basic than giving each customer a container running apache, but it's much easier for the hoster to administer and it serves the customer just as well for a large cross section of use cases and for those it doesn't serve, the hoster usually has separate container hosting (for a higher price, of course). James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
On Sun, 2013-08-25 at 19:37 +0200, Kay Sievers wrote: > On Sun, Aug 25, 2013 at 7:16 PM, James Bottomley > wrote: > > On Wed, 2013-08-21 at 11:51 +0200, Kay Sievers wrote: > >> On Wed, Aug 21, 2013 at 9:22 AM, Gao feng wrote: > >> > On 08/21/2013 03:06 PM, Eric W. Biederman wrote: > >> > >> >> I suspect libvirt should simply not share /run or any other normally > >> >> writable directory with the host. Sharing /run /var/run or even /tmp > >> >> seems extremely dubious if you want some kind of containment, and > >> >> without strange things spilling through. > >> > >> Right, /run or /var cannot be shared. It's not only about sockets, > >> many other things will also go really wrong that way. > > > > This is very narrow thinking about what a container might be and will > > cause trouble as people start to create novel uses for containers in the > > cloud if you try to impose this on our current infrastructure. > > > > One of the cgroup only container uses we see at Parallels (so no > > separate filesystem and no net namespaces) is pure apache load balancer > > type shared hosting. In this scenario, base apache is effectively > > brought up in the host environment, but then spawned instances are > > resource limited using cgroups according to what the customer has paid. > > Obviously all apache instances are sharing /var and /run from the host > > (mostly for logging and pid storage and static pages). The reason some > > hosters do this is that it allows much higher density simple web serving > > (either static pages from quota limited chroots or dynamic pages limited > > by database space constraints) because each "instance" shares so much > > from the host. The service is obviously much more basic than giving > > each customer a container running apache, but it's much easier for the > > hoster to administer and it serves the customer just as well for a large > > cross section of use cases and for those it doesn't serve, the hoster > > usually has separate container hosting (for a higher price, of course). > > The "container" as we talk about has it's own init, and no, it cannot > share /var or /run. This is what we would call an IaaS container: bringing up init and effectively a new OS inside a container is the closest containers come to being like hypervisors. It's the most common use case of Parallels containers in the field, so I'm certainly not telling you it's a bad idea. > The stuff you talk about has nothing to do with that, it's not > different from all services or a multi-instantiated service on the > host sharing the same /run and /var. I gave you one example: a really simplistic one. A more sophisticated example is a PaaS or SaaS container where you bring the OS up in the host but spawn a particular application into its own container (this is essentially similar to what Docker does). Often in this case, you do add separate mount and network namespaces to make the application isolated and migrateable with its own IP address. The reason you share init and most of the OS from the host is for elasticity and density, which are fast becoming a holy grail type quest of cloud orchestration systems: if you don't have to bring up the OS from init and you can just start the application from a C/R image (orders of magnitude smaller than a full system image) and slap on the necessary namespaces as you clone it, you have something that comes online in miliseconds which is a feat no hypervisor based virtualisation can match. I'm not saying don't pursue the IaaS case, it's definitely useful ... I'm just saying it would be a serious mistake to think that's the only use case for containers and we certainly shouldn't adjust Linux to serve only that use case. James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
On Mon, 2013-08-26 at 09:06 +0800, Gao feng wrote: > On 08/26/2013 02:16 AM, James Bottomley wrote: > > On Sun, 2013-08-25 at 19:37 +0200, Kay Sievers wrote: > >> On Sun, Aug 25, 2013 at 7:16 PM, James Bottomley > >> wrote: > >>> On Wed, 2013-08-21 at 11:51 +0200, Kay Sievers wrote: > >>>> On Wed, Aug 21, 2013 at 9:22 AM, Gao feng wrote: > >>>>> On 08/21/2013 03:06 PM, Eric W. Biederman wrote: > >>>> > >>>>>> I suspect libvirt should simply not share /run or any other normally > >>>>>> writable directory with the host. Sharing /run /var/run or even /tmp > >>>>>> seems extremely dubious if you want some kind of containment, and > >>>>>> without strange things spilling through. > >>>> > >>>> Right, /run or /var cannot be shared. It's not only about sockets, > >>>> many other things will also go really wrong that way. > >>> > >>> This is very narrow thinking about what a container might be and will > >>> cause trouble as people start to create novel uses for containers in the > >>> cloud if you try to impose this on our current infrastructure. > >>> > >>> One of the cgroup only container uses we see at Parallels (so no > >>> separate filesystem and no net namespaces) is pure apache load balancer > >>> type shared hosting. In this scenario, base apache is effectively > >>> brought up in the host environment, but then spawned instances are > >>> resource limited using cgroups according to what the customer has paid. > >>> Obviously all apache instances are sharing /var and /run from the host > >>> (mostly for logging and pid storage and static pages). The reason some > >>> hosters do this is that it allows much higher density simple web serving > >>> (either static pages from quota limited chroots or dynamic pages limited > >>> by database space constraints) because each "instance" shares so much > >>> from the host. The service is obviously much more basic than giving > >>> each customer a container running apache, but it's much easier for the > >>> hoster to administer and it serves the customer just as well for a large > >>> cross section of use cases and for those it doesn't serve, the hoster > >>> usually has separate container hosting (for a higher price, of course). > >> > >> The "container" as we talk about has it's own init, and no, it cannot > >> share /var or /run. > > > > This is what we would call an IaaS container: bringing up init and > > effectively a new OS inside a container is the closest containers come > > to being like hypervisors. It's the most common use case of Parallels > > containers in the field, so I'm certainly not telling you it's a bad > > idea. > > > >> The stuff you talk about has nothing to do with that, it's not > >> different from all services or a multi-instantiated service on the > >> host sharing the same /run and /var. > > > > I gave you one example: a really simplistic one. A more sophisticated > > example is a PaaS or SaaS container where you bring the OS up in the > > host but spawn a particular application into its own container (this is > > essentially similar to what Docker does). Often in this case, you do > > add separate mount and network namespaces to make the application > > isolated and migrateable with its own IP address. The reason you share > > init and most of the OS from the host is for elasticity and density, > > which are fast becoming a holy grail type quest of cloud orchestration > > systems: if you don't have to bring up the OS from init and you can just > > start the application from a C/R image (orders of magnitude smaller than > > a full system image) and slap on the necessary namespaces as you clone > > it, you have something that comes online in miliseconds which is a feat > > no hypervisor based virtualisation can match. > > > > I'm not saying don't pursue the IaaS case, it's definitely useful ... > > I'm just saying it would be a serious mistake to think that's the only > > use case for containers and we certainly shouldn't adjust Linux to serve > > only that use case. > > > > The feature you said above VS contianer-reboot-host bug, I prefer to > fix > the bug. What bug? > and this feature can be achieved even container unshares /run > directory > w
Re: [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
On Mon, 2013-08-26 at 11:35 +0800, Gao feng wrote: > On 08/26/2013 11:19 AM, James Bottomley wrote: > > Yes, we are discussing this problem in this whole thread. I wasn't really watching that bit, since the problem looks solved to me. I was just reacting against the unfortunate notion that a container should run init. > If so, OpenVZ > > has never suffered from that problem and I thought it was fixed > > upstream. I've not tested lxc tools, but the latest vzctl from the > > openvz website will bring up a container on the vanilla 3.9 kernel > > (provided you have USER_NS compiled in) can also be used to reboot the > > container, so I see no reason it wouldn't work for lxc as well. > > > > I'm using libvirt lxc not lxc-tools. > Not all of users enable user namespace, I trust these container > management > tools can have right/proper setting which inhibit this reboot-problem > occur. > but I don't think this reboot-problem won't happen in any > configuration. It sounds like you're setting up your containers wrongly. If a container can reboot the system it means that host root capabilities have leaked into the container, which is a big security no-no. The upstream way of avoiding this is USER_NS (because root in the container is now not root in the host). The OpenVZ kernel uses a different mechanism to solve the problem, but we think USER_NS is the better way to go on this. James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Small tool to spawn programs in graphical sessions from non-graphical ones
On 1 September 2013 01:16, Mantas Mikulėnas wrote: > > On Sat, Aug 31, 2013 at 4:35 PM, Jan Engelhardt wrote: > > > > On Saturday 2013-08-31 14:28, killermoehre wrote: > >>Doesn't Amarok starts if you prefix it with the right DISPLAY variable? > >>Like »DISPLAY=:0 amarok«. This should work from cron, too. > > > > Normally, you also need to set XAUTHORITY= to the right path -- > > since you do not want just anybody to be able to connect to your :0. > > And then there are sessions /not/ on :0. Like when the display > manager's login screen is on :0 (although this mostly happens in weird > situations like startx'ing when a DM is running), or when Xorg crashes > and doesn't delete the lockfile for :0 so the next session gets :1, or > – what heresy – when there's a second user logged in, with /their/ > session on :0. > > ...sometimes I think Xorg should start at :1 instead, and reserve :0 > for annoying cronjobs and services that have DISPLAY=":0" hardcoded, > to remind everyone that they're using a multi-user OS. >[..] Welcome to Windows circa 2006 ;P http://blogs.msdn.com/b/oldnewthing/archive/2007/05/08/2470754.aspx -- James ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] On(Resume|suspend|hibernate) in unit files?
On 1 March 2013 07:24, Cristian Rodríguez wrote: > Having this confessed non-ideal ReloadOnResume ,StopOnSuspend in unit > files etc will make extremely easy to avoid relying on either pm-utils > hooks or those new in /usr/lib/systemd/systemd-sleep and having to patch > buggy software, most likely by introducing more dependencies and more bugs > into already roting legacy pieces of code. > > Would not Conflicts=sleep.target do what you want? (I tried to test it out but suspend is broken on my system at the moment... :/) This would only cover systemd/systemctl initiated PM transitions AFAICT though - ie. something manually echoing mem into /sys/power/state would be missed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] shell / systemd config files
Files such as /etc/machine-info have an incompatibility with systemd in regards to how it writes and/or parses them. Take the following sample: PRETTY_HOSTNAME="\'\"\$\`\\" Systemd will translate this to: '"$`\ However, the shells bash and dash will translate this to: \'"$`\ So, it appears to be that systemd is escaping single quotes when the shells themselves do not honor it for single quotes here. Thoughts for a solution? I ask because I have to write some systemd config files for a distro installer, and cannot use hostnamectl yet. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] For a "device" unit, what is the trigger source of an associated service unit "Enqueue" and "Replace" state in the systemd state engine?
I am chasing a bug in the systemd response to the initiation of an ethernet interface "device" unit by the kernel. When an ethernet interface "device" unit is initiated by the kernel, systemd will Start an associated service unit in response, but will subsquently "Enqueue" that same already running service unit a second time. Consequently, systemd will forcefully terminate the already running service unit, and then restart it. After this first "mystery" restart, the service units then operate as expected. This "Replace" action is a pointless waste of time, of course. Can someone familiar with the systemd state engine explain the source of the trigger which causes systemd to "Enqueue" a service unit a second time, while that same service unit is already running? Since systemd is not able to mount a root file system when booting with systemd "debug" reporting, enabled from the kernel command line, it is necessary to set systemd "debug" reporting after boot, and then initialize an ethernet interface "device" on a running system. This can be done by removing and then reloading the ethernet hardware device driver using modprobe. The function of the service units effected is to configure networking on the interface device. The service units configure WIDE dhcp6c, a sit tunnel, udhcp, and some static addresses. The service units for udhcp and the static addresses are somehow not effected by this "Replace" bug. The service units are formatted as shown here: After= sys-subsystem-net-devices-%i.device BindsTo= sys-subsystem-net-devices-%i.device ConditionPathExists= /sys/class/net/%i [Service] EnvironmentFile= /etc/conf.d/network.conf Type= oneshot RemainAfterExit= yes ... [Install] WantedBy= sys-subsystem-net-devices-%i.device The udhcp6c service unit also includes: TimeoutStopSec= 20s Restart= no For dhcp6c and the tunnel, the log shows: systemd[1]: Starting WIDE-DHCPv6 dhcp6c with PD Subnet on enp4s0 and NA on interface enp6s0... ... systemd[1]: Starting Tunnel Interface "sit1" through Physical Interface enp6s0... ... systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=RestartUnit cookie=1 reply_cookie=0 signature=ss error-name=n/a error-message=n/a systemd[1]: sit1@enp6s0.service: Trying to enqueue job sit1@enp6s0.service/restart/replace systemd[1]: sit1@enp6s0.service: Merged into running job, re-running: sit1@enp6s0.service/restart as 7268 systemd[1]: sit1@enp6s0.service: Enqueued job sit1@enp6s0.service/restart as 7268 ... systemd[1]: sit1@enp6s0.service: Converting job sit1@enp6s0.service/restart -> sit1@enp6s0.service/start and similarly: systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=RestartUnit cookie=1 reply_cookie=0 signature=ss error-name=n/a error-message=n/a systemd[1]: dhcp6c-enp4s0@enp6s0.service: Trying to enqueue job dhcp6c-enp4s0@enp6s0.service/restart/replace systemd[1]: dhcp6c-enp4s0@enp6s0.service: Installed new job dhcp6c-enp4s0@enp6s0.service/restart as 7984 systemd[1]: dhcp6c-enp4s0@enp6s0.service: Enqueued job dhcp6c-enp4s0@enp6s0.service/restart as 7984 ... systemd[1]: dhcp6c-enp4s0@enp6s0.service: Converting job dhcp6c-enp4s0@enp6s0.service/restart -> dhcp6c-enp4s0@enp6s0.service/start The basic question is, why does systemd "enqueue" these running service units? And, who or what is "sender=n/a", "member=RestartUnit", which appears to be the intermediary for this "restart/replace" process? What is the trigger? Why are the udhcp and the static address service units not effected in the same way? This "Replace" state does not seem to be well documented, but man systemctl does tell us: --job-mode= When queuing a new job, this option controls how to deal with already queued jobs. It takes one of "fail", "replace", "replace-irreversibly", "isolate", "ignore-dependencies", "ignore-requirements", "flush", "triggering", or "restart-dependencies". Defaults to "replace", except when the isolate command is used which implies the "isolate" job mode. ... If "replace" (the default) is specified, any conflicting pending job will be replaced, as necessary. ... As used there, does "conflicting pending job" mean a service unit configured in another service unit as "Conflicts="? But then, how would a service unit "Conflict" with itself?
Re: [systemd-devel] For a "device" unit, what is the trigger source of an associated service unit "Enqueue" and "Replace" state in the systemd state engine?
On Thu, 2025-02-13 at 22:07 +0100, Lennart Poettering wrote: > On Mo, 10.02.25 19:09, James Feeney (ja...@nurealm.net) wrote: > > > > > > systemd[1]: Got message type=method_call sender=n/a > > destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 > > interface=org.freedesktop.systemd1.Manager member=RestartUnit > > cookie=1 reply_cookie=0 signature=ss error-name=n/a > > error-message=n/a > > A client is explicitly asking for the service to be restarted! > > > The basic question is, why does systemd "enqueue" these running > > service units? And, who or what is "sender=n/a", > > "member=RestartUnit", which appears to be the intermediary for this > > "restart/replace" process? What is the trigger? Why are the udhcp > > and the static address service units not effected in the same way? > > Well, it's not systemd that enqueues those restarts on its own. It's > some D-Bus client. use "busctl monitor" to figure out what that might > be. > > you probably have some script or other service thta issues "systemctl > restart" on the service. figure out which one that is. > Thanks for your message Lennart. Now I have a `sudo busctl capture` file, which I can view in `wireshark`, but I don´t know what to make of it. Except for a few entries at the start, prior to any reference to the device driver module, no other entries list any "Destination". Most of the "Source" entries are from "org.freedesktop.systemd1". The "Info" fields include: PropertiesChaged, UnitNew, JobNew, JobRemoved, DhcpLeaseUpdated - from `dnsmasq`, and UnitRemoved. JobNew appears to correspond to the initiation of each service unit, and JobRemoved appears to correspond to the completion of each service unit. I can see only one set of JobNew and JobRemoved messages for the sit1 service unit, even though in the systemd log it is seen to be killed with sigterm and restarted. I can see two sets of JobNew and JobRemoved messages for the dhcp6c service unit, and I can bracket messages between the first JobRemoved and the following JobNew. But there are only two pairs of intervening messages regarding dhcp6c. Both pairs show org.freedesktop.systemd1 as Source, and both pairs say "ActiveState: active, FreezeState: running, SubState: running". There are no other sorts of D-Bus messages there. So, the conjecture that there is some script or other service issuing a "systemctl restart" appears unsupported by `busctl` during that portion of the D-Bus log. Is there any way to look deeper? Your theory for now is that there must be a D-Bus message forcing a Restart: > systemd[1]: Got message type=method_call sender=n/a > destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 > interface=org.freedesktop.systemd1.Manager member=RestartUnit cookie=1 > reply_cookie=0 signature=ss error-name=n/a error-message=n/a How else should I be reading these D-Bus messages? If I look all the way back at the beginning of the D-Bus log, there are three messages that show org.freedesktop.systemd1 as the Destination. In two cases, the Source is shown as ":1.1", and in the last case, the Source is org.freedesktop.DBus. In the first two cases, I do see "Member: LoadUnit, String: dbus-org.freedesktop.home1.service", and then "Member: StartUnit, String: dbus-org.freedesktop.home1.service, String: replace". That certainly sounds suspicious, "replace". What is "dbus-org.freedesktop.home1.service" and who is ":1.1"? Does that appear to be the source of one or the other of the replace/restart events? That seems to answer the question, Who is "sender-n/a", and answer would be ":1.1". But then, the "replace" message, sent by ":1.1", is marked "Method Call", and the Response, sent by org.freedesktop.systemd1, says "Unit dbus-org.freedesktop.home1.service not found". So, it's not obvious that these messages have anything to do with anything. And I do not see any similar messages relating to the sit1 service unit, which also gets the "replace" treatment. Thoughts?
Re: [systemd-devel] Designing a scheduler interface
Hi Daniel, Thanks for getting in touch. On Thu, Jan 13, 2011 at 5:29 PM, Daniel Poelzleithner wrote: > What is currently unknown on the other hand is the current active X > window in use. This could be done by connecting tho X and reacting to > events there, but I think a cleaner approach would be that the window > manager signals the running optimisation daemon that a given program is > of user importance. May it be that the program has focus or is visible > on the screen. I would like to have a standard dbus interface for this. > Would ConsoleKit not know which is the currently active session on a given seat? > Another problem I expect are clashes between systems that try to control > similar kernel subsystems. systemd at least uses cgroups in some parts. > We need to define some interface between init and the scheduling daemon > if one is running. Elsewise some expected behaviour won't work. When > init signals the optimizer the importance of services, this could be > taken into account for the decision he makes. > A cgroup hierarchy is associated with particular subsystems, and you can have many cgroup hierarchies. As long as the init daemon is not using the same subsystem as you, you can simply control it using an entirely separate hierarchy, though it would be up to you to move tasks into and out of your own. If there were overlap, some care would be required, because the init daemon may be using the cgroup for supervision purposes - removing a task from the group could mean the init daemon believes the service is no longer running. One obvious solution here is to move tasks into sub-groups with differing parameters and expect the init daemon to clean up when empty (as it's in its own hierarchy). Assuming the above, I don't see any real need for a complex interaction between them - the interface is the existing kernel interfaces. Unless I've wildly missed the point ;-) Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] use /run instead of /dev/.run
Ludwig Nussel wrote: > mount --bind /var/run /mnt > mount /var > mount -M /mnt /var/run > This doesn't work. It means there is a period during boot where /var/run suddenly vanishes (when mount the separate /var). You have to do: mount DEV_OF_VAR /mnt mount --bind /var/run /mnt/run mount -M /mnt /var We do this in Ubuntu. But I would certainly support a new "/run" to replace all the previous incarnations; viz. "/lib/init/rw", "/dev/.initramfs", "/dev/.run", "/var/run" & "/var/lock"; with one true location that's always writable during boot. Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "udevadm settle" and "init"
There is, of course, one use for "settle"; I like to have a "monitor" running during boot that creates /var/log/udev - settle is as good a command as any to kill monitor when it's done. On Thu, Mar 31, 2011 at 11:35 AM, Kay Sievers wrote: > Hey, > > the underlying problem described below, is in no way specific to > systemd, it applies to all modern systems and services, existing ones, > or ones not even developed. > > The udev systemd service files for udev do no longer pull-in the > barrier 'udevadm settle'. The udev coldplug run is executed fully > asynchronously in the background along with many other services, and > no other service will be blocked by default, waiting for udev to > populate /dev. > > That means: non-hotplug-aware services are likely to break. Services > which assume a static /dev, rely on scanning /dev and finding "all" > devices at a certain point in time, are required to explicitly pull-in > udev-settle.service to paper-over their inability to cope with a > dynamic system. It will block the broken service until udev's coldplug > run has finished and /dev is populated with all devices known at that > time. > > It's 2011 and services should cope with hotplug, devices coming and > going at any time, and a constantly changing and re-configuring > environment. No service which wants survive the next years of Linux > evolution should depend on the udev-settle.service barrier though, > please fix your stuff, or the reality might go on without you. :) > > There is libudev, which connects your service to meaningful event for > news devices, device changes, and allows you to enumerate all > currently existing devices. Subscribing to events before enumeration > is started will make sure not to miss anything, and to propagate later > changes into the service. > > All that even works from python, java, mono, javascript, ... programs, > so there is no excuse anymore to continue to do any of the > much-too-simple things we all did in the past. Just stop making > assumptions like: "booting has finished" or "all devices are there" -- > that never really was in the past, and it will never be true in the > future. > > Thanks, > Kay > -- > To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Parallel startup with sockets and without killing the machine?
Hey, I've been reading through the documentation on systemd and the Mailing List Archives and have had some questions, so I figured I'd post them here. These might be fairly complicated or unusual cases, and there may be no good answers now, and maybe no good answers ever, but I'd still like to get an idea of what you think. First up, parallel startup using sockets. We know that the theory of this goes something like this: you have a service that many other services and processes depend on, and connect to via a socket. Rather than manually express that dependency in the configuration, you instead have the socket created by the init daemon in advance. Now you simply start the service and all of the other services and processes together, and let the blocking nature of those sockets (or the software polling a non-blocking socket) sort out the ordering for you. This seems to assume that it's a free cost to start a service or process and have it block on a socket. But that isn't true, to get to the point where it connects to the socket, that service or process first has to be loaded from disk, its shared libraries mapped and relocated, it probably has to do a bunch of initialization including reading its own configuration files, etc. That's fine for "low priority" services out of the critical path for user interaction, but not for services we need as fast as possible. The best example I can think is the X server itself. It's pretty much the definition of the critical path. Everything started before the X server are those basic system components needed to start the X server, I understand in systemd that this core part would be a different target to the X part and a dep of it. Everything started after the X server is up are components of the user's session that aren't totally critical for them to login or use their computer. It's during the X startup that things get interesting. There are a few discreet phases of it. Firstly we have to spawn the X server, load the executable, map and relocate shared libraries, all of that jazz. You don't want anything else happening on the system alongside this, and you most certainly don't want every X client (Chromium/Firefox!) being loaded at the same time. The default behaviour of systemd seems to be to do just this :-( Secondly you have the period after the X server has "loaded" while it initializes but before it's "ready" to receive clients. In a perfect world this would be fast, but we all know that it isn't. In practice the X server takes countable seconds to do this work. This is a prime place in boot optimization to start other services alongside while X does its thang. But you wouldn't want to flood the system, as you don't want to delay X's startup, just use the spare resource to get more done. Can systemd discern "X has been spawned" and "X has initialized". Can systemd serialize services in this period (perhaps limited to one or two starting at a time)? Can it prioritize the order of those services in the X target? Lastly there's the processes you'd start after X is up and services are connecting to it; again I assume this would be a different target - how would systemd know that X, and the critical X services/processes are fully up and that it can begin starting these. The important thing here is user latency - the startup of these services need to not noticeably impact system performance - not as simple as prioritization because the service itself may well need a different priority once its up. Any thoughts here? Thanks, Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] device units rely on udev rules?
Another question I wasn't able to find an answer to in the documentation I've read so far. The use of device units seems to very much rely on udevd running on the system, and not only that, udev rules having been parsed for the device and a systemd tag "set" in the udevdb. udev obviously starts after systemd, and systemd starts after the kernel. This means there are a large number of devices already known to the kernel at the point that systemd starts, especially if you build the drivers into the kernel for those devices. It's possible to get going straight away with those devices. But relying on udevd tagging them means you end up waiting around for udevd to start, and worse! since udevd doesn't apply rules to existing devices on startup, you have to wait around for "udevadm trigger" to be run. Given that devtmpfs means the device nodes are already available, and systemd will be merging the ACL handling from CK/udev into itself, why does systemd rely on udev coldplugging in this way? All that's left for udevd to do at this point is "device groups" (which should go really away on any modern distro) and symlinks. There are probably many systems out there (hi!) that care so little about symlinks that they're happy for udevd to be started non-critically in the boot, and consider the "udevadm trigger" run a necessity that's probably the last thing to run. What are the long term plans here? Do you envision this staying the way it is? Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Communicating need
Thanks for your answers so far, I haven't had a chance to fully read and digest them yet, but will do so before replying on those threads (if I even need to, it's likely your responses are complete in of themselves). My third question is about communicating need; for this I'd like to outline a use case we should all be reasonable familiar with, that of Bluetooth. There are a number of components of this stack, all separated by ring/privilege for good reason: The Kernel Driver(s) - these live in kernel-land The System Daemon - privileged, so runs as root Userspace Agent/Applet - exposes information such as incoming peering, transfers, etc. to the user For the stack to be at all useful, you need all three pieces. Having one or two has no point at all. One of Upstart's mistakes - understandable, it was 2005, we were still excited about hotplug! - was to work on the principle that if we could start something, we should start something. This reflects its hotplug heritage, and even udevd works this way today: The Kernel Driver was loaded because we have seen hardware, as soon as we see that hardware. The System Daemon was loaded because we had seen the kernel create the bluetooth devices. Userspace Agent/Applet was actually always loaded as part of the session. Now there's lots of obvious problems with this approach: Userspace Agent/Applet gets loaded whether or not there is Bluetooth Hardware in the computer, whether or not there is a Kernel Driver loaded and whether or not the System Daemon is installed. The System Daemon gets loaded whether or not there is a user session; it's wasted resources without one, there's no user to authenticate incoming peering requests and transfers. (At least the Upstart approach ensures the System Daemon doesn't get loaded without a Kernel Driver). The Kernel Driver gets loaded whether or not there is a System Daemon or user session; sure it's small, but it's still a waste of time and effort without them. So I was curious how these problems would be solved in the systemd world? Reading through the documentation I came up with the following: The Kernel Driver is still going to get loaded regardless, because udevd runs modprobe, not systemd. The System Daemon seems to be where systemd is much more clever; a Bluetooth device unit would "want" the System Daemon, but that could be joined with socket/D-Bus Activation right? So the presence of the device creates the socket, but doesn't start the daemon until an actual connection from a Userspace Agent/Applet arrives. But the Userspace Agent/Applet is again going to get started regardless; it'll start up, and connect to the socket, activating the Bluetooth Daemon. In the case where there is no Bluetooth hardware, the socket won't exist so it'll get "connection refused". But you've still wasted the effort of starting a bluetooth agent/applet when there isn't any bluetooth hardware/support on the system. My questions are these: 1) is the above seen as a problem? 2) wouldn't it be better if the need could be communicated at all levels, I'm thinking something like: Moving module loading from udevd to systemd would mean we don't *have* to load the kernel driver, we just know we /can/ should we need to. Likewise we therefore know we /can/ load the system daemon, so the socket would be created for it, but the daemon itself isn't loaded and the module isn't loaded just yet. When the user session starts, we know we /can/ load the userspace agent/applet, and since a system daemon also can be loaded, we actually do go ahead and start it - it's a leaf of the can tree. It starts, connects to the socket which activates the system daemon, but beforehand causes the kernel module to be loaded. The case of no bluetooth hardware, or no user session, etc. would simply result in none of the above being started ever. Better or not? Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
Thanks for the reply! On Mon, May 9, 2011 at 11:04 AM, Lennart Poettering wrote: > On Mon, 09.05.11 09:10, Scott James Remnant (sc...@netsplit.com) wrote: > > > This seems to assume that it's a free cost to start a service or process > and > > have it block on a socket. But that isn't true, to get to the point where > it > > connects to the socket, that service or process first has to be loaded > from > > disk, its shared libraries mapped and relocated, it probably has to do a > > bunch of initialization including reading its own configuration files, > > etc. > > > > That's fine for "low priority" services out of the critical path for user > > interaction, but not for services we need as fast as possible. > > We can now boot a resonably complete GNOME userspace in less than > 1s. Given that that is the *total* these days, I really don't > understand why you are concerned about the startup speed of individual > service, and fear timeouts there. > > Because that's on a machine with plenty of L1/L2 Cache, take that away and this becomes a big concern. Especially if 1s is a target boot time ;-) > The best example I can think is the X server itself. It's pretty much the > > definition of the critical path. Everything started before the X server > are > > those basic system components needed to start the X server, I understand > in > > systemd that this core part would be a different target to the X part and > a > > dep of it. Everything started after the X server is up are components of > the > > user's session that aren't totally critical for them to login or use > their > > computer. > > X itself is really fast these days. While there's room for improvement > it's far from the biggest speed bump right now. (LVM is) > > LVM isn't on our system. X is the biggest bump along with Chromium. > Firstly we have to spawn the X server, load the executable, map and > relocate > > shared libraries, all of that jazz. You don't want anything else > happening > > on the system alongside this, and you most certainly don't want every X > > client (Chromium/Firefox!) being loaded at the same time. The default > > behaviour of systemd seems to be to do just this :-( > > Well, there's more than 30 years research in modern CPU and IO scheduler > technology for the kernel. Instead of second guessing those from > userspace I'd just entrust them that they pick something like the > optimal order. And if they don't, then go and optimize them for the new > workloads, don't bypass them by scheduling things in userspace. > > I'm glad you answered this way, because my thinking was in this direction too. The scheduler isn't that great in Linux at times, as we all know, because it lacks information about what's important. Since the kernel is able to schedule efficiently by cgroup, the ideal seems to be to start everything at once *but with different priorities* so that the services come up in something approaching a sane order. We did something like this back in Ubuntu, all fsck processes are started simultaneously and we used I/O priorities to ensure only one was running at a time for any given physical disk. This worked awesomely well. Obviously this "startup priority" isn't the same as the eventual priority you'd want the service to settle at, you'd want it to be pretty flexible - perhaps even changing a few times. > Lastly there's the processes you'd start after X is up and services are > > connecting to it; again I assume this would be a different target - how > > would systemd know that X, and the critical X services/processes are > fully > > up and that it can begin starting these. The important thing here is user > > latency - the startup of these services need to not noticeably impact > system > > performance - not as simple as prioritization because the service itself > may > > well need a different priority once its up. Any thoughts here? > > Ignoring that X currently is not socket activatable I see no issue here > at all. > > Really, this came as a surprise to me - don't all clients initially connect to X via its socket? > Also, note that launchd on MacOS does the same thing (including spawning > X like this for X clients). They build their whole OS like this. And it > works really really really well there. All experience with launchd and > systemd tells the same story: socket activation is awesome. Plain awesome. > > You've never had to reboot an iPhone, have you? You need other entertainment while it does so, a copy of the Lord of the Rings sometimes suffices. Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
On Mon, May 9, 2011 at 12:16 PM, Gustavo Sverzut Barbieri < barbi...@profusion.mobi> wrote: > >> Well, right now let's make clear that Firefox/Chromium or other X clients >> won't be started by systemd as they are user session applications, and >> systemd itself will just deal with system context (ie: up to GDM/KDM...). >> > > Really? A major feature of systemd I understood was that it would also manage user sessions as a seamless part of boot along with the system session. Is that not the case? > But using your case, just like I said above, you really want that. You'd > chromium and X11 to be loaded at the same time, because the kernel will > handle the load and may load chromium executable while X11 is doing EDID > read, then may let the dynamic linker work while X11 asks for input device, > etc. > > Or the kernel might load Chromium completely before giving X any time at all; between picking the right thing and the wrong thing, without information, the kernel seems to more usually pick the latter. Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
On Tue, May 10, 2011 at 7:41 AM, Gustavo Sverzut Barbieri < barbi...@profusion.mobi> wrote: > I'm not following all the user-session discussion, but AFAIU this > management will be done by the same code, but not same process (it's not > PID1). PAM (or another entity that has a role in the login/logout) will talk > to systemd (PID1) and ask for a new service to be started to handle this > user-session. This will still be the same code, but of course on the user > context and not handle things like actual reboot/halt of the machine, > mounting system filesystems. But again, I'm not following it closely and I > might be wrong here. > > That's a shame. Having it as a separate process would mean the user session would be started all at once in one go at the end of the boot, rather than with the rest of the boot :-( Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Parallel startup with sockets and without killing the machine?
On Tue, May 10, 2011 at 9:39 AM, Lennart Poettering wrote: > Note that you need to delay execution of user code after the base system > is set up anyway, in order to ensure that the right perms are set on the > volatile and other directories. That means having a single transaction > for both user and system services effectively wins you very little. > > Really, what permissions? The only volatile directories on the system are all tmpfs these days so get passed the permissions in their mount options. Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] device units rely on udev rules?
On Mon, May 9, 2011 at 12:43 PM, Lennart Poettering wrote: > > This means there are a large number of devices already known to the > kernel > > at the point that systemd starts, especially if you build the drivers > into > > the kernel for those devices. It's possible to get going straight away > with > > those devices. But relying on udevd tagging them means you end up waiting > > around for udevd to start, and worse! since udevd doesn't apply rules to > > existing devices on startup, you have to wait around for "udevadm > trigger" > > to be run. > > That's actually dead fast, and systemd picks up those devices as they > show up. The trigger can hence finish after we already preceeded > booting. In fact, with the new netlink actviation in newest udev and > systemd we can start the trigger at the same time as udev itself. > > We cannot really mount file systems before their block devices have > shown up and have been probed, and we exactly wait for that, and no > longer. To do fsck/mount we need udev to have run for that device, > there's no realistic way around that. > > It isn't "dead fast" enough. The problem is that when you run udevadm trigger, it doesn't immediately spawn 700 processes to handle the events. So you end up with situations where input devices aren't available to X because the system is too busy probing for filesystems, or loading sound card drivers. And we really *can* mount file systems before their block devices have been probed (they show up as soon as the driver's loaded). Actually the probing code is exactly the kind of code I would want to delay; filesystems can be mounted by GPT ids which doesn't require the expensive block device probing. To my mind, we would want the filesystem mounted as soon as the kernel event arrives, whether or not udevd is running and whether or not udevadm trigger has been run. > udev isn't just about symlinks. It's about perms and primarily about > meta data, and a lot of other stuff too. > > perms are increasingly irrelevant due to ACLs, which your plans are moving to systemd, no? Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Communicating need
On Mon, May 9, 2011 at 4:32 PM, Lennart Poettering wrote: > On Mon, 09.05.11 13:13, Scott James Remnant (sc...@netsplit.com) wrote: > > > The System Daemon seems to be where systemd is much more clever; a > Bluetooth > > device unit would "want" the System Daemon, but that could be joined with > > socket/D-Bus Activation right? So the presence of the device creates the > > socket, but doesn't start the daemon until an actual connection from a > > Userspace Agent/Applet arrives. > > Well, systemd allows you to do such a thing, but I don't think we want > this really. > > Let me give you another example, then. I've already touched in the other thread on the problem with input devices being delayed by other probing work udev is doing. Actually, it's more than that. When we start the X server it enumerates the "udev known" input devices on the system, since getting something on the screen is our top priority, the X server comes up before that udevadm trigger (and maybe even before udevd is running - I don't think there's a dep there). Obviously there are no devices, and they are not tagged ID_INPUT by udev, so X sees no devices. It's not until a few seconds later that the show up - udevadm trigger may take meer hundreds of milliseconds (that sounds cheap to you, expensive to us :p) but it takes udevd many seconds to actually deal with the result. In my ideal world, the X server starting up and asking for input devices would "activate" the probes on those devices (and even load modules if necessary - though for us they're built-in), so that the information is delivered in a timely manner. > 2) wouldn't it be better if the need could be communicated at all levels, > > I'm thinking something like: > > > > Moving module loading from udevd to systemd would mean we don't *have* to > > load the kernel driver, we just know we /can/ should we need to. > > This would be kernel 2.2 style module loading? I think that makes sense > only for very few devices, mostly static singleton, even virtual devices > only. > > Well, that style loading was "on activation" whereas you seem to be arguing for "on event" here ;-) I thought systemd was all about the former, whereas Upstart was all about the latter :p Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Communicating need
On Thu, May 12, 2011 at 6:59 PM, Gustavo Sverzut Barbieri < barbi...@profusion.mobi> wrote: > > Well, maybe you didn't get the activation part or you're trolling :-) > > Neither... > As I said in my mail about the bluetooth part, the problem with kernel > modules is that "you don't know what's in there until you look in there". If > you don't have usb subsystem you can't know an usb sound card may be there > :-D Same for audio device on bluetooth on usb, etc. > > But if you have a USB subsystem, you *do* know what the devices are before loading the modules - USB, PCI, etc. all have the notion of a "device class" that tells you what kind of thing it is. And while upstart was indeed all about "events" (at least 3 years ago it > was), systemd provides multiple ways to handle services, not just socket > activation, but timers, various conditionals (paths, directories...) and > events. You used to force one direction in the graph, we offer both. > > You appear to be confusing my mails with someone who isn't genuinely of the opinion that Upstart doesn't work, and is trying to gather information about the other kid in town to see whether that solves problems he's encountered since. Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Communicating need
On Mon, May 16, 2011 at 2:23 PM, Lennart Poettering wrote: > Our entire userspace bootup takes <1s here on an older X300. I think > nobody expects that the mouse reacts any quicker than that. > > Your "older X300" is probably rather more powerful than a single-core Atom CPU. > But as mentioned elsewhere: if this really is a problem we could modify > udev trigger to sort the devices according to some user specific rules > before triggering them. That way we can ensure that input gets triggered > before network, or whatever else you want to express. > > But again, I'd really like to see this profiled before look into > this. Right now if userspace booting takes < 1s this should be more then > sufficiently good for desktop machines, include ChromeOS machines. > > It depends what you mean by "userspace booting". We are able to start the entire system, X server and Chromium browser in about 2.2s It takes about 5-6s for udev to run input_id on the keyboard + touchpad, and thus for them to be available to X. Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Communicating need
On Mon, May 16, 2011 at 2:46 PM, Lennart Poettering wrote: > > It takes about 5-6s for udev to run input_id on the keyboard + touchpad, > and > > thus for them to be available to X. > > How come this takes so long? > > Does this actually delay X? Nromally X should be fine without kbd/mouse > and then be able to make use of it the moment it becomes available? > > Well, X is sitting there with a nice screen that the user can't use because the keyboard and touchpad don't work yet ... so no, it doesn't delay X, it delays the user experience ;-) Scott ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] generators, private /tmp
Hi everyone, The system manager (as of v253) executes generators in a sandbox with a fresh tmpfs mount on /tmp: https://github.com/systemd/systemd/blob/a526b9ddfc03a290f20a65c0a73792e73029f1b8/src/core/manager.c#L4274 Looking at the code, it appears that there is no way to disable that using, say, an environment variable or a config file setting. Is that correct? Thanks, -James M
Re: [systemd-devel] generators, private /tmp
> > Hi everyone, > > > > The system manager (as of v253) executes generators in a sandbox with a > > fresh tmpfs mount on /tmp: > > > > > > https://github.com/systemd/systemd/blob/a526b9ddfc03a290f20a65c0a73792e73029f1b8/src/core/manager.c#L4274 > > > > Looking at the code, it appears that there is no way to disable that using, > > say, an environment variable or a config file setting. > > > > Is that correct? > > Yes. > > Generators run during earliest boot, where /tmp/ is quite likely not > mounted yet, hence generators do not have access to the system's /tmp/ > and get a transient one. > Thanks for your reply. Is my second statement also correct? i.e. is there no way to prevent mounting a private /tmp when executing generators using something like an environment variable or config setting? I see the condition !MANAGER_IS_TEST_RUN(m) guards the flag FORK_PRIVATE_TMP but that seems to be just for testing. -James M
Re: [systemd-devel] generators, private /tmp
> > > > Hi everyone, > > > > > > > > The system manager (as of v253) executes generators in a sandbox with a > > > > fresh tmpfs mount on /tmp: > > > > > > > > > > > > https://github.com/systemd/systemd/blob/a526b9ddfc03a290f20a65c0a73792e73029f1b8/src/core/manager.c#L4274 > > > > > > > > Looking at the code, it appears that there is no way to disable that > > > > using, say, an environment variable or a config file setting. > > > > > > > > Is that correct? > > > > > > Yes. > > > > > > Generators run during earliest boot, where /tmp/ is quite likely not > > > mounted yet, hence generators do not have access to the system's /tmp/ > > > and get a transient one. > > > > > > > Thanks for your reply. > > > > Is my second statement also correct? > > > > i.e. is there no way to prevent mounting a private /tmp when executing > > generators using something like an environment variable or config setting? > > There is none. I am considering preparing a patch that makes it configurable via system.conf. e.g., "GeneratorsUsePrivateTmp=yes" Would a contribution like that be welcome? -James M
[systemd-devel] systemd-bootchart, switch-root breakage
Is anyone else using systemd-bootchart on a system that boots using an initial ramdisk? (e.g. like Fedora 41) I am fighting with two issues and am looking for some advice. **1. systemd-bootchart stops too early** According to “man systemd-bootchart”, the recommended way to invoke bootchart is via a kernel parameter: init=/usr/lib/systemd/systemd-bootchart That parameter causes systemd-bootchart to be executed as the new init process when we switch into the real root filesystem. bootchart does run, but it stops too early. In /etc/systemd/bootchart.conf, I have bootchart configured to collect 1800 samples at a frequency of 10 samples per sec. It should run for about 3 minutes. When I login, the svg file is already present under /run/log (but the system has only been up for about 10 secs). Doing “grep bootchart /proc/*/cmdline” when I login shows that bootchart is not running. **2. systemd-bootchart errors out during switch root** In this case, I have systemd-bootchart added to the initial ramdisk and execute it via the “rdinit” kernel parameter: rdinit=/usr/lib/systemd/systemd-bootchart In the systemd-bootchart source, you can see that the first character of its argv[0] is changed to “@”, so bootchart should survive the switch-root killing spree. Unfortunately, bootchart errors out during switch root because it wants to read /proc/schedstat and it is not available (I have an strace log confirming that). There seems to be a time-of-check / time-of-use issue in the code -- it checks that the proc filesystem is available, but then when it goes to read /proc/schedstat the file is not there (ENOENT). Has anyone else come across these? Should I open github issues? I can try creating a PR to fix issue 2. Thanks, -James M
Re: [systemd-devel] switch-root, init, SIGHUP
> > I think the SIGHUP must come from the new PID 1. > > I don't know if this will help you, however here is a program that I > wrote last year that starts a service in the initramfs, it survives > the systemd killing spree during the transition to the root > filesystem, a new copy of the program is started from the root > filesystem, the previous running state is passed from the initramfs to > the version started from the root filesystem, and the version started > from the initramfs is gracefully shut down. The program does not have > the SIGHUP issue that you describe, so maybe there's something here > that may help you. > > https://github.com/masneyb/early-service-example Thanks very much for this pointer! I will take a closer look at your code since I would indeed prefer to start my process (and systemd-bootchart) in the initrd. I had tried doing that using "rdinit=" and did observe that the SIGHUP problem does not occur in that case (btw, it is SIGHUP followed by SIGCONT). For systemd-bootchart, after it does some initial set-up, it only reads files under /proc (and it keeps a directory stream to /proc open). Unfortunately, the switch-root operation somehow causes /proc/schedstat to become inaccessible, so systemd-bootchart is broken with "rdinit=" as well. -James M
[systemd-devel] switch-root, init, SIGHUP
I have a program, init-jm, that forks and executes /usr/lib/systemd/systemd in the parent (using execl() ) while the child collects some stats in a loop. The child sets its argv[0][0] to ‘@’. init-jm is invoked using the “init” kernel parameter on a switch-root system (it’s Fedora 41). Can someone explain why systemd (PID 1) sends SIGHUP to the child? This happens just before the statement log_execution_mode(&first_boot) is executed inside main(). Sending SIGHUP to the child seems to be particular to the re-execution of the systemd binary during switch-root because it is not sent when init-jm is invoked using “rdinit”. Thanks, -James M
Re: [systemd-devel] switch-root, init, SIGHUP
> I suspect that your process has a controlling tty based on this comment
> in the killall() function at src/shared/killall.c:
>
>if (send_sighup) {
>/* Optionally, also send a SIGHUP signal, but only if the process
> has a controlling
> * tty. This is useful to allow handling of shells which ignore
> SIGTERM but react to
> * SIGHUP. We do not send this to processes that have no
> controlling TTY since we
> * don't want to trigger reloads of daemon processes. Also we make
> sure to only send
> * this after SIGTERM so that SIGTERM is always first in the
> queue. */
> ...
>}
>
> Also systemd >= v255 (Fedora 41 has v256) has the directive
> SurviveFinalKillSignal=yes that can be used instead of setting
> argv[0][0] = '@'.
Hi Brian. Thanks very much for your reply.
When I grepped for sighup in the systemd source, I did find the function
killall().
The sighup should not be coming from there because my process has argv[0][0] ==
‘@’ and there is a check for that in the killall() for-loop (it is done in the
static function ignore_proc()).
Also, my process does not have a controlling tty (it is being invoked using the
“init” kernel param).
There is no tty shown when I view its details using ps, and I also don’t see
any ttys when I do “ls -l /proc//fd”.
Any other suggestions?
Maybe I should open a github issue for this.
-James M
Re: [systemd-devel] switch-root, init, SIGHUP
> > I have a program, init-jm, that forks and executes > > /usr/lib/systemd/systemd in the parent (using execl() ) while the > > child collects some stats in a loop. > > Uh, you can do this, but it's not trivial to get right: you need to > move yourself down the cgroup tree, because otherwise you'll collide > with cgroup's no-processes-in-inner-cgroup-nodes rule. Create two > cgroups in the root of the cgroup tree, then put your stuff in one, > and invoke systemd in the other. That's the only "correct" way to do > this, so that your stuff runs reasonably isolated from systemd. Thanks very much for your reply. I was not aware of this cgroup rule. I will read more about that. > > The child sets its argv[0][0] to '@'. > > > > init-jm is invoked using the "init" kernel parameter on a switch-root > > system (it's Fedora 41). > > > > Can someone explain why systemd (PID 1) sends SIGHUP to the child? > > Are you sure you are setting argv[0][0] properly? the killing spree we > do on switch root should exclude processes marked like that. When I check /proc//cmdline, I see the '@' character. It is not clear to me if the '@' is necessary because the process is invoked using the "init" kernel parameter. Doesn't that mean it gets executed after the switch-root killing spree? (i.e. it gets executed when PID 1 from the initial ramdisk re-executes to run the new init). I think the SIGHUP must come from the new PID 1. > Note that we'll also possibly reinitialize the tty on switch root, > maybe your tool has the tty open and gets a SIGHUP because of that. Brian M also suggested that might be the cause, but I don't see any ttys when I do "ls -l /proc//fd". This pattern (fork and exec /usr/lib/systemd/systemd in the parent) is used by systemd-bootchart. If you invoke systemd-bootchart using the "init" kernel parameter on Fedora 41 (which is the recommended way), then you will hit this SIGHUP (and bootchart exits when it receives SIGHUP, so this breaks it). That appears to have been not working for a while (e.g. it does not work with systemd v251). There is an strace log here: https://github.com/systemd/systemd-bootchart/issues/58 -James M
Re: [systemd-devel] switch-root, init, SIGHUP
> > It is not clear to me if the '@' is necessary because the process is > > invoked using the "init" kernel parameter. > > That detail doesn't matter. It's irrelevant how the process gets > started. In particular as I understand you you fork()ed once, > i.e. init= starts PID 1, but this is not PID 1 we are talking about > here... I did not mean to imply that a process forked from "init=" gets special treatment. I only mentioned "init=" because I think it implies an ordering wrt the switch-root killing spree. > > Doesn't that mean it gets executed after the switch-root killing > > spree? (i.e. it gets executed when PID 1 from the initial ramdisk > > re-executes to run the new init). > > do you actually invoke the systemd binary in the initrd already, and > the ask it to switch root, or how does that work? I am working with a vanilla Fedora 41 image. systemd runs as PID 1 in the initrd. The process I specify using "init=" is invoked as part of the normal switch-root flow (when systemd from the initrd calls execve() ). > > I think the SIGHUP must come from the new PID 1. > > sigaction() actually tells you exactly where a signal comes from, if > you let it via the siginfo_t structure optionally delivered to your > signal handler. hence you can relatively easily figure this out. The > si_pid specifies the source pid. And si_code tells you if this was > sent by the kernel or by userspace, i.e. SI_KERNEL, SI_USER and so on. The strace log I pointed to shows PID 1 sent the signal. However, there is PID 1 from the initrd and the new PID 1 from the real root file system. It must be the new PID 1 that sends the SIGHUP. > > > Note that we'll also possibly reinitialize the tty on switch root, > > > maybe your tool has the tty open and gets a SIGHUP because of that. > > > > Brian M also suggested that might be the cause, but I don't see any > > ttys when I do "ls -l /proc//fd". > > it's not so much about that, but about which ctty your process has. There is no controlling tty listed in the output of "ps". -James M
Re: [systemd-devel] systemd-bootchart, switch-root breakage
> **1. systemd-bootchart stops too early** > > According to "man systemd-bootchart", the recommended way to invoke bootchart > is via a kernel parameter: > > init=/usr/lib/systemd/systemd-bootchart > > That parameter causes systemd-bootchart to be executed as the new init > process when we switch into the real root filesystem. > > bootchart does run, but it stops too early. > > In /etc/systemd/bootchart.conf, I have bootchart configured to collect 1800 > samples at a frequency of 10 samples per sec. It should run for about 3 > minutes. > > When I login, the svg file is already present under /run/log (but the system > has only been up for about 10 secs). > > Doing "grep bootchart /proc/*/cmdline" when I login shows that bootchart is > not running. I opened https://github.com/systemd/systemd-bootchart/issues/58 to track this. The issue is worse than systemd-bootchart stopping too early. The genenerated svg is actually a zero byte file.
Re: [systemd-devel] systemd-bootchart, switch-root breakage
> Isn't systemd-bootchart, like, dead? Last release is nine years old or so. The last release of systemd-bootchart, v235, was done in November 2023: https://github.com/systemd/systemd-bootchart/tags There hasn’t been much activity lately, but I wouldn’t call it dead (there are a few PRs open that should be merged). The svg files produced by systemd-bootchart are more detailed than the ones produced by “systemd-analyze plot” (with bootchart, you can see the various processes that get run when a unit is invoked).
Re: [systemd-devel] systemd-bootchart, switch-root breakage
> I opened https://github.com/systemd/systemd-bootchart/issues/58 to track > this. Could someone explain why systemd-bootchart is being sent SIGHUP? Changing systemd-bootchart to ignore that signal isn’t difficult, but I would like to understand why PID 1 is sending it. Note that systemd-bootchart is invoked using the “init” kernel parameter.
[systemd-devel] systemd-tmpfiles, unsafe path transitions
I am doing dev work on a linux system and I am mounting the root filesystem via NFS to make my work-flow easier. Unfortunately, the directory I am NFS mounting is not owned by root, and this causes some of the directives processed by the systemd-tmpfiles utility during boot (e.g. in systemd-tmpfiles-setup.service) to fail due to unsafe path transitions: Detected unsafe path transition / (owned by ) -> /run (owned by root) during canonicalization of run/log/… Is there a conf option or an environment variable I can use to disable the unsafe path transition check? Failing that, is there a way I can change the ownership systemd-tmpfiles sees? Thanks, -James M
Re: [systemd-devel] systemd-tmpfiles, unsafe path transitions
> > Is there a conf option or an environment variable I can use to disable the > > unsafe path transition check? > > No there is not. It's a security hole what you are doing there... > > > Failing that, is there a way I can change the ownership systemd-tmpfiles > > sees? > > Why not just fix the ownership of the root inode? i.e. actually fix > the original problem that causes the message to show? The root filesystem is mounted read-only because the nfs server only allows read-only exports (i.e. "ro"). So, "chown root:root /" does not work on the client. And on the server, I do not have root access.
Re: [systemd-devel] systemd-tty-ask-password-agent, new warning
>>> Is systemd-tty-ask-password still an optional component? >>> >>> Is this new behaviour (where systemd-tty-ask-password is repeatedly >>> executed) intentional? >> >> It is not new behavior. systemctl did it for as long as I remember. > > Okay. But the display of the warning is new behaviour. > > Was the warning just not visible or not generated before? > > Should systemd-tty-ask-password not be considered an optional component? Answering my own question: yes, the warning / failure message was not visible until recently (v255.10). The following commit adds a log statement to exec-util,c and that is why it has appeared: https://github.com/systemd/systemd-stable/commit/76fe6ebee8 Any comment on my other question: is systemd-tty-ask-password an optional component? -James M
