[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. 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
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
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
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?
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 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
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)
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)
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)
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)
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)
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)
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 --- 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)
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
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] logger --id=val is ignored by systemd
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@probook:~ # logger -t "me" --no-act --stderr --id=$PPID "foo: blah" <13>Oct 21 09:58:13 me[2606]: foo: blah root@probook:~ # logger -t "me" --id=$PPID "foo: blah" root@probook:~ # Oct 21 10:02:33 probook.fritz.box me[2928]: foo: blah logger -t "me" --id=$PPID "foo: blah" root@probook:~ # Oct 21 10:02:34 probook.fritz.box me[2929]: foo: blah I expect "me[2606]" to appear in "journalctl -f" output, but appearently the id is always replaced by the pid of logger. How should a script look like to comply with systemd? Olaf ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[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 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
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? 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
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? 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
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
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
[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 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
[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. 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