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

[Olaf Hering]

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.

But, unfortunately both services may touch the same files while they run.

Does systemd have a way to serialize execution of such units, so that starting 
of A.service is delayed until B.service is done, and via versa?

Before=/After= may not apply, at least the docs say nothing about timer driven 
units.


I might be able to add some locking to A.service and B.service with some 
creative ExecStartPre/Post= in A.service.d/lock.conf ...


Olaf


pgpKSCG6u9LCV.pgp
Description: Digitale Signatur von OpenPGP

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

[Olaf Hering]

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, so it does not get 
lost in the noise.

Olaf


pgpspYD4dz4BS.pgp
Description: Digitale Signatur von OpenPGP
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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 
configuration. As a result, such configuration is per host and not generic 
anymore. Is there a knob I overlooked so that the bridge uses the MAC from the 
physical interface? If not, are there plans to fix that?

Olaf

==> /etc/sysconfig/network/ifcfg-br0 <==
BOOTPROTO='dhcp'
BRIDGE='yes'
BRIDGE_PORTS='eth0'
BRIDGE_STP='off'
STARTMODE='auto'
==> /etc/sysconfig/network/ifcfg-eth0 <==
BOOTPROTO='none'
STARTMODE='auto'

==> /etc/NetworkManager/system-connections/eth <==
[connection]
id=eth
uuid=----
type=ethernet
interface-name=eth0
master=br0
permissions=
slave-type=bridge
[ethernet]
mac-address-blacklist=
==> /etc/NetworkManager/system-connections/br <==
[connection]
autoconnect-slaves=1
id=br
interface-name=br0
permissions=
type=bridge
uuid=----
[bridge]
stp=false
[ipv4]
dhcp-timeout=2147483647
dns-search=
method=auto
[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ip6-privacy=0
method=auto


pgpaHsfjiLPgq.pgp
Description: Digitale Signatur von OpenPGP
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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 have? These systems have plenty of cpus, have plenty of
> > memory, likely enough to handle these few fstab entries during bootup.
> > 
> > Is there a way to boot with debug enabled, but not spam the serial
> > console with lots of noise while the issue does not happen?
> 
> "resources" is a bit misleading... It's our catch-all result code if
> some kernel API returned an error we didn't expect. Most likely
> (hopefully?) there's more info about what operation failed in the
> logs. Do you see anything there? If you can reproduce it, can you turn
> on "systemd-analyze set-log-level debug" before it maybe to get more
> detailed output?

There was nothing obvious in the logs, but debug was not enabled AFAIK.

But it turned out the mount point did not exist in this case. Once
created, all "automount" entries in fstab worked fine.

I have seen this generic error on a few more systems. I will enable
debug once I get the chance to work on these systems.


Olaf


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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 575e658 is broken. My fault, I did not doublecheck the 
updated submission...

So, how is one supposed to handle untagged hexvalues? Invent a new helper, or 
prepend "0x" if missing, or just use sscanf?

Olaf


pgpxbJPIkHTEH.pgp
Description: Digitale Signatur von OpenPGP
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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 avoid it, nor what (low) limits could be the cause.

Current event, which triggered this message:

...
root@anonymi:~ # systemctl status LEAP42.2.mount
● LEAP42.2.mount - /LEAP42.2
   Loaded: loaded (/etc/fstab; generated; vendor preset: disabled)
   Active: inactive (dead)
Where: /LEAP42.2
 What: /dev/disk/by-label/LEAP42.2
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)
root@anonymi:~ # systemctl status LEAP42.2.automount
● LEAP42.2.automount
   Loaded: loaded (/etc/fstab; generated; vendor preset: disabled)
   Active: failed (Result: resources)
