Re: [systemd-devel] keyrings and dbus
On Di, 11.06.19 12:07, Josef Moellers (jmoell...@suse.de) wrote:
> Hi,
>
> We have seen this problem: when you open a gnome-terminal, then the
> shell in that terminal will not have the same keyring (created by
> pam_keyinit.so) as the one eg in an xterm. This is due to the fact that
> the xterm ist started by the standard fork/exec mechanism which passes
> the keyring down to the children and the gnome-teminal (actually
> gnome-terminal-server) is started by sending a dbus message to some
> instance which the starts the terminal process.
>
> AAMOF the gnome-terminal does not even have a keyring, so if one asks
> for it ("keyctl show @s"), it is created on the fly. This causes the
> kernel to create a keyring as a "user session keyring" while the GNOME
> session (and thus the xterm) has a "session keyring".
>
> Has anyone seen this and/or, most important question, does anyone have
> an idea how to solve this?
>
> I know that, strictly speaking, this is not a systemd question, but
> we're trying to probe many sources to see if anyone has a solution.
So, I think you found most of this out already, but the "session"
keyring concept is not particularly useful in today's world where
desktops run with a per-user systemd instance of which most apps are
forked off. Just don't bother with session keyrings besides ensuring
they are propery created. Make sure that every PAM session comes with
pam_keyinit configured, so that they all get their own keyring
properly hooked up (and that includes the PAM session systemd --user
runs as) but other then that, don't make use of it, as it makes no
sense in a world where every session of the same user shares the same
service manager that does not inherit process attributes from the
user's original login session.
Note that usually the user keyring ends up being linked into the
session keyring (if pam_keyinit is properly set up), and hence if some
code does request_key() to find a key it will end up being searched,
hence, if you just insert your keys into the user keyring, then
everything should be great as long as the keyrings are correctly
linked up. Never insert keys into the session keyring though, because
then your other sessions and everything forked off the systemd user
instance won't find it.
I wished they had substantially dumbed down the keyring system. With
all these keyrings that do not make much sense in the actual real-life
world they pretty much created a monster.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is it possible to set a default for MemoryMax?
On Do, 13.06.19 22:06, McKay, Sean (sean.mc...@hpe.com) wrote: > Hi there, > > First off, forgive me if this is documented or discussed somewhere > already. I couldn't find any reference to it in the man pages or in > the mailing list archives, and I'm relatively new to this community > so I could easily be missing something. > > Context that can be skipped if you only care about the technical > part of the question: We're building a customized linux environment > using systemd as the init system, and we've found that some of the > daemons that we're including in said environment aren't particularly > good citizens in regards to their resource consumption (admittedly > most of those are the ones that have been written in house). As a > result, while we try to track down and fix those bugs, we would like > to limit the memory that processes are allowed to consume by default > (with actual values in the .service files overriding that > default). While we understand that this is the sort of thing that's > probably best set individually per-daemon based on an understanding > of how the daemon should behave, it would at least give us a > starting point and would mean that a leaky process would be the one > that crashed (when it hit the memory limit), rather than taking down > the whole system or the OOM killer selecting a different process > that's working correctly but still happens to be using more memory > at the time. > > We've been trying to encourage our developers to use memory > accounting and MemoryMax, since we're given to understand that's > applied to the entire cgroup's memory usage for a given daemon's > slice. The documentation, however, doesn't seem to indicate that a > default value for any of the memory variables can be set in the > system.conf file, and some quick experimental testing seems to > indicate that's truly the case. There does seem to be support for > setting the memory resource limit (limitas), but my understanding is > that wouldn't apply to subprocesses that are spawned off by the > parent daemon - they'd inherit the resource limit, but get their own > instance of it (and I'm actually still trying to figure out if it > would apply to threads, given the way I'm given to understand Linux > treats threads. For memory, it would probably still cap things, > since they're all in the same address space, but I'm unclear if that > would be true of the other limits that can be applied). > > Am I missing something and this is possible to set? Or is it > something that's come up and been rejected for some reason? Or has > it come up and not been important relative to other development > priorities? Or has it simply never come up because we're the first > ones to want to do something so foolish? > > Any insight that you could provide would be greatly appreciated! Thanks. See https://github.com/systemd/systemd/pull/12211 It adds this for MemoryLow=. I see no reason why we shouldn't add this for MemoryMax= too. Please consider pinging @cdown about this, and maybe prep a PR that adds this for you. It should be simple now, given that the MemoryLow= case is very very similar. Or maybe MemoryLow= is actually the knob you want to use and thus what you are asking for already exists in current git? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does "systemctl daemon-reload" discard service information?
On Mo, 20.05.19 20:07, Andrei Borzenkov (arvidj...@gmail.com) wrote: > 20.05.2019 16:36, Ulrich Windl пишет: > > Hi! > > > > I have had the effect that a "systectl status" before and after a > > "daemon-reload" is different, while the service in question wasn't > > restarted: > > > ...> > > Is that intentional? > > > > daemon-reload is known to lose state for years. Some problems get fixed, > new problems appear. Problems range from cosmetic to losing state of > units and jobs causing callers of systemd to "hang" waiting for job > completion. Humm. Have you filed bugs about these? I thought we covered everything now. I am not aware about "new problems appearing"... > Unfortunately daemon-reload is often the only answer to > other reported problems (like in "systemd does not see fstab changes? > Run daemon-reload, where is the problem"). /etc/fstab changes require a "systemctl daemon-reload" to take effect in systemd's unit dep tree. That's because the generators need to be rerun and the generated units reread by systemd. This is documented here: https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/?updated Distros should probably include a comment about that in the default /etc/fstab they ship. If yours doesn't, please file a bug against it, asking them to do so. On Fedora you will find a comment like this in /etc/fstab: # After editing this file, run 'systemctl daemon-reload' to update systemd # units generated from this file. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Unexplainable unit restart ("Start request repeated too quickly")
On Di, 04.06.19 08:24, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > >>> Michael Chapman schrieb am 03.06.2019 um 13:14 in > Nachricht : > [...] > > > > Um, OK. I don't think we're any closer to solving your problem though. :-) > > Actually I am! > The root of the problem is that any oneshot service without > RemainAfterExit=true is listed as "inactive (dead)" after being > started. I think the manual page should be more clear on that fact! Please file a github issue requesting clarification of this fact in the docs. Or even better prep a PR that adds a brief comment about that! > Then if you have a dependency like this (best viewed with a monospaced font): > B > / \ > A-C-E > \ / > D > > where A is a target that wants B,C,D, and each of those in turn wants E > (which is the oneshot service), the following happens: > When starting A, E is NOT started ONCE, but it is started THREE TIMES, while > my expectation was it will be started once only. As I had set a burst limit > of 1, an unexpected fauilure was reported. > > What I'm unsure: Does systemd wait for each "start of E" to > terminate before calling the next one (i.e. serialized), or are the > starts being attempted in parallel? Unless you use "template units", systemd only manages one invocation of a specific service at a time, and that fulfills all deps. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Static IP address on wandering Wi-Fi client
Hi Lennart, >> Is there any way to tell systemd-networkd to use one .network file or >> another depending on which SSID the Wi-Fi interface is connected to? > > This does not currently exist, but it was always the intention to add > this. So far nobody did the work though. > > Most likely this would require some minimal wifi netlink hookup so > that we can properly watch the configured SSID for the interfaces we > watch. Would love to review such a patch. actually this is the wrong approach. You are not getting the full state information back from the netlink interface. You need to talk to a proper WiFi daemon like iwd that has a full understanding of the WiFi state. And frankly IP configuration needs to move into the network technology daemons like iwd for example. Doing that at the level of networkd or NetworkManager is not working out long term. Each technology has a lot of interlinking between the IP configuration and its network technology. There needs to be a split between configuring the network interface and setting up routing and other relationships. The pure IP configuration has to be done by iwd (and soon it will be). Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: Re: Q: ConditionPathExists=
On Di, 04.06.19 14:20, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote: > > ConditionPathExists=/dev/tty0 > > I can only guess that multiple file names are not allowed for > ConditionPathExists to allow file names containing spaces, an off > concept for UNIX, BTW... It indeed would probably make sense to allow multiple paths to specified in one line. Please consider filing an RFE issue about this on github and we'll look into it. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] suggestion: auto reload as the default to help packagers?
Am 17.06.19 um 16:26 schrieb Lennart Poettering: > On Mo, 17.06.19 16:24, Lennart Poettering (mzn...@0pointer.de) wrote: > > [...] > >> On current Linuxes the assumption tends to be that there's only one >> RPM instance or one admin running at a time, and that they schedule >> the configuration reload when they think there work is complete. It's >> basically a transaction logic by linerarization and move the burden to >> manage this onto the user/package manager. > > Addendum: there's also the problem that reloading PID1 in full can be > slow on bigger systems where you have 10Ks of units. hence reloading > all the time willy-nilly might be quite slow. Ideally, RPM would only > reload configuration once after all its work is complete. yeah, and that's why systemd should reload just the affected unit when "systemctl restart" bails that it was changed and make the whole daemon-reload to a normally not used exception ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] suggestion: auto reload as the default to help packagers?
Am 17.06.19 um 16:25 schrieb Lennart Poettering: > On Fr, 31.05.19 14:01, Reindl Harald (h.rei...@thelounge.net) wrote: > >> Am 31.05.19 um 12:31 schrieb Michael Chapman: >>> It also means that the sysadmin can't prepare a set of interconnected >>> changes and have them applied at once. For instance, you might want a >>> timer unit and its associated service unit to be applied at the same time, >>> rather than have the timer fire before the service has been properly >>> configured. >> >> and at least that don't apply when i say "systemctl restart service" by >> hand - frankly - every time when i edit a unit, forget about manual > > Consider using "systemctl edit". it reloads PID 1 after your exit your > editor. that don't excuse a plain wrong behavior either refuse the restart at all when you bail at me about the change you already noticed or just apply it ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] suggestion: auto reload as the default to help packagers?
On Mo, 17.06.19 16:24, Lennart Poettering (mzn...@0pointer.de) wrote: [...] > On current Linuxes the assumption tends to be that there's only one > RPM instance or one admin running at a time, and that they schedule > the configuration reload when they think there work is complete. It's > basically a transaction logic by linerarization and move the burden to > manage this onto the user/package manager. Addendum: there's also the problem that reloading PID1 in full can be slow on bigger systems where you have 10Ks of units. hence reloading all the time willy-nilly might be quite slow. Ideally, RPM would only reload configuration once after all its work is complete. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] suggestion: auto reload as the default to help packagers?
On Fr, 31.05.19 14:01, Reindl Harald (h.rei...@thelounge.net) wrote: > > > Am 31.05.19 um 12:31 schrieb Michael Chapman: > > It also means that the sysadmin can't prepare a set of interconnected > > changes and have them applied at once. For instance, you might want a > > timer unit and its associated service unit to be applied at the same time, > > rather than have the timer fire before the service has been properly > > configured. > > and at least that don't apply when i say "systemctl restart service" by > hand - frankly - every time when i edit a unit, forget about manual Consider using "systemctl edit". it reloads PID 1 after your exit your editor. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] suggestion: auto reload as the default to help packagers?
On Do, 30.05.19 08:16, Roger Pack (rogerdpa...@gmail.com) wrote: > Seeing as one goal of systemd is to DRY up installation and running of > services so that people can't "accidentally mess things up" through > their own init.d files...perhaps that principle could be expanded upon > to help make it so that package creators also can't "accidentally mess > things up"? Maybe the default could be to reload units automatically, > ? With a configuration option to not to, so that package creators > don't *all* have to remember to daemon-reload, since not all do? This is not really feasible on Linux. Linux does not have a transactional file system. This means we never really know when a set of changes made to the fs is complete or when it's ongoing. If we reload instantly and automatically whenever we see a change happeneing, then we might end up reloading at the wrong times: when files are half written, when upgrades still happen and some files are updated and others are not. Automatic reloading of daemons on configuration changes is something that is safe only in very simple, isolated cases, i.e. where you are sure that the writers of the files do so in an "atomic" fashion, i.e. create the files under a hidden, temporary name, write it in full, then move it into place, and where files are comprehensive on their own, i.e. bear no relationship to other files that might be updated in sync. systemd isn't like that, we neither know how people write their files, nor are unit files stand-alone (they configure a dependency tree after all). Hence, if we had a safe way how changes to the fs would always be transaction based, i.e. executed as a whole or not at all, and we only get notification after each transaction is complete and only see the result of completed transactions then we could do things like this, but without that it's always going to create more problems than it solves. On current Linuxes the assumption tends to be that there's only one RPM instance or one admin running at a time, and that they schedule the configuration reload when they think there work is complete. It's basically a transaction logic by linerarization and move the burden to manage this onto the user/package manager. Sorry, Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-bus: Enabling free-standing, bus-independent plain messages
On Do, 23.05.19 11:56, Stanislav Angelovič (angelovi...@gmail.com) wrote: > Hi Lennart, > > Sorry for a bit late reply, I've been quite busy recently. > > > So we could readd the ability to create a bus message with a NULL bus, > > but I am a bit concerned that people then always pass NULL which might > > ultimately result in constant remarshalling if the message is > > eventually enqueued on a real bus. When you put together a message it > > actually matters which bus connection you do that for... > > My proposal is that we would allow passing NULL bus ptr only for > `sd_bus_message_new` function. And such a message would be disallowed from > enqueuing. In functions that need real bus ptr we might place an assert > that bus != NULL. In a limited set of functions, which I mentioned in > previous e-mail (`sd_bus_message_seal` for example), we would allow bus == > NULL. Prepare a patch that does this. If it's minimal and doesn't litter the API with too many new calls, that should be OK. (Note that due to the demise of kdbus, gvariant-over-dbus never really materialized in the end, hence the logic in sd-bus that can generate either is kinda dead. There's hope though that dbus-broker might add this eventually, not sure where that went though. In general I think it would make a ton of sense to switch to gvariant for everything, it just needs somebody to hack it up in dbus-daemon/dbus-broker) > OK, I will try. So we don't introduce any new message factory function > without bus parameter, but make use of existing `sd_bus_message_new`, > right? We will modify it to allow NULL bus ptr. However, this function > needs three things from the bus when initializing message: > `message_version`, `can_fds`, and `allow_interactive_authorization`. What > values shall we use there when bus is NULL? there never was any other version than 1, and fds are off. the allow a_i_a stuff should probably left off, as it doesn't really matter for most cases. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allocating resource to achieve predictable run times
On Mo, 17.06.19 14:15, John Lane (syst...@jelmail.com) wrote: Note that I/O might fuck up your measurements. i.e. make sure you have everything in the page cache already you need, so that you never have to pagefault. More importantly though: use isolcpus= on the kernel cmdline to make sure the kernel will never schedule its own work on the CPUs you want to exclusively assing to a specific set of units. Make sure with /proc/interrupts and /proc/irq that all IRQs are properly dispatched only on the CPUs you don't want your own stuff to run. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev: Access permission of fw character device in which fw node includes unit handled by ALSA
On Mo, 20.05.19 21:27, Takashi Sakamoto (o-taka...@sakamocchi.jp) wrote:
> Hi all,
>
> I'm an ALSA developer, mainly committing to drivers for audio and
> music units on IEEE 1394 bus (yes, it's legacy FireWire). I have a
> concern about access permission for fw character device.
I am not sure I understand firewire well enough to say something too
smart. But if I understand correctly, then we (in systemd upstream)
currently only have these four firewire specific rules in our tree:
SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x00010*", GROUP="video"
SUBSYSTEM=="firewire", ATTR{units}=="*0x00b09d:0x00010*", GROUP="video"
SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x010001*", GROUP="video"
SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x014001*", GROUP="video"
And all of these are handled by some firewire core driver? The devices
you care about, how would the rules look like for this?
In general, when it comes to auto-loading of drivers we usually expect
the kernel to add modalias metadata to .ko files.
In the hwdb usually mostly only "auxiliary" data is stored, i.e. stuff
that is great to have but is not essential for a device to work
basically.
Rules files should generally be kept short. i.e. if you add 3 more
rules for the devices you care about, that'd be fine — if you add 100,
then that's not so great however, and another approach should be
found.
Anyway, given that I am not a firewire pro, I figure you have to
decide yourself what the best approach is, and then prep a PR and we
can have a look. Without looking at an (maybe just RFC) patch I am not
sure I grok enugh to properly comment on it.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Allocating resource to achieve predictable run times
I am trying to meet a requirement to have predictable execution of jobs. I'm asking here because I need to do this in a systemd environment, specifically a Fedora 26 server but this could get upgraded to a later version as part of any solution. Because this is a systemd server I would like to achieve this in a systemd-friendly way. I am trying to define multiple "containers" for jobs where we can have, say, 5 jobs per cpu and expect a job's time to complete to be the same whether one or many are run. The system may be able to allocate 32+ cpus to such containers (e.g. 5*32 = 160 container capacity). When I say "container" I mean "an environment with reserved resources". I have been looking at using cgroups both directly and via systemd. In a simplistic example, a process that takes n seconds to run without restriction should take 5n seconds to run on a 20% cpu share regardless of the load on the remainder of the system. That a job takes longer to run isn't important; that it always takes the same time is: the job's execution time must be predictable. I have a "dispatcher" that launches jobs. It is a systemd service that has "Delegate=True", "CPUAffinity" set to the processors the job may run on and "CPUQuota" or directly setting "cpu.cfs_quota_us" to limit them to 20% of a cpu. Observations with a simple single-threaded test on one cpu: * a single job takes 15 seconds when run on an otherwise idle system with no other restrictions. * a single job takes 35 seconds when run on a system otherwise running at 100% cpu. * 5 jobs run on one cpu (each job 20% of the cpu) with the rest of the system idle takes (roughly) 75 seconds - five times the duration of one unresticted job on the same idle system. * 5 jobs run on one cpu (each job 20% of the cpu) with the rest of the system busy takes (roughly) 175 seconds - five times the duration of one unresticted job on the same busy system. * runing one job on 20% of one CPU with the rest of the system idle takes much longer (more than 270 seconds) than the duration when running five jobs (this really does not make sense). I have also tried "cpuset.cpus" - the dispatcher creates the cgroups that systemd does not. I've tried using "taskset", "numactl", "isolcpus", systemd settings and cgroup settings but I cannot get predictable results: that 1 job or n jobs take the same amount of time. Having read all the documentation that I can find, I'm not sure what else to try... Are there other provisions (in systemd, cgroups, or other) that can I use to make a job always take (more-or-less) the same amount of time ? Thanks and much appreciated. (p.s. I initially wrote a much longer message but it was a bit too TL;DR so this is the short(er) version. I can provide more detail as needed). pEpkey.asc Description: application/pgp-keys ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 5.2rc2, circular lock warning systemd-journal and btrfs_page_mkwrite
On Di, 04.06.19 12:24, Chris Murphy (li...@colorremedies.com) wrote: > This is on Fedora Rawhide > systemd-242-3.git7a6d834.fc31.x86_64 > kernel 5.2.0-0.rc2.git1.2.fc31.x86_64 Please report to the kernel btrfs maintainers, this is not a userspace problem. Thanks, Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Static IP address on wandering Wi-Fi client
On Do, 13.06.19 10:44, Bruce A. Johnson (bjohn...@blueridgenetworks.com) wrote: > Is there any way to tell systemd-networkd to use one .network file or > another depending on which SSID the Wi-Fi interface is connected to? This does not currently exist, but it was always the intention to add this. So far nobody did the work though. Most likely this would require some minimal wifi netlink hookup so that we can properly watch the configured SSID for the interfaces we watch. Would love to review such a patch. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Start service after video drivers have been loaded
Il giorno lun 17 giu 2019 alle ore 11:07 Lennart Poettering ha scritto: > > On So, 09.06.19 19:45, Germano Massullo (germano.massu...@gmail.com) wrote: > > > Il giorno mar 21 mag 2019 alle ore 16:59 Mantas Mikulėnas > > ha scritto: > Actually, maybe having udev > > > trigger BOINC startup would be a good option? After all that's how > > > BlueZ already works -- it doesn't go in multi-user.target, it has > > > WantedBy=bluetooth.target and there's an udev rule that makes every > > > Bluetooth device pull in bluetooth.target as a dependency. And > > > that's already an official systemd thing, too. > > > > No because BOINC client can even run on systems without graphic card. > > I will try an approach of restarting BOINC client as soon a new > > dev-dri-card0.device appears > > The clean way to handle this is to make your software handle hardware > dynamically internally: make use of the graphics devices it can make > use of the moment they pop up, and not earlier, and do so with any > device showing up, regardless if there are zero initially, one > eventually, or even more... > > systemd is not really designed to be used as work-around for software > that deals with hardware but doesn't really understand that hw is > dynamic these days. > > Hence my recommendation would be to work with the upstream developers > of your project to natively hook up things with libudev or a similar > library to watch for devices popping up and going away. Good, thank you very much for clarifing this. Have a nice day! > > Lennart > > -- > Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Start service after video drivers have been loaded
On So, 09.06.19 19:45, Germano Massullo (germano.massu...@gmail.com) wrote: > Il giorno mar 21 mag 2019 alle ore 16:59 Mantas Mikulėnas > ha scritto: > Actually, maybe having udev > > trigger BOINC startup would be a good option? After all that's how > > BlueZ already works -- it doesn't go in multi-user.target, it has > > WantedBy=bluetooth.target and there's an udev rule that makes every > > Bluetooth device pull in bluetooth.target as a dependency. And > > that's already an official systemd thing, too. > > No because BOINC client can even run on systems without graphic card. > I will try an approach of restarting BOINC client as soon a new > dev-dri-card0.device appears The clean way to handle this is to make your software handle hardware dynamically internally: make use of the graphics devices it can make use of the moment they pop up, and not earlier, and do so with any device showing up, regardless if there are zero initially, one eventually, or even more... systemd is not really designed to be used as work-around for software that deals with hardware but doesn't really understand that hw is dynamic these days. Hence my recommendation would be to work with the upstream developers of your project to natively hook up things with libudev or a similar library to watch for devices popping up and going away. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
