Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
Too used to "reply to all". well... Hi Lucas, Maybe, maybe not. It was not said publicly in that thread, but some systemd guys are nacking this due to the JS engine it would provide. Tom contacted me in private to tell me this is put on hold (though himself, he really want that service to get in, as Lennart and David). I guess the time people get convinced somehow. I'll probably come back to that in the end of September, I am fully busy with other things right now. If there is really nothing to be done on systemd side, then there loss. We will improve PACrunner and that's it. Br, Tomasz Hi Tomasz, On Fri, Apr 10, 2015 at 9:17 AM, Tomasz Bursztyka wrote: Hi, As it has been discussed in the systemd hackfest during the Linux Conference Europe, one daemon could centralize the management of all network proxy configurations. Idea is something user can do per-application (like in firefox for instance) or broader (per-DM like in Gnome), user could do it once and for all through such daemon and applications would then request it to know whether or not a proxy has to be used and which one. As a notice, this is nothing new. Such standalone daemon has been already done by the past, pacrunner. systemd-proxy-discoveryd will more or less implement the same ideas with improvements. It will get rid of big JS engines like spidermonkey or v8 which are overkill for the tiny PAC files to be executed on, for instance. From pacrunner experience, APIs will be also improved. This one is using - at least in this RFC - the duktape JS engine to run the PAC files. Note it is not provided in this patchset. Latest version 1.2.x was used. Next features to come are a bit detailed in the TODO (last patch). Tomasz Bursztyka (6): proxy-discoveryd: Basic core added proxy-discoveryd: Add the basics for parsing the default configuration proxy-discoveryd: Add PAC support through duktape js engine proxy-discoveryd: Execute the PAC based proxy in a thread proxy-discoveryd: Add the basic parts for handling DBus methods update TODO What happened to this patch set? Are you going to send a new version? Lucas De Marchi ___ 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] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
Hi Lucas, Maybe, maybe not. It was not said publicly in that thread, but some systemd guys are nacking this due to the JS engine it would provide. Tom contacted me in private to tell me this is put on hold (though himself, he really want that service to get in, as Lennart and David). I guess the time people get convinced somehow. I'll probably come back to that in the end of September, I am fully busy with other things right now. If there is really nothing to be done on systemd side, then there loss. We will improve PACrunner and that's it. Br, Tomasz Hi Tomasz, On Fri, Apr 10, 2015 at 9:17 AM, Tomasz Bursztyka wrote: Hi, As it has been discussed in the systemd hackfest during the Linux Conference Europe, one daemon could centralize the management of all network proxy configurations. Idea is something user can do per-application (like in firefox for instance) or broader (per-DM like in Gnome), user could do it once and for all through such daemon and applications would then request it to know whether or not a proxy has to be used and which one. As a notice, this is nothing new. Such standalone daemon has been already done by the past, pacrunner. systemd-proxy-discoveryd will more or less implement the same ideas with improvements. It will get rid of big JS engines like spidermonkey or v8 which are overkill for the tiny PAC files to be executed on, for instance. From pacrunner experience, APIs will be also improved. This one is using - at least in this RFC - the duktape JS engine to run the PAC files. Note it is not provided in this patchset. Latest version 1.2.x was used. Next features to come are a bit detailed in the TODO (last patch). Tomasz Bursztyka (6): proxy-discoveryd: Basic core added proxy-discoveryd: Add the basics for parsing the default configuration proxy-discoveryd: Add PAC support through duktape js engine proxy-discoveryd: Execute the PAC based proxy in a thread proxy-discoveryd: Add the basic parts for handling DBus methods update TODO What happened to this patch set? Are you going to send a new version? Lucas De Marchi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev-buildin-net_id.c hotplug slot with SRIOV
On 14.08.2015 02:39, Keller, Jacob E wrote: Hello, I discussed this a while ago, but I have found that the hotplug slot names for ethernet devices gets confused when SRIOV is used. Basically: I have a device plugged into a hotplug slot, and it gets enps for its PCI path name. For the slot, it gets ens Example: enp5s0 ens1 However, this device has SR-IOV functionality, and it creates new VFs which appear at different functional bus:slot.func values. In this device's case, as long as the particular layout for VFs puts these in only functions 1-7 then I get ens1f1 ens1f2 ens1f3 that is all great. However, devices are free to layout their SR-IOVs into PCI cfg space at separate slots, ie: enp5s1f0 etc. The issue comes up because *now* the hotplug slot functionality no longer works: for some of the VFs, I get devices named above, others now get enp5s1f0 and so forth. This is very confusing to the user as they use this device and don't understand why it gets alternating user schemes. I believe the error results from line 248 of udev-builtin-net_id.c In this case, we check if we're a hotplug slot by checking if the bus *and* slot are both equivalent. However, on my system all the hotplug slots are always only at a specific bus, and not at a non-zero slot. Could you show lspci -t with VF created? I honestly am not sure if this is a guarantee. Maybe I am wrong here? If this is the case, then I'd suggest a modification to the hotplug ules, so that it will match all :05:XX.X to match that slot at :05:00.0, rather than only the functions. I am not sure what the correct name scheme would be for ens1(some subscript letter) would have to be. However, it seems that the code is wrong today, and I end up having to remove the hotplug slot from among the options when using this device. Does anyone have any better suggestions? Regards, Jake ___ 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] Failed at step RUNTIME_DIRECTORY spawning /usr/bin/true: File exists
Am 14.08.2015 um 02:28 schrieb Ivan Shapovalov: On 2015-08-10 at 15:46 +0200, Reindl Harald wrote: Am 10.08.2015 um 15:28 schrieb Ivan Shapovalov: On 2015-08-10 at 15:14 +0200, Reindl Harald wrote: Am 10.08.2015 um 15:05 schrieb Ivan Shapovalov: On 2015-08-10 at 11:16 +0200, Reindl Harald wrote: Moreover, * "RuntimeDirectory" is a service configuration * the daemon is started as unprivileged user * "RuntimeDirectory" should be created long before ExecStart / ExecStartPost This is wrong. The runtime directory "will be created <...> when the unit is started, and removed when the unit is stopped". what is wrong? The runtime directory should be created right before the unit is started, not "long before ExecStart / ExecStartPost". so why trying to create it before "ExecStart" *and* "ExecStartPost" Because there may be no ExecStart= but ExecStartPost=. how would that matter when "RuntimeDirectory" is just created at service start and removed at service end independent of any other lines? "unit is started" is for me pretty clear the whole systemd-unit As can be seen from the code, the runtime directory creation is attempted on execution of each configured process, be it ExecStart= or ExecStartPost= (or whatever else) and why in the world is the code written that way? This is pointless rhetoric. no it is not pointless rhetoric it's a serious question See above. Doing explicit checks against existence of certain entries or implementing an ad-hoc FSM is way more fragile than just writing idempotent code not it is not mkdir, chown, chgrp, chmod at the very begin is fore sure not fragile, the expected behavior, free from race-conditions and that the "idempotent code" is more fragile was already proven by the race condition of that topic if the Fedora maintainer would care about such bugs it won't do that much harm, but they exists until the middle of a release lifetime signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed at step RUNTIME_DIRECTORY spawning /usr/bin/true: File exists
On 2015-08-10 at 15:46 +0200, Reindl Harald wrote: > > Am 10.08.2015 um 15:28 schrieb Ivan Shapovalov: > > On 2015-08-10 at 15:14 +0200, Reindl Harald wrote: > > > > > > Am 10.08.2015 um 15:05 schrieb Ivan Shapovalov: > > > > On 2015-08-10 at 11:16 +0200, Reindl Harald wrote: > > > > Moreover, > > > > > > > > > > > > > > * "RuntimeDirectory" is a service configuration > > > > > * the daemon is started as unprivileged user > > > > > * "RuntimeDirectory" should be created long before > > > > > ExecStart / ExecStartPost > > > > > > > > This is wrong. The runtime directory "will be created <...> > > > > when > > > > the unit is started, and removed when the unit is stopped". > > > > > > what is wrong? > > > > The runtime directory should be created right before the unit is > > started, not "long before ExecStart / ExecStartPost". > > so why trying to create it before "ExecStart" *and* "ExecStartPost" Because there may be no ExecStart= but ExecStartPost=. > > > "unit is started" is for me pretty clear the whole systemd-unit > > > > > > > As can be seen from the code, the runtime directory creation is > > > > attempted on execution of each configured process, be it > > > > ExecStart= > > > > or > > > > ExecStartPost= (or whatever else) > > > > > > and why in the world is the code written that way? > > > > This is pointless rhetoric. > > no it is not pointless rhetoric > it's a serious question See above. Doing explicit checks against existence of certain entries or implementing an ad-hoc FSM is way more fragile than just writing idempotent code. > > > > there is no logical reason that "RuntimeDirectory" created once > > > would > > > disappear while starting the other processes as well as > > > tempfiles.d > > > which get replaced by "RuntimeDirectory" isn't fired all the time > > > > Why do you think that it would disappear between starting two > > processes > > belonging to the same unit? > > why do the developers think that? See above. > if they don't think so why attempt creation for *each configured > process* of the same systemd-unit? > > > The runtime directory is destroyed when a > > unit enters inactive state. systemd always attempts to create it > > when > > it forks off a control process, just (I guess) because it's more > > robust > > to do it that way rather than to implement a separate state machine > > just for that purpose. Now, there was a TOCTOU-style race > > condition, > > and it got fixed indeed as far as I can see > > yes, the race condition seems now to be fixed > > but it would have been impossible to happen if *really* "The runtime > directory should be created right before the unit is started" would > be > the implementation because there would be no second (needless) attemt > to create it See above. -- Ivan Shapovalov / intelfx / > but a single point of early code which creates it with the > correct permissions and any following ExecStart* could rely that it > exists signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udev-buildin-net_id.c hotplug slot with SRIOV
Hello, I discussed this a while ago, but I have found that the hotplug slot names for ethernet devices gets confused when SRIOV is used. Basically: I have a device plugged into a hotplug slot, and it gets enps for its PCI path name. For the slot, it gets ens Example: enp5s0 ens1 However, this device has SR-IOV functionality, and it creates new VFs which appear at different functional bus:slot.func values. In this device's case, as long as the particular layout for VFs puts these in only functions 1-7 then I get ens1f1 ens1f2 ens1f3 that is all great. However, devices are free to layout their SR-IOVs into PCI cfg space at separate slots, ie: enp5s1f0 etc. The issue comes up because *now* the hotplug slot functionality no longer works: for some of the VFs, I get devices named above, others now get enp5s1f0 and so forth. This is very confusing to the user as they use this device and don't understand why it gets alternating user schemes. I believe the error results from line 248 of udev-builtin-net_id.c In this case, we check if we're a hotplug slot by checking if the bus *and* slot are both equivalent. However, on my system all the hotplug slots are always only at a specific bus, and not at a non-zero slot. I honestly am not sure if this is a guarantee. Maybe I am wrong here? If this is the case, then I'd suggest a modification to the hotplug ules, so that it will match all :05:XX.X to match that slot at :05:00.0, rather than only the functions. I am not sure what the correct name scheme would be for ens1(some subscript letter) would have to be. However, it seems that the code is wrong today, and I end up having to remove the hotplug slot from among the options when using this device. Does anyone have any better suggestions? Regards, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC 0/6] A network proxy management daemon, systemd-proxy-discoveryd
Hi Tomasz, On Fri, Apr 10, 2015 at 9:17 AM, Tomasz Bursztyka wrote: > Hi, > > As it has been discussed in the systemd hackfest during the Linux Conference > Europe, one daemon could centralize the management of all network proxy > configurations. Idea is something user can do per-application (like in > firefox for instance) or broader (per-DM like in Gnome), user could do it > once and for all through such daemon and applications would then request it > to know whether or not a proxy has to be used and which one. > > As a notice, this is nothing new. Such standalone daemon has been already > done by the past, pacrunner. systemd-proxy-discoveryd will more or less > implement the same ideas with improvements. It will get rid of big JS > engines like spidermonkey or v8 which are overkill for the tiny PAC files > to be executed on, for instance. From pacrunner experience, APIs will be > also improved. > > This one is using - at least in this RFC - the duktape JS engine to run > the PAC files. Note it is not provided in this patchset. Latest version > 1.2.x was used. > > Next features to come are a bit detailed in the TODO (last patch). > > Tomasz Bursztyka (6): > proxy-discoveryd: Basic core added > proxy-discoveryd: Add the basics for parsing the default configuration > proxy-discoveryd: Add PAC support through duktape js engine > proxy-discoveryd: Execute the PAC based proxy in a thread > proxy-discoveryd: Add the basic parts for handling DBus methods > update TODO What happened to this patch set? Are you going to send a new version? Lucas De Marchi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Why is my docked idle laptop suspended?
Hi list, I'm trying to figure out why is my laptop automatically suspended after being idle in a docking station. As far as I understand, logind should not suspend when the laptop is docked or external monitor is connected. Below is the (partially filtered) system log of what happens before the suspend. Things start at 17:34:09 when my screensaver sets IdleHint. Few minutes later (17:37) something happens and the logind suspends the system. I don't expect that network manager, active at the same time, can cause this. When looking at function manager_is_docked_or_external_displays(), when my system is docked, I should see "System is docked." message, but instead I see "External (1) displays connected." Can it be that the monitor powers down automatically and logind suspends the system because it is not aware of being docked? If yes, how can I make logind be aware of being docked? Thank you. -Michal Aug 13 17:34:09 steelpick systemd-logind[16201]: Got message type=method_call sender=:1.39 destination=:1.224 object=/org/freedesktop/login1/session/_32 interface=org.freedesktop.login1.Session member=SetIdleHint cookie=34 reply_cookie=0 error=n/a Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=GetConnectionUnixUser cookie=3105 reply_cookie=0 error=n/a Aug 13 17:34:09 steelpick systemd-logind[16201]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.224 object=n/a interface=n/a member=n/a cookie=2170 reply_cookie=3105 error=n/a Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/login1/session/_32 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=3106 reply_cookie=0 error=n/a Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/login1/seat/seat0 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=3107 reply_cookie=0 error=n/a Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/login1/user/_1000 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=3108 reply_cookie=0 error=n/a Aug 13 17:34:09 steelpick systemd-logind[16201]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/login1 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=3109 reply_cookie=0 error=n/a Aug 13 17:34:09 steelpick systemd-logind[16201]: device-enumerator: scan all dirs Aug 13 17:34:09 steelpick systemd-logind[16201]: device-enumerator: scanning /sys/bus Aug 13 17:34:09 steelpick systemd-logind[16201]: device-enumerator: scanning /sys/class Aug 13 17:34:09 steelpick systemd-logind[16201]: External (1) displays connected. Aug 13 17:34:09 steelpick systemd-logind[16201]: Refusing operation, as it is turned off. ... Aug 13 17:37:48 steelpick NetworkManager[1420]: (wlan0): DHCPv4 state changed bound -> bound Aug 13 17:37:48 steelpick NetworkManager[1420]: (wlan0): Lowering IPv6 MTU (1280) to match device MTU (0) Aug 13 17:37:48 steelpick NetworkManager[1420]: (wlan0): IPv6 MTU (0) smaller than 1280, adjusting Aug 13 17:37:48 steelpick NetworkManager[1420]: (wlan0): Raising device MTU (0) to match IPv6 MTU (1280) Aug 13 17:37:48 steelpick dbus[1307]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' Aug 13 17:37:48 steelpick dhclient[22949]: bound to 147.32.219.249 -- renewal in 261 seconds. Aug 13 17:37:48 steelpick systemd[1]: Starting Network Manager Script Dispatcher Service... Aug 13 17:37:48 steelpick systemd-logind[16201]: Got message type=signal sender=:1.0 destination=n/a object=/org/freedesktop/systemd1/unit/NetworkManager_2ddispatcher_2eservice interface=org.freedesktop.DBus.Properties member=P Aug 13 17:37:48 steelpick NetworkManager[1420]: sleep requested (sleeping: no enabled: yes) Aug 13 17:37:48 steelpick systemd-logind[16201]: device-enumerator: scan all dirs Aug 13 17:37:48 steelpick NetworkManager[1420]: sleeping... Aug 13 17:37:48 steelpick systemd-logind[16201]: device-enumerator: scanning /sys/bus Aug 13 17:37:48 steelpick NetworkManager[1420]: (wlan0): device state change: activated -> unmanaged (reason 'sleeping') [100 10 37] Aug 13 17:37:48 steelpick systemd-logind[16201]: device-enumerator: scanning /sys/class Aug 13 17:37:48 steelpick systemd-logind[16201]: Failed to open configuration file '/etc/systemd/sleep.conf': No such file or directory Aug 13 17:37:48 steelpick systemd-logind[16201]: Suspending... ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Method to Wait for service to complete
On 12.08.2015 21:34, Harry Goldschmitt wrote: I have a service that has to complete before boot can continue. Is there an "approved" method for doing this? "Boot can continue" is a bit vague. It is not possible to insert arbitrary synchronization point at arbitrary place in startup sequence, but it is possible to make e.g. basic.target depend on your service. I have an ugly solution I've come up with... I've created a foo.target to run my foo.service and set the default.target to my foo.target. After my foo.service completes, I'm issuing "systemctl isolate multi-user" to complete the boot. Last time this question came up I think it was exactly the workaround as well. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