Where: /LEAP42.2
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)
root@anonymi:~ # lsblk -f
NAMEFSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1  btrfs  BOOT  d398bdb5-1622-43e4-887c-c7584567078d /chainloader
├─sda2  swap   SWAP  815eef7d-9586-4c5a-87a1-f1f81ed6c67a [SWAP]
├─sda3
├─sda5  ext3   SLES11SP2 d393f3fc-5959-4688-af3d-3fd8d7c869b4
├─sda6  ext3   SLES11SP3 f9b6a27b-2fb3-449f-b4d8-a1a7a866da3c
├─sda7  ext3   SLES11SP4 965a3749-06db-4895-8eee-660cedeca9ab
├─sda8  ext4   SLES15SP0 4bf640b6-5d9f-4a5c-98bf-ef63b0543fab /
├─sda9  ext3   SLES12GA  11071484-04e2-46a0-b4ce-d478c702ed28
├─sda10 ext3   SLES12SP1 154174be-edf9-44cc-8bf5-a176c8e66495
├─sda11 ext3   SLES12SP2 26a65e63-bcd4-4482-9750-acd4bc092afc
├─sda12 ext3   SLES12SP3 78d6ab38-79b9-458c-97d0-3bfbbf12ff94
├─sda13 ext3   LEAP42.1  015ce2d3-21ff-4bd6-8057-81acda9515d3
├─sda14 ext3   LEAP42.2  d2530d52-04e2-4574-91ea-65e45f0d7bf0
├─sda15 ext3   LEAP42.3  d436294f-8e8e-4d28-ad2d-5891637732cb
├─sda16 ext3   TW5062f2e1-2c31-4291-8092-07fe74295061
└─sda17 ext3   VM_IMAGES 49f90684-3df3-4157-bb38-b92e3935e1d6
root@anonymi:~ # grep LEA /etc/fstab
LABEL=LEAP42.1 /LEAP42.1 ext3 
ro,noatime,,x-systemd.automount,x-systemd.idle-timeout=11 1 2
LABEL=LEAP42.2 /LEAP42.2 ext3 
ro,noatime,,x-systemd.automount,x-systemd.idle-timeout=11 1 2
LABEL=LEAP42.3 /LEAP42.3 ext3 
ro,noatime,,x-systemd.automount,x-systemd.idle-timeout=11 1 2
...

'journalctl -b' does not indicate any related failure.

Does anyone happen to know what limits a mount point or an automount
point might have? These systems have plenty of cpus, have plenty of
memory, likely enough to handle these few fstab entries during bootup.

Is there a way to boot with debug enabled, but not spam the serial
console with lots of noise while the issue does not happen?

Olaf


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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 Tumbleweed:

dev-hugepages.mount:ConditionVirtualization=!private-users
haveged.service:ConditionVirtualization=!container
hv_fcopy_daemon.service:ConditionVirtualization=microsoft
hv_kvp_daemon.service:ConditionVirtualization=microsoft
hv_vss_daemon.service:ConditionVirtualization=microsoft
irqd.service:ConditionVirtualization=!container
ksm.service:ConditionVirtualization=no
lxcfs.service:ConditionVirtualization=!container
mcelog.service:ConditionVirtualization=false
ntp-wait.service:ConditionVirtualization=!container
ntpd.service:ConditionVirtualization=!container
rng-tools.service:ConditionVirtualization=!container
smartd.service:ConditionVirtualization=false
sys-fs-fuse-connections.mount:ConditionVirtualization=!private-users
systemd-random-seed.service:ConditionVirtualization=!container
systemd-timesyncd.service:ConditionVirtualization=!container
vgauthd.service:ConditionVirtualization=vmware
vmblock-fuse.service:ConditionVirtualization=vmware
vmtoolsd.service:ConditionVirtualization=vmware
xendriverdomain.service:ConditionVirtualization=xen

I think the relevant services are ksm,mcelog and smartd. Each one likely
wants the "hardware domain" rather than the "toolstack domain". IMO what
systemd today sees as "dom0" should be set based on "XENFEAT_dom0".

Olaf


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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 responsibility of the toolstack control domain.

No, I did not intent to make use of ConditionVirtualization= in the
xen*.service files in tools/hotplug/Linux/. That variable can not be used
for this purpose, and the patch would not change that.

