Re: [systemd-devel] syscvall-filters killing CGI after update to Fedora 33
On Mon, Apr 19, 2021 at 10:24 AM Reindl Harald wrote: > > after a long time using this SystemCallFilter perl-cgi with Fedora 33 > get killed - anyone an idea what changed that's obviously covered by the > second line > > SystemCallFilter=@system-service @network-io @privileged > SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount > @obsolete @raw-io @reboot @resources @swap > > either the blacklist of the new systemd version convers more than before > or something changed in the perl stack > > - > > Process 7723 (mailgraph.cgi) of user 48 dumped core.#012#012Stack trace > of thread 7723:#012#0 0x7f14be8e955d syscall (libc.so.6 + > 0xfc55d)#012#1 0x7f14be2959d2 g_thread_pool_new (libglib-2.0.so.0 + > 0x839d2)#012#2 0x7f14bde5ae5c g_task_get_type_once (libgio-2.0.so.0 > + 0xabe5c)#012#3 0x7f14bde5af85 g_task_get_type (libgio-2.0.so.0 + > 0xabf85)#012#4 0x7f14bde5b09d g_task_new (libgio-2.0.so.0 + > 0xac09d)#012#5 0x7f14bdfd2c4e pango_fc_font_map_init > (libpangoft2-1.0.so.0 + 0xac4e)#012#6 0x7f14be37db97 I think the following change in pango is now making it spawn a thread where it didn't before. https://gitlab.gnome.org/GNOME/pango/-/commit/e4e7a76a173620394a4bff9738d9b156c40e8c45 -- Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: one more time: SCSI device identification
Martin,
> Hm, it sounds intriguing, but it has issues in its own right. For
> years to come, user space will have to probe whether these attribute
> exist, and fall back to the current ones ("wwid", "vpd_pg83")
> otherwise. So user space can't be simplified any time soon. Speaking
> for an important user space consumer of WWIDs (multipathd), I doubt
> that this would improve matters for us. We'd be happy if the kernel
> could just pick the "best" designator for us. But I understand that
> the kernel can't guarantee a good choice (user space can't either).
But user space can be adapted at runtime to pick one designator over the
other (ha!).
We could do that in the kernel too, of course, but I'm afraid what the
resulting BLIST changes would end up looking like over time.
I am also very concerned about changing what the kernel currently
exports in a given variable like "wwid". A seemingly innocuous change to
the reported value could lead to a system no longer booting after
updating the kernel.
(Ignoring for a moment that some arrays will helpfully add a new ID
designator after a firmware upgrade and thus change what the kernel
reports. *sigh*)
> What is your idea how these new sysfs attributes should be named? Just
> enumerate, or name them by type somehow?
Up to you. Whatever you think would be easiest for userland to deal
with. I don't have a good feeling for how common vendor specific ones
are in practice. Things would obviously be easier if SCSI didn't have so
many choices :(
But taking a step back: Other than "it's not what userland currently
does", what specifically is the problem with designator_prio()? We've
picked the priority list once and for all. If we promise never to change
it, what is the issue?
--
Martin K. Petersen Oracle Linux Engineering
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] resolved: wrong address w/ cache off, wo/ querying DNS server
Dear Systemd Developers, I got stuck with investigating an issue and I would be very grateful for some advice. Briefly, systemd-resolved keeps returning a wrong answer to a query, despite the cache is disabled. The debug log doesn't show the origin of the answer. Systemd-resolved doesn't query the configured DNS server when answering this query. If I query the DNS server directly, it returns the correct answer. I described the issue in this thread: https://bbs.archlinux.org/viewtopic.php?pid=196#p196 -- please ignore the starting comment, the last 3 are the most relevant. See some system info below the mail. Best, Denes Systemd version: 247.3 Linux: Linux x 5.10.13-hardened1-1-hardened #1 SMP PREEMPT Thu, 04 Feb 2021 22:19:00 + x86_64 GNU/Linux ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "Correct" way to obtain DHCP lease info?
Am Mittwoch, dem 21.04.2021 um 14:24 -0400 schrieb Bruce A. Johnson: > Is there a correct way to obtain information about the DHCP lease > received by systemd-networkd's DHCP client functionality? It was easy > enough to find SERVER_ADDRESS in /var/run/systemd/netif/leases/4, but > there is a big fat warning stamped at the top of the file: > > > # This is private data. Do not parse. > I'd like to be able to make a widget that can tell me which DHCP server > issued my lease, how much more time I have, etc., mainly because I want > to be able to ping something that is known to be on the network. I'm > dealing with a lazy sysadmin who doesn't want to put a gateway on this > private network, I haven't found a solution using the CLI tools. > > Thanks in advance. Hi Bruce, IMHO "having a lease" is not a good metric to determine if you can access something. I would suggest something along this line: --- /etc/systemd/system/internal-network-accessable.target [Unit] Description=Internal System Accessable --- --- /etc/systemd/system/check-if-internal-system-is-accessable.service [Unit] Description=Check if internal system can be reached [Service] ExecStart=/usr/local/bin/check-if-internal-system-is-accessable.sh Restart=always [Install] WantedBy=multi-user.target --- --- /usr/local/bin/check-if-internal-system-is-accessable.sh #!/usr/bin/bash while :; do if wget -q --spider $INTERNAL_RESOURCE; then systemctl start internal-network-accessable.target else systemctl stop internal-network-accessable.target fi sleep 600 done --- Than you can check just the status of the .target. You may need to tweak the lifeness probe, YMMV. Also in sd-networkd you can configure a .network to never loose its lease, see man:systemd.network → KeepConfiguration= HTH Silvio signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] "Correct" way to obtain DHCP lease info?
Is there a correct way to obtain information about the DHCP lease received by systemd-networkd's DHCP client functionality? It was easy enough to find SERVER_ADDRESS in /var/run/systemd/netif/leases/4, but there is a big fat warning stamped at the top of the file: # This is private data. Do not parse. I'd like to be able to make a widget that can tell me which DHCP server issued my lease, how much more time I have, etc., mainly because I want to be able to ping something that is known to be on the network. I'm dealing with a lazy sysadmin who doesn't want to put a gateway on this private network, I haven't found a solution using the CLI tools. Thanks in advance. -- Bruce A. Johnson | Firmware Engineer Blue Ridge Networks, Inc. 14120 Parke Long Court Suite 103 | Chantilly, VA 20151 Main: 1.800.722.1168 | Direct: 703-633-7332 http://www.blueridgenetworks.com OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/ OpenPGP_signature Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Request for Feedback on Design Issue with Systemd and "Consistent Network Device Naming"
On Mi, 21.04.21 10:13, Simon Foley (si...@simonfoley.net) wrote: > The issue is around the depreciation of the support for the HWADDR= argument > in the ifcfg files (RHEL, other distros are available). systemd upstream is not involved in that. ifcfg is specific to Red Hat distributions and systemd doesn't mandate the concept to be deprecated. It doesn't support them natively, but there's no need to. The .link concept systemd provides is more powerful and works across distributions. You can use that to name your interfaces by MAC address, it's very well supported. > How HPC architects try to help sysadmins and application teams in the > process is to have post build modifications. > Here we can use the HWADDR= variable in the ifcfg-[device name] files to > move a *specific* device name to these targeted NIC cards and ports. systemd doesn't stop you to. It provides a more generic way to do this via .link files, but from systemd's PoV you don#t have to migrate, if you don't want. You could easily write a conversion script btw, that takes your ifcfg files and converts them to .link files in /run, if you like. > It would appear in RHEL8 that due to systemd the HWADDR= is no longer > supported and we have lost this fundamentally important feature. If RHEL deprecated this, that's a decision by RHEL, and the upstream systemd project does not mandate anything in this area. It provides a generic mechanism to do the same, but you can use whatever you want. Anyway, the upstream systemd project is the wrong forum to discuss any of this. You are apparently upset by a RHEL decision. While I sympathize with the decision, it's not a decision the systemd project took, but RHEL did, and technically nothing in systemd mandates this. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Request for Feedback on Design Issue with Systemd and "Consistent Network Device Naming"
On Wed, Apr 21, 2021 at 12:20 PM Simon Foley wrote: ... > Here we can use the HWADDR= variable in the ifcfg-[device name] files to > move a *specific* device name to these targeted NIC cards and ports. Read man systemd.link. [Match] MACAddress= (or PermanentMACAddress=) [Link] Name=whatever-name-you-need ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
