[systemd-devel] run only a single service at a time

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.

Re: [systemd-devel] Inherit MAC address for bridge from physical device

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

[systemd-devel] Inherit MAC address for bridge from physical device

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

Re: [systemd-devel] automount fails with generic "resources" error

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 might h

[systemd-devel] How to handle untagged hexvalues in systemd code?

I submitted a correct and tested patch via https://github.com/systemd/systemd/pull/7581, which was using sscanf("0028f0", "%x",). 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

[systemd-devel] automount fails with generic "resources" error

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

Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

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

Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

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

Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

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

Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

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

Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

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

[systemd-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

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" sta

Re: [systemd-devel] [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

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

[systemd-devel] stacked automounts

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

[systemd-devel] add new entry for HP ProBook 6555b to keyboard.hwdb

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

Re: [systemd-devel] add new entry for HP ProBook 6555b to keyboard.hwdb

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 >

Re: [systemd-devel] add new entry for HP ProBook 6555b to keyboard.hwdb

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

Re: [systemd-devel] add new entry for HP ProBook 6555b to keyboard.hwdb

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?

Re: [systemd-devel] add new entry for HP ProBook 6555b to keyboard.hwdb

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

[systemd-devel] network interface names flipping

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

[systemd-devel] when is a service ready to be used after startup?

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.