In case you refer to the "proc-xen.mount" change from a few days/weeks ago,
this was all about avoiding the error when xenfs becomes an "API filesystem".
With this suggested change the existing "proc-xen.mount units would not fail
anymore because /proc/xen is added to the ignore list.

Olaf


pgp7kFBMS_k21.pgp
Description: Digitale Signatur von OpenPGP
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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. Right now the term "dom0" is 
a mix of "has access to host (IO) hardware" and "runs the toolstack".

ConditionVirtualization= today lacks such details as well.
"xen" means domU, and "none" is dom0, simply to handle "dom0" like "native"
so that all services that want access to "host hardware" can start.

One could argue that passing a PCI device to a domU may also require
.service files to manage that PCI device in some way. The specifc case
which triggered all the suggested changes was smartd, which is not
supposed to run in "VMs". If a SATA card is provided to a domU it may
be a good idea to monitor the attached disks as well.

So in some way Jan is correct with his suggestion to use XENFEAT_dom0
instead of "control_d". I will do some research about when it became available
and update the patch description.

Olaf


pgpexM37QzucI.pgp
Description: Digitale Signatur von OpenPGP
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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 entities).

Per discussion in https://github.com/systemd/systemd/pull/6662, the
feature bits should not be used for dom0 detection.

Olaf


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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 depending on "native" have to run in dom0.

Actually, it is spelled with 'z': ConditionVirtualization=
https://www.freedesktop.org/software/systemd/man/systemd.unit.html
https://www.freedesktop.org/software/systemd/man/systemd-detect-virt.html

Olaf


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

The detection of ConditionVirtualisation= relies on the presence of
/proc/xen/capabilities. If the file exists and contains the string
"control_d", the running system is a dom0 and VIRTUALIZATION_NONE should
be set. In case /proc/xen exists, or some sysfs files indicate "xen",
VIRTUALIZATION_XEN should be set to indicate the system is a domU.

With an (old) xenlinux based kernel, /proc/xen/capabilities is always
available and the detection described above works always. But with a
pvops based kernel, xenfs must be mounted on /proc/xen to get
"capabilities". Up to now this was done by a proc-xen.mount unit, which
is part of xen.git. Since the mounting happens "late", other units may
be scheduled before "proc-xen.mount". If these other units make use of
"ConditionVirtualisation=", the virtualization detection returns
incorect results. detect_vm() will set VIRTUALIZATION_XEN because "xen"
is found in sysfs. This value will be cached. Once xenfs is mounted,
the next process that runs detect_vm() will get VIRTUALIZATION_NONE.

This misdetection can be fixed by turning xenfs into an "API
filesystem", which is done by adding it to mount_table[]. That way xenfs
will be mounted early, and detect_vm() returns correct results.

But since the "proc-xen.mount" unit still exists, the startup of that
unit fails because it is rejected due to a conflict with an "API
filesystem" mount. This is done in mount_verify(). The unit gets into
state FAILED. Other Xen toolstack related .service files rely on the
existance of the proc-xen.mount unit. If proc-xen.mount fails, the
toolstack fails too.

To stay compatible with existing and upcoming releases of Xen, add
"/proc/xen" to the 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 anyway.

Signed-off-by: Olaf Hering <o...@aepfle.de>
---

I'm not 100% sure if the logic change in mount_verify() has undesired effects.

 src/core/mount-setup.c | 3 +++
 src/core/mount.c   | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index d5c0fcddc..df23e71b5 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -114,6 +114,8 @@ static const MountPoint mount_table[] = {
   cg_is_legacy_wanted, MNT_FATAL|MNT_IN_CONTAINER },
 { "pstore",  "/sys/fs/pstore","pstore", NULL,  
MS_NOSUID|MS_NOEXEC|MS_NODEV,
   NULL,  MNT_NONE   },
