Re: [systemd-devel] Question regarding configuration of SystemMaxUse and SystemKeepFree
On 02.09.2023 00:29, PureLinux Betriebsführung wrote: Hi, i am running a bunch of partly very different systems with Debian Bookworm. On this machines, i am using systemd 252 (252.12-1~deb12u1). If i am configuring journald, i am facing the problem, that /var/log is having a very different size on all my machines. From 100M to 8G or something. Documentation states that te default limit is capped at 4G. If you really have 8G of journal files, you probably need to investigate why. Journald states, that the configuration options SystemMaxUse and SystemKeepFree cannot be a relative, percentual value. But they are percentual values by default. If i want to set a percentual value, journald only returns "/etc/systemd/journald.conf:25: Failed to parse size value, ignoring: 20%" So my question is - is there any option to set a relative value/a percentage for that values? Pragmatic answer - service that creates drop-in for journald.conf. It can run every time and drop into /run or just once and drop into /etc. Per default, it seems to be possible. So why not a user defined percentage?
[systemd-devel] Reporting Duplicate Log Lines Issue in journald
Hi community,
I am experiencing an issue while using journald, and I would like to inquire
whether this is a known issue within the community.
The problem is I see duplicate log lines appearing in journald sometimes. It
seems that certain log entries are being duplicated, which can make log
analysis and troubleshooting quite challenging.
Before proceeding with any bug reports or further investigations, I wanted to
reach out to the community to check if anyone else has experienced this issue
or if there are any known workarounds or solutions. It's possible that this
might be a configuration-related problem or a known issue with a specific
version of journald.
For example "journalctl -f -o short-precise" shows a log stream like this:
Sep 01 19:24:12.198000 host app1[1234]: log_line_1 <--
Sep 01 19:24:12.206480 host app2[5678]: log_line_2
Sep 01 19:24:12.216570 host app3[9012]: log_line_3
Sep 01 19:24:12.198000 host app1[1234]: log_line_1 <-- repeated
Both log entries from app1 seem to have identical fields except for the
"__CURSOR" field.
Example:
cursor 1 -->
{"__CURSOR":"s=1a903b70ee3546ed9aeb1d887f6744ed;i=19d76e;b=0727495496944c728dbb763733c88683;m=2bd97bcd0a;t=604515ba608c8;x=35f0437384026ee1"}
cursor 2 -->
{"__CURSOR":"s=1a903b70ee3546ed9aeb1d887f6744ed;i=19d76f;b=0727495496944c728dbb763733c88683;m=2bd97bcd0a;t=604515ba608c8;x=35f0437384026ee1"}
For this example, app1 uses facility local0 and apps 2 & 3 use facility daemon.
Systemd version: 250.4
If you are aware of this problem or have any insights on how to address it, I
would greatly appreciate your guidance. Alternatively, if this is not a known
issue, I am willing to provide additional information and collaborate on
diagnosing and resolving this issue together with the community.
Thank you for your time and consideration. I look forward to your response and
any assistance you can provide.
Best regards,
Swaroop.
[systemd-devel] Question regarding configuration of SystemMaxUse and SystemKeepFree
Hi, i am running a bunch of partly very different systems with Debian Bookworm. On this machines, i am using systemd 252 (252.12-1~deb12u1). If i am configuring journald, i am facing the problem, that /var/log is having a very different size on all my machines. From 100M to 8G or something. Journald states, that the configuration options SystemMaxUse and SystemKeepFree cannot be a relative, percentual value. But they are percentual values by default. If i want to set a percentual value, journald only returns "/etc/systemd/journald.conf:25: Failed to parse size value, ignoring: 20%" So my question is - is there any option to set a relative value/a percentage for that values? Per default, it seems to be possible. So why not a user defined percentage? May you can help me... thanks in advance! Best regards Karl OpenPGP_0x08EAA736C348F670.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[systemd-devel] (no subject)
Okay
Re: [systemd-devel] networkd: IPv6: equivalent of 'default via fe80::1` with policy routing?
On 01/09/2023 14:15, Mantas Mikulėnas wrote: No; `default` has nothing to do with the gateway field. It's an alias for the route *destination network* field, specifically ::/0 for IPv6 or 0.0.0.0/0 for IPv6. What you have is a completely standard IPv6 default route, regardless of which table it's in: [Route] Destination=::/0 Gateway=fe80::1 Doh! How I did not see that in the man-page I do not know! Thank-you for saving me :) OpenPGP_0xEFEC37A429CD6080.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [systemd-devel] networkd: IPv6: equivalent of 'default via fe80::1` with policy routing?
On Fri, Sep 1, 2023 at 2:55 PM TJ wrote: > I may just be over-thinking this but I have a scenario that I can > configure manually but have not been able to figure out how to amend the > networkd configuration to match! > > # echo "2 starlink" >> /etc/iproute2/rt-tables > # ip -6 rule add from 2001:0DB8:1:1::/64 table starlink priority 100 > # ip -6 route add default via fe80::1 dev WAN table starlink > > Note: 'via' required to prevent failed neighbour solicitations for > external addresses. > > The issue is I cannot see how to achieve both 'default' and 'via' in > .network > ROUTE section (when specifying a routing table). > I see recommendations to use `Gateway=::` as an alias for 'default' but > that prevents > setting the next-hop router address explicitly, which results in failure > due to neighbour > solicitation. > No; `default` has nothing to do with the gateway field. It's an alias for the route *destination network* field, specifically ::/0 for IPv6 or 0.0.0.0/0 for IPv6. What you have is a completely standard IPv6 default route, regardless of which table it's in: [Route] Destination=::/0 Gateway=fe80::1 -- Mantas Mikulėnas
Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
On Fri, 1 Sep 2023 13:37:46 +0200 Lennart Poettering wrote: > On Fr, 01.09.23 13:13, Christian Pernegger (perneg...@gmail.com) wrote: > > > I don't know about this. Yes, seat1 could hog the GPU that seat0's > > outputs are attached to, or vice versa, but seat1 could just as well > > hog all the RAM or saturate the CPU. My point being, seats share the > > host's CPU power, RAM, ..., already, why not the rendering/compute > > power as well. IMVHO it's really just inputs and outputs that should > > be seat-specific. Restricting the shared resources available to a > > given seat, allocating them fairly, etc., is a different problem (and > > arguably one that I'd tackle per user and not per seat). > > CPU/RAM are by default resource managed, i.e. each user logged in gets > a similar amount under pressure, as controlled via the cgroups > logic. > > This is different from GPU resources, there's no such reosurce > management for that. If you mean cgroup resource limits for GPUs, yeah, it's not there yet, but I've seen people trying to add them. It just seems difficult to define what those resources are exactly and how to measure them in a sensible way, since GPUs have wildly different execution unit architectures. I'm not sure what the current patch state is. Thanks, pq pgp8gyq3kPyME.pgp Description: OpenPGP digital signature
Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
On Fri, 1 Sep 2023 13:13:12 +0200 Christian Pernegger wrote: > Alright. I only played around with it in the hopes that it would help > me get some VTs (and VT switching) on seat1. So far, no luck on that > front. The funny thing there is that the kernel, where the VT is implemented, has no idea of any seat assignments. Seat management is completely a userspace invention. This can have some wild (security) consequences: https://gitlab.freedesktop.org/wayland/weston/-/issues/434 IOW, if seat0 is running only VT, you might have keyboards from *any* seat type into that VT *in addition* to any session running on that other seat. It's also common to assume, that only the default seat (seat0) can even have VTs. I don't see how you could have VTs on multiple seats, when the kernel simply has no concept of a seat. There is only one VT system, and that either takes input or does not (there is an ioctl for that). Individual input devices can only be excluded from the VT by opening and grabbing them, meaning nothing else can get them either. It would be best to forget the kernel VTs completely, and implement the equivalent in userspace, which can then be seat-aware and much more featureful (fonts, input methods) than the in-kernel VT can ever be. E.g. kmscon: https://wiki.archlinux.org/title/KMSCON Unfortunately looks like the original repository has been untouched for a decade now. Arch seems to be using this instead: https://github.com/Aetf/kmscon/ You might even want to aim for CONFIG_VT=n, in which case https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/?rdt=37727 might be interesting. Thanks, pq pgpBqMGXEm3d4.pgp Description: OpenPGP digital signature
[systemd-devel] networkd: IPv6: equivalent of 'default via fe80::1` with policy routing?
I may just be over-thinking this but I have a scenario that I can configure manually but have not been able to figure out how to amend the networkd configuration to match! # echo "2 starlink" >> /etc/iproute2/rt-tables # ip -6 rule add from 2001:0DB8:1:1::/64 table starlink priority 100 # ip -6 route add default via fe80::1 dev WAN table starlink Note: 'via' required to prevent failed neighbour solicitations for external addresses. The issue is I cannot see how to achieve both 'default' and 'via' in .network ROUTE section (when specifying a routing table). I see recommendations to use `Gateway=::` as an alias for 'default' but that prevents setting the next-hop router address explicitly, which results in failure due to neighbour solicitation. Scenario (current): IPv6 only local network gateway is host using systemd-networkd (systemd 252.12 on Debian 12) gateway is directly connected to Starlink terminal (the 'dish') on interface "WAN" "WAN" interface has only operated on IPv4 until now (CG-NAT) Wireguard IP tunnel to data-center server acting as public gateway Wireguard tunnel only carries IPv6 data-center gateway delegates public IPv6 prefix to local gateway local hosts allocated public addresses by gateway Scenario (new): Starlink terminal now advertises an IPv6 /64 prefix using RA allocate IPv6 from prefix (manually or automatically) to "WAN" use policy routing so replies go out on "WAN" when arriving on that interface (this is to act as a back-up since the Wireguard tunnel will remain the primary routing) /etc/systemd/networkd.conf: [Network] RouteTable=starlink:2 /etc/systemd/network/WAN.network: # ... existing configuration# named tables must be added to /etc/systemd/networkd.conf as name:number pairs, space separated: # [Network] # RouteTable=starlink:2 [Address] Address=2001:0DB8:1:1::dead:beef/64 [RoutingPolicyRule] Table=starlink From=2001:0DB8:1:1::/64 Priority=100 [Route] # starlink terminal link-local address (gateway's should always use link-local address) Gateway=fe80::1 # default route # Gateway=:: GatewayOnLink=true Table=starlink OpenPGP_0xEFEC37A429CD6080.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
On Fr, 01.09.23 13:13, Christian Pernegger (perneg...@gmail.com) wrote: > Of course, if you want to take the position that it's a bit weird for > GNOME to use /dev/rfkill to detect the presence of BT devices, I can't > argue against that. :) Doesn't NM/bluez manage these things from privileged code anyway? Is this really done from inside the GNOME UI with direct device access? > (From a use case perspective, it would be nice if paired BT devices > could somehow be tagged. I.e. so that each seat can pair devices and > manage them, but not see or manage ones paired by other seats and/or > users.) Yeah, it would be great if bluez would gain native multi-seat support, i.e. that it tracks seat assignments for paired devices. But that's something to request from bluez upstream, not systemd. > > You cannot attach devices to multiple seats. > > Roger that. Is there a way to exempt devices from the multiseat > mechanism, though? Mark them not seat-specific? Or is that > hard-coded? change the udev rules to not set the "seat" udev property on the relevant device. That's what decides whether seat mgmt is done for the device. > > You should be able to assign the device to a different seat though. > > systemctl attach won't let me, at least not using the path seat-status > spits out. But I'm sure the version of systemd in Ubuntu 22.04 is > ancient, and/or they may have done something to it. If you like, I can > try whether adding a udev rule manually works, but personally I'm not > too bothered about this particular issue. So the problem is that the rfkill device does not carry the ID_FOR_SEAT property right now, we only add that for pci/usb/… devices, i.e. the usual busses. rfkill being a virtual device doesn't carry that property. That property carries the string identifier that we should use for identifying the device for seat mgmt purposes. It's usually derived from the path ID of the device. To make rfkill managable via "loginctl attach" would mean adding such a property there. happy to take a patch for that, please submit via github. > > that's how things work and people assume them to work: graphics render > > services are used to bring stuff to screen. > > I don't know about this. Yes, seat1 could hog the GPU that seat0's > outputs are attached to, or vice versa, but seat1 could just as well > hog all the RAM or saturate the CPU. My point being, seats share the > host's CPU power, RAM, ..., already, why not the rendering/compute > power as well. IMVHO it's really just inputs and outputs that should > be seat-specific. Restricting the shared resources available to a > given seat, allocating them fairly, etc., is a different problem (and > arguably one that I'd tackle per user and not per seat). CPU/RAM are by default resource managed, i.e. each user logged in gets a similar amount under pressure, as controlled via the cgroups logic. This is different from GPU resources, there's no such reosurce management for that. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
Am Fr., 1. Sept. 2023 um 11:48 Uhr schrieb Lennart Poettering : > > It makes no sense for /dev/rfkill to belong to a specific seat, > > though. > > Typically any RF kill buttons are attached to the main seat of a > laptop only, hence this assignment. If there's some form of physical RF kill button (dedicated, hard-wired keyboard shortcut, whatever), it makes perfect sense to assign that *button* to a specific seat. But /dev/rfkill, the rfkill *mechanism*, doesn't depend on the presence or absence of an RF kill button, does it? Just the presence of wireless hardware. You always have soft rfkill, don't you? (This particular box is a desktop without any physical RF kill buttons.) Of course, if you want to take the position that it's a bit weird for GNOME to use /dev/rfkill to detect the presence of BT devices, I can't argue against that. :) (From a use case perspective, it would be nice if paired BT devices could somehow be tagged. I.e. so that each seat can pair devices and manage them, but not see or manage ones paired by other seats and/or users.) > You cannot attach devices to multiple seats. Roger that. Is there a way to exempt devices from the multiseat mechanism, though? Mark them not seat-specific? Or is that hard-coded? > You should be able to assign the device to a different seat though. systemctl attach won't let me, at least not using the path seat-status spits out. But I'm sure the version of systemd in Ubuntu 22.04 is ancient, and/or they may have done something to it. If you like, I can try whether adding a udev rule manually works, but personally I'm not too bothered about this particular issue. > /dev/kvm is 0666 by default, except of some distros [...] Oh. I see. Sorry about that, then. > fb is obsolete. Alright. I only played around with it in the hopes that it would help me get some VTs (and VT switching) on seat1. So far, no luck on that front. > that's how things work and people assume them to work: graphics render > services are used to bring stuff to screen. I don't know about this. Yes, seat1 could hog the GPU that seat0's outputs are attached to, or vice versa, but seat1 could just as well hog all the RAM or saturate the CPU. My point being, seats share the host's CPU power, RAM, ..., already, why not the rendering/compute power as well. IMVHO it's really just inputs and outputs that should be seat-specific. Restricting the shared resources available to a given seat, allocating them fairly, etc., is a different problem (and arguably one that I'd tackle per user and not per seat). Anyway, thanks for getting back to me. Have a nice weekend! Christian Pernegger
Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
On Fr, 01.09.23 02:02, Christian Pernegger (perneg...@gmail.com) wrote:
> Am Do., 31. Aug. 2023 um 21:55 Uhr schrieb Andrei Borzenkov
> :
> >
> > On 31.08.2023 19:22, Christian Pernegger wrote:
> > There is no ID_SEAT, so this device [/dev/rfkill] ]belongs to seat0 by
> > default.
>
> It makes no sense for /dev/rfkill to belong to a specific seat,
> though.
Typically any RF kill buttons are attached to the main seat of a
laptop only, hence this assignment.
> GNOME at least assumes the user to have write access.
> Note that while /sys/devices/virtual/misc/rfkill shows up in the
> output of loginctl seat-status it cannot be attached to another seat
> ("Could not attach device: No such device").
You cannot attach devices to multiple seats. You should be able to
assign the device to a different seat though.
> Or what about /dev/kvm? Why should only seat0 have the ability to use
> KVM? (It can't be attached to other seats, either.)
/dev/kvm is 0666 by default, except of some distros that depart from
that. Please contact them for help how they intend to manage access
there, but the uaccess logic is not it.
> The dri/renderD??? device is automatically attached to the seat that
> the dri/card? one is attached to (even though it isn't a child
> according to the seat-status tree--funnily enough this does not happen
> for the fb? device).
fb is obsolete. fb devices are still assigned to seats but no unpriv
access is granted.
> It makes sense that the rendering bits of a card should "belong to"
> the seat that has the outputs, the problem is that this renders it
> inaccessible to the other seats, which it shouldn't. A seat can
> access another seat's *rendering capabilities* just fine as long as
> the permissions are set correctly.
Well, you can do lots of things. We ship defaults only. Feel free to
write udev rules that assign things to whatever you want them to be
assigned.
By default render devices are only accessible to local users on the
seat they are logged on to, not everyone else, since typically
resources on a graphics card are bounded, and it makes sense to give
access to users who also get access to the screen, because typically
that's how things work and people assume them to work: graphics render
services are used to bring stuff to screen. There's also a "render"
group set up to which users can be added which should always get
access.
Lennart
--
Lennart Poettering, Berlin
Re: [systemd-devel] Assertion '!ether_addr_is_null(addr)'
On Thu, 31 Aug 2023 at 12:12, Lennart Poettering wrote: > > On Mi, 30.08.23 15:22, Mirza Krak (mirza.k...@gmail.com) wrote: > > > Hi, > > > > Environment: > > * systemd: 250.5 > > This release is from 2021, i.e. relatively old. The issue you are > descriping is almost certainly aleady addressed in newer > versions. Consider using a new version. Or contact your OS vendor, > asking them to maybe backport the fix in question. Unfortunately I am the OS vendor (Yocto Project based distribution), so it's up to me to solve it :). Would like to avoid updating to a newer version at the moment, so the backport does sound like a feasible path forward. Would appreciate any pointers/references to where this issue might reside, to help me find the necessary backports. / Mirza
