There is A.timer and its A.service, and B.timer and B.service.
Both A and B do not know about each other per default.
Both timers fire in their own cadence.
Both services have their unpredictable time until they finish.
So it may happen that A.service is started while B.service is still active.
Bu
With ifcfg or NetworkManager it is possible to have generic config files for
every system to configure a bridge on the one and only physical network
interface. See the examples below how such configuration looks like.
With systemd-networkd it is apparently required to specify the MAC in the
con
Am Thu, 9 May 2019 11:49:24 +0200
schrieb Olaf Hering :
> With systemd-networkd it is apparently required to specify the MAC in the
> configuration. As a result, such configuration is per host and not generic
> anymore.
This is now https://github.com/systemd/systemd/issues/12558, s
Is there a way to have stacked automounts?
In this example only /d is mounted when /d/l/1/ is accessed:
LABEL=d/d xfs noatime,x-systemd.automount,x-systemd.idle-timeout=22
1 2
/d/i/1.iso /d/l/1 iso9660 ro,loop,x-systemd.automount,x-systemd.idle-timeout=11
0 0
In the logs I see:
Set
On Wed, Nov 29, Jan Beulich wrote:
> With all of the above, was it considered to check /sys/hypervisor
> alongside with or perhaps even in preference to /proc/xen?
Yes.
/proc/xen/capabilities is the one and only place that indicates a dom0.
Olaf
signature.asc
Description: PGP signature
___
list of ignored paths and adjust the check for API
mounts.
Now "proc-xen.mount" is silently accepted, it gets into state "start
condition failed" because "ConditionPathExists=!/proc/xen/capabilities
was not met". But all units depending on "proc-xen.mount" start
On Wed, Nov 29, Jan Beulich wrote:
> But in the description you talk about detect_vm() - by its name that
> doesn't look to care about Dom0, but whether running on top of
> _some_ hypervisor.
dom0 has to be handled as "no virtualization" because it has access to
all hardware, all services dependi
On Wed, Nov 29, Jan Beulich wrote:
> Ah, I see. But then still I don't see why at least on half way
> recent Xen /sys/hypervisor/properties/features wouldn't have
> the information you're after (and even more precise, because
> down the road control domain and hardware domain may be
> separate ent
Am Fri, 1 Dec 2017 10:21:46 +
schrieb Wei Liu :
> In Olaf's case, he cares about knowing whether the domain runs the
> controlling toolstack, he doesn't care about if it is the hardware
> domain or not, so my conclusion was using that flag was wrong.
I think this is not entirely accurate. Rig
Am Fri, 1 Dec 2017 12:29:24 +
schrieb Wei Liu :
> But Olaf needs to know if some of the services like xenconsoled or
> xenstored should be started, and if some of the special file systems
> should be mounted, right? Those aren't tied to hardware in anyway. In my
> view that's the responsibilit
On Fri, Dec 01, Wei Liu wrote:
> What information do you need? For a moment let's skip using the fuzzy
> "Dom0" term and try to be precise. Like "I would like to know if that
> domain has access to all hardware" or something else.
That depends on the .service files. This is the list of openSUSE T
Since I discovered the automount feature I started to add it to fstab,
as shown below, on several systems with various versions of systemd.
Most of the time it works fine. But sometimes units fail to start.
Google does not give much hints about that, nor a pointer what limits
must be raised to avoi
I submitted a correct and tested patch via
https://github.com/systemd/systemd/pull/7581, which was using sscanf("0028f0",
"%x",&val). During discussion I was soft-forced to use systemd helper
functions. These (strtoull based) helpers expect "0x...", which sysfs does not
provide. As a result 575
On Tue, Jan 23, Lennart Poettering wrote:
> On Mo, 15.01.18 15:13, Olaf Hering (o...@aepfle.de) wrote:
>
> > 'journalctl -b' does not indicate any related failure.
> >
> > Does anyone happen to know what limits a mount point or an automount
> > point
My copy of /usr/lib/udev/hwdb.d/60-keyboard.hwdb has (at least) three
issues:
This advice fails, bugreporting is disabled, perhaps just for me?
# If your changes are generally applicable, open a bug report on
# http://bugs.freedesktop.org/enter_bug.cgi?product=systemd
The wildcard does not wor
Am 16.10.2015 um 14:56 schrieb Martin Pitt:
>> # HP ProBook 6555b, icon earth, sends home, should send www
>> evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard:pnHPProBook6555b:*
>> KEYBOARD_KEY_b2=www
>
> This looks similar to this already existing rule for this model:
> # HDX9494nr
> evdev:atkbd
Am 16.10.2015 um 14:56 schrieb Martin Pitt:
> This looks similar to this already existing rule for this model:
I just noticed that there is a catch al, which looks very odd:
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pn*:pvr*
Why would such a wildcard be correct? Guess I will disable tha
Am 16.10.2015 um 15:45 schrieb Martin Pitt:
> udevadm test-builtin keyboard
> /devices/platform/i8042/serio0/input/input4/event5
>
> ? Does that give any error message wrt. assigning the www key? Can you
> please double-check in evtest that you really still get KEY_HOMEPAGE
> after that?
root
Am 16.10.2015 um 15:42 schrieb Martin Pitt:
> Hello Olaf,
>
> Olaf Hering [2015-10-16 15:22 +0200]:
>> I just noticed that there is a catch al, which looks very odd:
>>
>> evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pn*:pvr*
>
> How does it look odd?
Wildc
Since the introducion of the (un)predictable network interface names the
name of the single onboard interface on my Shuttle changes if I boot my
own .config or the kernel.rpm provided by openSUSE. I just threw up
hands and continue to boot with netnames=0 (or whatever).
Now that same thing starts
How can scripts which use "logger -t id --id=val" get "me[val]" into syslog?
This used to work, with a systemd based system it looks like this:
root@probook:~ # journalctl -f &
root@probook:~ # logger -t "me" --no-act --stderr --id=$PPID "foo: blah"
<13>Oct 21 09:58:11 me[2606]: foo: blah
root@pr
I wonder how systemd handles the startup time of a daemon once it did
the execve (or whatever systemd does internally). Every daemon needs
some time until it can service requests.
In the following example a socket is provided, a daemon handles the
socket and another tool will use the socket. How
What is the proper way to run a service as the very first unit when the
system goes down? I want to run it before systemd stops active sessions
with "Stopping Session N of User $user...".
It seems that "After=session-N.scope" does have the desired effect,
but I may have to list every possible valu
Wed, 12 Feb 2025 20:54:08 +0300 Andrei Borzenkov :
> session-.scope
While also this does shift things around, it does not what one would expect.
Not a problem, thanks for your help.
Olaf
pgp93cN0jK6tN.pgp
Description: Digitale Signatur von OpenPGP
Hello,
the two unit files shown at the end are supposed to run the service
once per week around the specified time. But for some reason the
timer triggers at unexpected other times. What needs to be done
to make sure it really only runs at the specified OnCalendar= time?
Both units are part of a
25 matches
Mail list logo
