[systemd-devel] Confusing hwdb matching behaviour
The hwdb behaviour is a bit hard to predict when multiple matches with globs apply to a device so I'm wondering whether this is just an implementation result or intended behaviour. Example 1: $> cat 99-test.hwdb test:* match=generic test:specific* match=specific $> systemd-hwdb query "test:specific_match" match=specific This is what I would expect from the hwdb entries. But if we have a rule where glob matches before specific, the generic one overwrites the specific one: Example 2: $> cat 99-test.hwdb test:* match=generic test:*specific* match=specific match2=yep $> systemd-hwdb query "test:specific_match" match=generic match2=yep Definitely not what I expected (note: the order of the entries doesn't matter). This is actually a problem for libinput because it means we can't overwrite generic matches with specific matches. But it gets even weirder once we start stacking more: Example 3: $> cat 99-test.hwdb test:* match=generic test:*specific* match=specific match2=yep test:*specific_match match=specific match2=nope match3=yep $> sudo systemd-hwdb query "test:specific_match" match=generic match2=nope match3=yep It picks the most generic one last but the more specific one over the less specific one. This is confusing and hard to predict. But it gets worse: Example 4: $> cat 99-test.hwdb test:* match=generic test:*specific* match=specific match2=yep test:*spe*match match=specific match2=nope match3=yep test:*specific*match match=specific match2=oh match3=what match4=confused $> sudo systemd-hwdb query "test:specific_match" match=generic match2=yep match3=what match4=confused And now I'm lost :) As a homework, try predicting what this one produces: Exercise: test:* MATCH=generic # changing this to test:specific gives different results test:*specific* MATCH=specific MATCH2=yep test:*spe*match MATCH=specific MATCH2=nope MATCH3=yep test:*specific_* MATCH=specific MATCH2=oh MATCH3=crap MATCH4=what? test:*specific*match MATCH=specific MATCH2=doh MATCH3=what MATCH4=confused MATCH5=boo Solution: "generic, oh, crap, what?, boo" with the glob, without the glob it's "specific, yep, crap, what?, boo" So the question is: is this the intended behaviour (if so, we should document it and make it official) or is this a side-effect. If that, can we change it or is it set in stone? I think no-one but me is currently eagerly stacking hwdb snippets, so maybe there's room to move. As for expected behaviour, I'd intuitively expect a more sequential matching, with an entry in 99-test.hwd overwriting whatever entry was in 10-test.hwdb. Cheers, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A question of sequential control of systemd service.
On Tue, Aug 30, 2016 at 12:41 PM, Mantas Mikulėnas wrote: > On Tue, Aug 30, 2016 at 6:31 PM, lin webber wrote: > >> >> >> hello: >> I have a question about systemd unit. I'm using ubuntu 16.04 whih >> lightdm display manager . I have a service that I want to start it >> completely before the lightdm service . it means that my service and >> lightdm is not parallel started . how can i write my unit file ,and what >> to add in my service code ? >> > > Use a Type= that lets systemd know when your service has 'started', e.g. > Type=forking, Type=notify, or Type=dbus. > > e.g. for Type=notify make sure to call sd_notify(0, "READY=1") after > startup. > > Then add "Before=lightdm.service" to [Unit]. > I'll bet a lot of people would like to see a long series of simple "'systemd 101' HOWTO" examples like this one. All conveniently listed in some easy-to-browse places online. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A question of sequential control of systemd service.
On Tue, Aug 30, 2016 at 6:31 PM, lin webber wrote: > > > hello: > I have a question about systemd unit. I'm using ubuntu 16.04 whih > lightdm display manager . I have a service that I want to start it > completely before the lightdm service . it means that my service and > lightdm is not parallel started . how can i write my unit file ,and what > to add in my service code ? > Use a Type= that lets systemd know when your service has 'started', e.g. Type=forking, Type=notify, or Type=dbus. e.g. for Type=notify make sure to call sd_notify(0, "READY=1") after startup. Then add "Before=lightdm.service" to [Unit]. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] A question of sequential control of systemd service.
hello: I have a question about systemd unit. I'm using ubuntu 16.04 whih lightdm display manager . I have a service that I want to start it completely before the lightdm service . it means that my service and lightdm is not parallel started . how can i write my unit file ,and what to add in my service code ? I like the logic of how systemd manage the system.but I'm not clearly about something in systemd. Thank you very much for your reply. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] alternate cryptsetup
On Mon, 29.08.16 18:18, Xen (l...@xenhideout.nl) wrote: > Lennart Poettering schreef op 29-08-2016 11:46: > >On Sat, 27.08.16 23:20, Xen (l...@xenhideout.nl) wrote: > > > >>How can I notify systemd-cryptsetup.service that cryptsetup has been > >>done in > >>a different way, and succeeded? > > > >Why would you do this? Note that systemd-cryptsetup.service is really > >just a helper for you, that reads /etc/crypttab for you and sets it > >up. If you don't like it you can use any other tool instead, that > >reads its config from anywhere else. All that matters for systemd is > >that the (unencrypted) block device eventually shows up in udev and > >carries the "systemd" tag, and does not have the SYSTEMD_READY=0 > >property set. How you get there, whether with the > >systemd-cryptsetup.service implementation or anything else is really > >of no relevance. It's not of any relevance how the service is called > >or what it actually does. > > > >Or in other words: if you want to put together your own code for > >setting up crypto block devices, go ahead, but there's really need to > >call it "systemd-cryptsetup.service", or interface with that > >implementation at all. > > > >>Or, what exit status should systemd-cryptsetup have to signal success? > > > >On UNIX, success is usually indicated by a process exit code of zero. > > > >Lennart > > Alright, so if I add a udev rule it should show up. Regular > systemd-cryptsetup keeps complaining that devices (from crypttab) haven't > been found and it enters failed status for those devices. Thanks for > sharing. I have found it impossible to turn systemd-cryptsetup off. You may mask the "cryptsetup-generator" binary. See systemd.generator(7). Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
