Re: [systemd-devel] How to stop service by timer
On Mon, Sep 12, 2016 at 09:13:26PM +0300, Федор Короткий wrote: > Hi, > > We are trying to setup a service that runs every day from 10:00 to 18:45. > > Starting is not a problem, we just used timer. But our solution for > stopping the service seems ugly. We have second service with > Type=oneshot which runs "systemctl stop first.service" at 18.45(by > using second timer). > > Is there a better way to achieve this? That's basically the way. Or you can make second service ”empty” (execing /bin/true) with Conflicts=first.service. I would be glad to see .timers extended with TimerAction= option, being ”start” be default, but allowing stop, isolate, restart etc. Maybe open and RFE issue on github? -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to stop service by timer
Hello! How does your service work from 10:00 till 18:45 -- with any interruption during this time-range, or constantly? I'm asking, because I'm not sure if RuntimeMaxSec= directive (https://www.freedesktop.org/software/systemd/man/systemd.service) is acceptable here|. | So, you start your service by timer on 10:00 and due to RuntimeMaxSec=31500 in [Service] section of your service, service should stop on 18:45:00 it should be stopped with exit code 0. But if it happens on 18:45:01 -- will stop with exit with failure state. In that case, if FailureAction= directive (https://www.freedesktop.org/software/systemd/man/systemd.service) for your service is set, it will be executed. 12.09.2016 21:13, Федор Короткий пишет: Hi, We are trying to setup a service that runs every day from 10:00 to 18:45. Starting is not a problem, we just used timer. But our solution for stopping the service seems ugly. We have second service with Type=oneshot which runs "systemctl stop first.service" at 18.45(by using second timer). Is there a better way to achieve this? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to stop service by timer
Hi, We are trying to setup a service that runs every day from 10:00 to 18:45. Starting is not a problem, we just used timer. But our solution for stopping the service seems ugly. We have second service with Type=oneshot which runs "systemctl stop first.service" at 18.45(by using second timer). Is there a better way to achieve this? -- Fedor Korotkiy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] why do we have aliases fro timedated, resolved, networkd, and what are they good for?
Umut Tezduyar Lindskog 2016-09-12 07:19:
Hi Michael,
On Sat, Sep 10, 2016 at 1:00 AM, Michael Biebl wrote:
Hi
I wonder why we have the following aliases/symlinks
dbus-org.freedesktop.hostname1.service -> systemd-hostnamed.service
dbus-org.freedesktop.import1.service -> systemd-importd.service
dbus-org.freedesktop.locale1.service -> systemd-localed.service
dbus-org.freedesktop.login1.service -> systemd-logind.service
dbus-org.freedesktop.machine1.service -> systemd-machined.service
dbus-org.freedesktop.network1.service -> systemd-networkd.service
dbus-org.freedesktop.resolve1.service -> systemd-resolved.service
dbus-org.freedesktop.timedate1.service -> systemd-timedated.service
Those dbus-org.* aliases are used in the corresponding D-Bus system
service files (SystemdService=dbus-org...)
The symlinks/aliases are created statically in $libdir/systemd/system,
so they can't be removed via systemctl disable.
So, I'm asking myself what good those aliases are for?
They actually have a downside:
We just had a Debian bug report, where a user was masking
systemd-resolved.service, but he was puzzled that he could still
trigger the start of the service via systemd-resolve.
This happened via D-Bus activation and the aliased name (which he had
not masked).
AFAIK, that 2 step service file name is for providing a way to prevent
dbus activation.
As in, it was intentionally done this way to allow masking a traditional
service separately from a dbus activate one?
That sorta makes sense that you might want to provide that
flexibility, but it's somewhat counterintuitive to me in this case.
Since the "service" for both is provided by "systemd-resolved.service" I
would expect that masking the base name would also prevent activation
through any aliases.
Maybe my confusion here is in how symlinks are handled generally.
I was under the impression that in most cases it was the names of the
symlink (source in some contexts, target in others), not the contents of
it's target that really made a difference.
For instance, I believe I can declare a service as desired for boot,
even if I don't know where it's actual .service file is (eg: it's
generated by legacy sysv init script or some such) by simply adding a
symlink of /etc/systemd/system/multi-user.target.wants.d/foo.service ->
/bin/true.
The fact that /bin/true isn't itself a unit file doesn't really matter -
it's more so the presence of a name that matters. Now, generally
symlinking to the actual unit is convenient for humans looking at the
files, though that can still be confusing due to overrides and the like
and something like "systemctl cat" should probably be used to avoid
that.
In other contexts, like this one, I was also under the impression that
the target of the symlink (eg: systemd-resolved.service) was just a
placeholder that stood for the name of the desired service to provide an
alias for and that the contents of the file weren't read at that time,
but rather they were evaluated to the contents of that service or in
this case appended as an additional name (eg:
dbus-org.freedesktop.resolve1.service) to that service (eg:
systemd-resolved.service) once that target service was read in. Then in
the case that it was masked, I'd have expected that placeholder-fill-in
operation to simply not take place.
Does my description make sense?
Granted, I haven't actually read the code for that to confirm that
impression, but that was my recollection from reading through gobs of
man pages and the systemd blog posts a few months ago.
Masking resolved alias file should prevent dbus
activation. "systemctl mask dbus-org.freedesktop.resolve1.service".
UMUT
I think the trouble with that is that it requires enumerating all of the
symlinks and determining what else might link to another service that's
masked (via a symlink elsewhere) in order to find all of the other
possible aliases since once you've masked the underlying service, it can
no longer tell you what it's aliases are via the "systemctl show
foo.service | grep ^Names=" command for instance:
# systemctl show systemd-resolved.service | grep ^Names=
Names=systemd-resolved.service
# systemctl cat systemd-resolved.service
# /dev/null
So, then one has to do something like this to find the other services
that might also be aliases:
# for i in $(systemctl list-unit-files --no-legend | awk '{ print $1 }'); do systemctl show $i
2>/dev/null | grep -q ^Names=.*systemd-resolved && echo "unit-file: '$i' has alias
of 'systemd-resolved'"; done
That's just not generally something one would probably consider doing
when attempting to mask a service.
Cheers,
Brian
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Confusing hwdb matching behaviour
Hey! On Wed, Aug 31, 2016 at 6:37 AM, Peter Hutterer wrote: > 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. The matching order always matches children before a node itself, and children in alphabetical order (ASCII). The trie is built based on prefix-matches. So parsing order does not matter. Lets look at your last example (with both possible scenarios): test:* test:specific test:*specific* test:*spe*match test:*specific_* test:*specific*match This will be searched in this order: test:*spe*match test:*specific*match test:*specific* test:*specific_* test:* test:specific (Ascii order: '*' < UPPER-CASE < '_' < LOWER-CASE) (Later matches override properties of earlier matches) I'm not saying this is a useful order, I'm just describing what the code currently does. > 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. If things are not stored in ASCII order, you break bsearch() and lookup performance would drop. A much easier solution would be to use multiple virtual tries: Prefix your generic matches with "test-generic:*foobar*" and your specific ones with "test-specific:*foobar*" and then always lookup both. This obviously only works if the number of levels is static. As a hack, I think you can use "**", "***", ... to change the ordering to your needs. We could also say each hwdb-source gets its own virtual trie and they're searched in alphabetical order. This would break ABI, but would make it a lot more powerful. Not sure. Maybe Kay has some comments? David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] can't use overlay in ubuntu 16.04 UEFI mode
hello: I install the overlay package in ubuntu16.04 and mount overlay file system in a black partition . and i reboot the system,then system go in emergency mode and when i use" journal ctl -xb" command to see what happened ,it tells me "/boot is faild to mount".how can i fix this problem? thanks for your reply. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