+{ "xenfs",   "/proc/xen", "xenfs",  NULL,  
MS_NOSUID|MS_NOEXEC,
+  NULL,  MNT_NONE   },
 #if ENABLE_EFI
 { "efivarfs","/sys/firmware/efi/efivars", "efivarfs",   NULL,  
MS_NOSUID|MS_NOEXEC|MS_NODEV,
   is_efi_boot,   MNT_NONE   },
@@ -126,6 +128,7 @@ static const MountPoint mount_table[] = {
 static const char ignore_paths[] =
 /* SELinux file systems */
 "/sys/fs/selinux\0"
+"/proc/xen\0"
 /* Container bind mounts */
 "/proc/sys\0"
 "/dev/console\0"
diff --git a/src/core/mount.c b/src/core/mount.c
index b25bb9cb4..5afe7fcd7 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -526,7 +526,7 @@ static int mount_verify(Mount *m) {
 return -EINVAL;
 }
 
-if (mount_point_is_api(m->where) || mount_point_ignore(m->where)) {
+if (mount_point_is_api(m->where) && !mount_point_ignore(m->where)) {
 log_unit_error(UNIT(m), "Cannot create mount unit for API file 
system %s. Refusing.", m->where);
 return -EINVAL;
 }
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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 mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] stacked automounts

[Olaf Hering]

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 up automount d-l-1.automount.
Unset automount d-l-1.automount.

Olaf


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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 work for me, but using /dev/input/event5 works.
#   udevadm hwdb --update
#   udevadm trigger /dev/input/eventXX
# where /dev/input/eventXX is the keyboard in question. If in
# doubt, simply use /dev/input/event* to reload all input rules.


And finally, this new entry to let th 'Earth' icon start the web browser
instead of sending XF86HomePage, which is ignored.

# HP ProBook 6555b, icon earth, sends home, should send www
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnHewlett-Packard:pnHPProBook6555b:*
 KEYBOARD_KEY_b2=www


This is the output from evtest:
...
Testing ... (interrupt to exit)
Event: time 1444997900.742080, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1c
Event: time 1444997900.742080, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0
Event: time 1444997900.742080, -- SYN_REPORT 
Event: time 1444997901.811896, type 4 (EV_MSC), code 4 (MSC_SCAN), value b2
Event: time 1444997901.811896, type 1 (EV_KEY), code 172 (KEY_HOMEPAGE), value 1
Event: time 1444997901.811896, -- SYN_REPORT 
Event: time 1444997901.818859, type 4 (EV_MSC), code 4 (MSC_SCAN), value b2
Event: time 1444997901.818859, type 1 (EV_KEY), code 172 (KEY_HOMEPAGE), value 0
Event: time 1444997901.818859, -- SYN_REPORT 
Event: time 1444997902.143888, type 4 (EV_MSC), code 4 (MSC_SCAN), value b2
Event: time 1444997902.143888, type 1 (EV_KEY), code 172 (KEY_HOMEPAGE), value 1
Event: time 1444997902.143888, -- SYN_REPORT 
Event: time 1444997902.150824, type 4 (EV_MSC), code 4 (MSC_SCAN), value b2
Event: time 1444997902.150824, type 1 (EV_KEY), code 172 (KEY_HOMEPAGE), value 0
Event: time 1444997902.150824, -- SYN_REPORT 
Event: time 1444997903.703173, type 4 (EV_MSC), code 4 (MSC_SCAN), value 1d
Event: time 1444997903.703173, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 1
Event: time 1444997903.703173, -- SYN_REPORT 
Event: time 1444997905.50, type 4 (EV_MSC), code 4 (MSC_SCAN), value 2e
Event: time 1444997905.50, type 1 (EV_KEY), code 46 (KEY_C), value 1
Event: time 1444997905.50, -- SYN_REPORT 
...

Olaf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHDX9494NR:pvr*
>  KEYBOARD_KEY_b2=www# Fn+F3
>  KEYBOARD_KEY_d8=!f23   # touchpad off
>  KEYBOARD_KEY_d9=!f22   # touchpad on
> 
> Do you have touchpad on/off keys? Do they already work?

No, there are no such keys.

> As for the new entry being ignored, is that still the case after "udevadm
> control --reload", or just rebooting? (I've heard that this sometimes is
> necessary). If so, can you please pastebin "udevadm info --export-db"
> somewhere, so that we can verify the DMI names and whether the hwdb
> entry actually matches?

http://pastebin.com/raw.php?i=Y5NJWJGF

Ignored means the desktop does nothing with XF86HomePage.

> Finally, which systemd version are you running? (The 60-keyboard.hwdb
> syntax changed in 220).

openSUSE Tumbleweed, currently at 224.

Olaf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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 that part
and see what the hardware actually provides...

Olaf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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@probook:~ # udevadm test-builtin keyboard
/devices/platform/i8042/serio0/input/input4/event5
calling: test-builtin
=== trie on-disk ===
tool version:  224
file size: 7049404 bytes
header size 80 bytes
strings1762740 bytes
nodes  5286584 bytes
Load module index
timestamp of '/usr/lib/systemd/network' changed
Parsed configuration file /usr/lib/systemd/network/99-default.link
Created link configuration context.
Unload module index
Unloaded link configuration context.
root@probook:~ #

My entry from the initial mail works, no worries.

Olaf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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?

Wildcard for all of HP?!

>> Why would such a wildcard be correct?
> 
> As inconsistent as scan code assignments are between different
> vendors, the big ones at least sem to have some internal consistency,
> like HP, the "ThinkPad Extra Buttons", or the "Acer WMI hotkeys". We
> just found over time that a large number of different HP models all
> have the same keymap and it seems logical to factor out the common
> keys and then just add a few model specific adjustments.
> 
> The common map does not set b2 BTW, so disabling it won't change
> anything.

I disabled everything, and the result when doing the Fn+something is
like shown below. This means that at least the entries for 81, 89, 92,
97 and ee are already correct via wildcard. The other wildcards may not
hurt.

However b7 and 1d should be handled somehow. Not sure what the correct
entries for this model would be to handle print and interrupt (Its
labeled Untbr in german) keys. Right now both send wrong keys. Not sure
what sysrq is supposed to do anyway, at least GNOME does a screenshot.

Olaf

icon
sleep:Fn+F3  == value df, KEY_SLEEP
display:  Fn+F4  == value ee, unhandled

no label: Fn+ESC == value 81, unhandled
no label: Fn+F6  == value 8a, unhandled
battery:  Fn+F8  == value 89, unhandled
bright-:  Fn+F9  == value 92, unhandled
bright+:  Fn+F10 == value 97, unhandled
no label: Fn+F11 == value b3, unhandled

print:Fn+pos1== value b7, sysrq?
sysrq:Fn+ende== value 54, sysrq
pause:Fn+pgup== value c5, pause
intr: Fn+pgdn== value 1d, left ctrl?

Olaf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] network interface names flipping

[Olaf Hering]

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 to happen on my Probook, and that makes me
wonder if the whole code should just be dropped from udev because it
obviously fails to work. Unless of course the goal is "UNpredictable"

So, with my own kernel "eth0" becomes "enp2s0". And as I noticed just
now, with kernel.rpm its always named "ens1".

What is udev doing wrong?
See http://pastebin.com/raw.php?i=Y5NJWJGF for some data.


Olaf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Olaf Hering]

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 can I make sure tool B
will always find an operational socket handled by A? There is the
obvious startup time required within A until it can service requests.

What happens if B runs and tries to acces /path while A is still
starting up?

Olaf

A.socket:
[Unit]
DescriptionA socket
[Socket]
ListenStream=/path
SocketMode=0600
Service=A.service
[Install]
WantedBy=sockets.target


A.service:
[Unit]
Description=A service
Requires=A.socke
[Service]
Type=notify
ExecStart=/bin/A
[Install]
WantedBy=multi-user.target


B.service:
[Unit]
Description=B, a tool talking to A
Requires=A.service
[Service]
Type=oneshot
ExecStart=/bin/B
[Install]
WantedBy=multi-user.target
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel