Re: [systemd-devel] Additional Locale Variables for Units and Number Format
Thank you, I think LC_NUMERIC will work for the number formatting, my company
is also looking for something along the lines of this, and hoping to use
locale/systemd to handle it:
https://lists.freedesktop.org/archives/xdg/2023-August/014659.html
From: systemd-devel on behalf of
systemd-devel-requ...@lists.freedesktop.org
Sent: Tuesday, August 29, 2023 6:24 PM
To: systemd-devel@lists.freedesktop.org
Subject: systemd-devel Digest, Vol 160, Issue 37
Send systemd-devel mailing list submissions to
systemd-devel@lists.freedesktop.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
or, via email, send a message with subject or body 'help' to
systemd-devel-requ...@lists.freedesktop.org
You can reach the person managing the list at
systemd-devel-ow...@lists.freedesktop.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of systemd-devel digest..."
Today's Topics:
1. Re: Additional Locale Variables for Units and Number Format
(Mantas Mikul?nas)
2. Re: Why are the priorities of stdout and stderr the same
(Nils Kattenbeck)
3. Re: Why are the priorities of stdout and stderr the same
(Cecil Westerhof)
4. Re: oomd wake-up frequency (Christian Hergert)
5. Re: Bluetooth in a multiseat (via loginctl) setup
(Christian Pernegger)
--
Message: 1
Date: Tue, 29 Aug 2023 23:19:19 +0300
From: Mantas Mikul?nas
To: TJ Shipp
Cc: Systemd
Subject: Re: [systemd-devel] Additional Locale Variables for Units and
Number Format
Message-ID:
Content-Type: text/plain; charset="utf-8"
It sounds like you're reinventing LC_NUMERIC.
The locale system has a lot more than just LANG; it already allows the
number format to be overridden separately from the "language". Take a look
at `locale -k LC_NUMERIC` and <
https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html>.
Adding custom variables would require changing a lot ? I guess the main
consumers are libc (Glibc) and libstdc++ (GCC), but of course there are
many places which set the existing LC_* and expect things to change
accordingly, or which might implement the standard interfaces on their own
without using libc.
On Tue, Aug 29, 2023, 20:17 TJ Shipp wrote:
> I am trying to add in support for a separate variable to change our unit
> system, and having both LANG and UNITS to identify the "locale" of the
> system.
> We are also not only looking for English versus Metric, but are looking
> for mixed units as well (both Imperial and Metric hybrid), as well as
> looking to add number formats (1,000.00 vs 1.000,00)
>
> And what is the best way to add support for a new system environment
> variable such as UNITS?
>
> P.S. If anyone is interested in contracting to do this work, please send
> me a private message outside this list.
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/systemd-devel/attachments/20230829/22c38e57/attachment-0001.htm>
--
Message: 2
Date: Tue, 29 Aug 2023 23:05:28 +0200
From: Nils Kattenbeck
To: Cecil Westerhof
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] Why are the priorities of stdout and
stderr the same
Message-ID:
Content-Type: text/plain; charset="UTF-8"
No, you can use systemd-cat to then invoke your script which applies
to every output of it.
Also, you can just use reply-all in gmail (or even set it as the
default in the settings) to have the correct behaviour of sending
mails also the the mailing list.
On Tue, Aug 29, 2023 at 10:25?PM Cecil Westerhof wrote:
>
> Aargh, forgot again that gmail works differently when replying. :'-{
>
> Op di 29 aug 2023 om 21:07 schreef Cecil Westerhof :
>>
>> Op di 29 aug 2023 om 19:47 schreef Nils Kattenbeck :
>>>
>>> Hi, At least for simple cases you can use systemd-cat which allows
>>> setting different priorities for stdout and stderr. It even explicitly
>>> states that doing so will lose the ordering guarantees which are only
>>> possible when attaching stdout and stderr to the same fd (as Lennart
>>> said).
>>
>>
>> If I understand it correctly, that is on a statement basis, not for the
>> complete script.
>
>
> --
> Cecil Westerhof
--
Message: 3
Date: Wed, 30 Aug 2023 00:10:22 +0200
From: Cecil Westerhof
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] Why are the priorities of stdout and
stderr the same
Message-ID:
Content-Type: text/plain; charset="utf
Re: [systemd-devel] Bluetooth in a multiseat (via loginctl) setup
Hello again, shelving that multiple BT adapters idea for a moment, since that doesn't seem to be a supported configuration, more's the pity, the issue with GNOME seems to be that /dev/rfkill doesn't get the right permissions. It's tagged "uaccess" alright, the intention seems to be that (active) logged-in users get rw-, but this only actually works on seat0. If both seats idle at the greeter, gdm (or lightdm) gets rw- via ACL. If I login at seat0, that ACL is replaced by an identical one for my user, and the GNOME BT panel works. If I login at seat1 instead, nothing changes, there's still just the one ACL for the greeter's user (and obviously the GNOME BT panel is broken). Obviously I could just override the regular permissions via udev rule, give it to an "rfkill" group or something, but I'd rather do it properly. Kind regards, Christian Pernegger I login on seat0, my user gets r Am Mo., 28. Aug. 2023 um 15:12 Uhr schrieb Christian Pernegger < perneg...@gmail.com>: > Hello all! > > Sorry to bother a -devel list with my user troubles, but I don't know > where (else) to start. > > So, Ubuntu 22.04, multiseat setup automagically via loginctl. The only > thing I had to do extra was disable Wayland in gdm. Works beautifully. > Except for Bluetooth. > > I've one USB port (with an attached hub) attached to seat one. Thought I'd > just attach a dedicated BT dongle to that hub, done. Turns out BT adapters > don't show up in the output of loginctl seat-status at all, not the USB one > on the hub, not the (USB) one integrated into the mainboard. Looking at > them with udevadm they seem to be tagged correctly, AFAICT. > > In GNOME on seat1 it shows my (manually paired) BT keyboard in the system > dropdown menu, but when I open BT settings it says BT is off, no adapters > found. > In GNOME on seat0 the BT settings GUI works, but AFAICT shows the wrong > adapter. > > I'm thinking I may just have the wrong end of the stick entirely--how is > BT supposed to work with multiseat? Ideally each seat would be able to pair > and configure its own BT devices in the usual GNOME GUI. But maybe it's > more of a bluetoothd access control thing than a device assignment one? > > Anyway, would appreciate a few pointers, > > Kind regards, > Christian Pernegger > > > >
Re: [systemd-devel] oomd wake-up frequency
On 8/25/23 7:54 AM, Michal Koutný wrote: I think the loop's event source could be disabled when no cgroups require swap monitoring [1] (and enabled lazily when such are configured). FYI I implemented your design this afternoon in case you have some time to review. https://github.com/systemd/systemd/pull/29011/commits/4806e203aa64bca942a780c4d92ea0b6b51ddd5c Thanks! -- Christian
Re: [systemd-devel] Why are the priorities of stdout and stderr the same
Op di 29 aug 2023 om 23:05 schreef Nils Kattenbeck :
> No, you can use systemd-cat to then invoke your script which applies
> to every output of it.
>
OK, I will dive into it.
> Also, you can just use reply-all in gmail (or even set it as the
> default in the settings) to have the correct behaviour of sending
> mails also the the mailing list.
>
I will do that then. Only problem is that the original poster will get the
message two times.
Except when I remove the To. But forgetting to remove that is not as bad as
not sending it to the mailing list.
> On Tue, Aug 29, 2023 at 10:25 PM Cecil Westerhof
> wrote:
> >
> > Aargh, forgot again that gmail works differently when replying. :'-{
> >
> > Op di 29 aug 2023 om 21:07 schreef Cecil Westerhof <
> cldwester...@gmail.com>:
> >>
> >> Op di 29 aug 2023 om 19:47 schreef Nils Kattenbeck <
> nilskem...@gmail.com>:
> >>>
> >>> Hi, At least for simple cases you can use systemd-cat which allows
> >>> setting different priorities for stdout and stderr. It even explicitly
> >>> states that doing so will lose the ordering guarantees which are only
> >>> possible when attaching stdout and stderr to the same fd (as Lennart
> >>> said).
> >>
> >>
> >> If I understand it correctly, that is on a statement basis, not for the
> complete script.
>
--
Cecil Westerhof
Re: [systemd-devel] Why are the priorities of stdout and stderr the same
No, you can use systemd-cat to then invoke your script which applies
to every output of it.
Also, you can just use reply-all in gmail (or even set it as the
default in the settings) to have the correct behaviour of sending
mails also the the mailing list.
On Tue, Aug 29, 2023 at 10:25 PM Cecil Westerhof wrote:
>
> Aargh, forgot again that gmail works differently when replying. :'-{
>
> Op di 29 aug 2023 om 21:07 schreef Cecil Westerhof :
>>
>> Op di 29 aug 2023 om 19:47 schreef Nils Kattenbeck :
>>>
>>> Hi, At least for simple cases you can use systemd-cat which allows
>>> setting different priorities for stdout and stderr. It even explicitly
>>> states that doing so will lose the ordering guarantees which are only
>>> possible when attaching stdout and stderr to the same fd (as Lennart
>>> said).
>>
>>
>> If I understand it correctly, that is on a statement basis, not for the
>> complete script.
>
>
> --
> Cecil Westerhof
Re: [systemd-devel] Additional Locale Variables for Units and Number Format
It sounds like you're reinventing LC_NUMERIC. The locale system has a lot more than just LANG; it already allows the number format to be overridden separately from the "language". Take a look at `locale -k LC_NUMERIC` and < https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html>. Adding custom variables would require changing a lot – I guess the main consumers are libc (Glibc) and libstdc++ (GCC), but of course there are many places which set the existing LC_* and expect things to change accordingly, or which might implement the standard interfaces on their own without using libc. On Tue, Aug 29, 2023, 20:17 TJ Shipp wrote: > I am trying to add in support for a separate variable to change our unit > system, and having both LANG and UNITS to identify the "locale" of the > system. > We are also not only looking for English versus Metric, but are looking > for mixed units as well (both Imperial and Metric hybrid), as well as > looking to add number formats (1,000.00 vs 1.000,00) > > And what is the best way to add support for a new system environment > variable such as UNITS? > > P.S. If anyone is interested in contracting to do this work, please send > me a private message outside this list. >
Re: [systemd-devel] Why are the priorities of stdout and stderr the same
Aargh, forgot again that gmail works differently when replying. :'-{
Op di 29 aug 2023 om 21:07 schreef Cecil Westerhof :
> Op di 29 aug 2023 om 19:47 schreef Nils Kattenbeck :
>
>> Hi, At least for simple cases you can use systemd-cat which allows
>> setting different priorities for stdout and stderr. It even explicitly
>> states that doing so will lose the ordering guarantees which are only
>> possible when attaching stdout and stderr to the same fd (as Lennart
>> said).
>>
>
> If I understand it correctly, that is on a statement basis, not for the
> complete script.
>
--
Cecil Westerhof
Re: [systemd-devel] Why are the priorities of stdout and stderr the same
Hi, At least for simple cases you can use systemd-cat which allows setting different priorities for stdout and stderr. It even explicitly states that doing so will lose the ordering guarantees which are only possible when attaching stdout and stderr to the same fd (as Lennart said). Greetings Nils On Tue, Aug 29, 2023 at 2:10 PM Cecil Westerhof wrote: > > Op di 29 aug 2023 om 11:58 schreef Lennart Poettering > : >> >> On Di, 29.08.23 11:56, Cecil Westerhof (cldwester...@gmail.com) wrote: >> > > I agree with that usecase, and we have discussed this many times >> > > before, but we couldn#t come up with a nice way to make everything >> > > work: proper ordering and distintion of stdout/stderr. >> > >> > I agree that the default behaviour is the right one. But why not give >> > people the possibility to override this behaviour? When they override it >> > themselves, they cannot complain that they lose ordering. >> >> We are generally conservative when providing mechanisms that are too >> glaringly broken. Even if they are opt-in. > > > OK. Thanks for your patience. > > -- > Cecil Westerhof
[systemd-devel] Custom Localed Configuration Location
I am trying to create a system where we can change locale on a running system (where we would have daemons subscribe to dbus and get the properties changed messages) but need to be able to change the location of the locale file (by default in /etc/locale.conf) as /etc is read-only on our system. Is there a way to change the file location to a writeable location as I can not find any current means to do such? I have tried making a sym-link to another file, but localed re-writes the whole file when called. (For PoC, made /etc writeable, but not able to do long term on our system.) Thank you for your support. P.S. If anyone is interested in contracting to do this work, please send me a private message outside this list.
Re: [systemd-devel] Why are the priorities of stdout and stderr the same
Op di 29 aug 2023 om 11:58 schreef Lennart Poettering < lenn...@poettering.net>: > On Di, 29.08.23 11:56, Cecil Westerhof (cldwester...@gmail.com) wrote: > > > I agree with that usecase, and we have discussed this many times > > > before, but we couldn#t come up with a nice way to make everything > > > work: proper ordering and distintion of stdout/stderr. > > > > I agree that the default behaviour is the right one. But why not give > > people the possibility to override this behaviour? When they override it > > themselves, they cannot complain that they lose ordering. > > We are generally conservative when providing mechanisms that are too > glaringly broken. Even if they are opt-in. > OK. Thanks for your patience. -- Cecil Westerhof
Re: [systemd-devel] Why are the priorities of stdout and stderr the same
On Di, 29.08.23 11:56, Cecil Westerhof (cldwester...@gmail.com) wrote: > > I agree with that usecase, and we have discussed this many times > > before, but we couldn#t come up with a nice way to make everything > > work: proper ordering and distintion of stdout/stderr. > > I agree that the default behaviour is the right one. But why not give > people the possibility to override this behaviour? When they override it > themselves, they cannot complain that they lose ordering. We are generally conservative when providing mechanisms that are too glaringly broken. Even if they are opt-in. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Why are the priorities of stdout and stderr the same
Op di 29 aug 2023 om 11:36 schreef Lennart Poettering < lenn...@poettering.net>: > On Di, 29.08.23 11:20, Cecil Westerhof (cldwester...@gmail.com) wrote: > > > Also: everything has a timestamp, so there is in my opinion when you > choose > > to take them apart no big problem. > > For stream connections like those used for stdout/stderr, lines do not > come with timestamps. We add them on the reception side, which is too late. > I did not know that. I understand it now. > > > > To get what is send to stderr I had to do: > > > > journalctl -p 6 -u aptCacheUsage.service > > > > > > > > which gave beside a lot of other things the things send to stdout. > > > > > > > > Now I have two different statements I can do: > > > > journalctl -p 3 -u aptCacheUsage.service > > > > > > > > But it would be nice if I did not need two different statements (and > the > > > > logic around that) for that. > > > > > > Still not getting what you are trying to say here. > > > > > > > Often I am only interested in what is sent to stderr and do not want what > > is sent to stdout. When both have the same log level I can not really > > filter on messages sent to stderr. At the moment I want to see the > messages > > sent to stderr, I will also get the messages sent to stdout because they > > have the same error level. > > I agree with that usecase, and we have discussed this many times > before, but we couldn#t come up with a nice way to make everything > work: proper ordering and distintion of stdout/stderr. > I agree that the default behaviour is the right one. But why not give people the possibility to override this behaviour? When they override it themselves, they cannot complain that they lose ordering. -- Cecil Westerhof
Re: [systemd-devel] Why are the priorities of stdout and stderr the same
On Di, 29.08.23 11:20, Cecil Westerhof (cldwester...@gmail.com) wrote: > Also: everything has a timestamp, so there is in my opinion when you choose > to take them apart no big problem. For stream connections like those used for stdout/stderr, lines do not come with timestamps. We add them on the reception side, which is too late. > > > To get what is send to stderr I had to do: > > > journalctl -p 6 -u aptCacheUsage.service > > > > > > which gave beside a lot of other things the things send to stdout. > > > > > > Now I have two different statements I can do: > > > journalctl -p 3 -u aptCacheUsage.service > > > > > > But it would be nice if I did not need two different statements (and the > > > logic around that) for that. > > > > Still not getting what you are trying to say here. > > > > Often I am only interested in what is sent to stderr and do not want what > is sent to stdout. When both have the same log level I can not really > filter on messages sent to stderr. At the moment I want to see the messages > sent to stderr, I will also get the messages sent to stdout because they > have the same error level. I agree with that usecase, and we have discussed this many times before, but we couldn#t come up with a nice way to make everything work: proper ordering and distintion of stdout/stderr. The closest I cam was using two distinct SOCK_DGRAM sockets connect()ed to the same target socket (instead of the current approach of using SOCK_STREAM). This would give us two benefits: for each deliverd datagram we would get a source socket address reported to us, and it will tell us which of the two source sockets it was, hence hence if stdout or stderr. Moreover, we would get a kernel-supplied kernel timestamp on each datagram if we want. This however has a fairly big problem too: if programs write too much data into their stdout/stderr at once they would get EMSGSIZE back, which programs generally don't expect (i.e. if write()'s size is larger than datagram max size you get EMSGSIZE). Programs trying to write too much usually expect blocking behaviour... Thus this approach is not really an option. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Why are the priorities of stdout and stderr the same
Op di 29 aug 2023 om 10:13 schreef Lennart Poettering <
lenn...@poettering.net>:
> On Sa, 26.08.23 06:14, Cecil Westerhof (cldwester...@gmail.com) wrote:
>
> Please keep mails like this on the mailing list.
>
Sorry, I am used to that when I am responding to a list, my reply goes to
the list. Gmail sadly works differently. Most I did catch, but not all. :'-(
> > We should not "assume the worst", hence given that the stderr stream
> > > is typically used for all kinds of informational messages we should
> > > not always assume its an error, because quite often its just
> > > informational.
> > >
> >
> > You have a very good point. When tcl opens a process for reading, it is
> an
> > error when there is something to read on stderr, except when you overrule
> > it. But that you can overrule it proves your point.
> >
> > > Hence, we use LOG_INFO if we have no clue simply because that's the
> > > "best assumption".
> > >
> >
> > I agree, but I would suggest a very simple solution.
> > There is SyslogLevel which sets the syslog level for stdout and stderr. I
> > would suggest adding SyslogLevelStderr. SyslogLevel would still set it
> for
> > both except when there is also SyslogLevelStderr.
>
> When journal redirection of both stdout + stderr is enabled for
> systemd services we'll connect a single pipe to both fds, in order to
> guarantee ordering, i.e. ensure that if something is written to
> stdout, and then something to stderr, we'll definitely process it in
> this order too. This however means, that on the receiving side we
> cannot distinguish stdout/stderr anymore, it's all one stream. Hence
> we can only choose between: guarantee correct ordering OR ability to
> distinguish stdout/stderr. We opted for the former, as corrupted
> ordering between stdout/stderr is just too confusing for users.
>
I understand your point. But that could be the default behaviour. At the
moment someone uses SyslogLevelStderr it is a conscious choice to take them
apart.
Also: everything has a timestamp, so there is in my opinion when you choose
to take them apart no big problem.
> > We generally recommend apps to use syslog() or sd-journal APIs to
> > > generate their log messages and specify the log level for each message
> > > explicitly, to avoid any doubts. Many programming language's logging
> > > frameworks natively have support for these.
> >
> > The script I use can be run from the command-line and from a service.
> > Because of that I have to use:
> > logMsg --simple "${message}" >&2
> > and:
> > echo "<3>$(logMsg --simple "${message}")" >&2
> >
> > doable but inconvenient.
> >
> > > Now when I want the things send to stderr I also get the things send to
> > > > stdout.
> > >
> > > I can't parse that.
> > >
> >
> > To get what is send to stderr I had to do:
> > journalctl -p 6 -u aptCacheUsage.service
> >
> > which gave beside a lot of other things the things send to stdout.
> >
> > Now I have two different statements I can do:
> > journalctl -p 3 -u aptCacheUsage.service
> >
> > But it would be nice if I did not need two different statements (and the
> > logic around that) for that.
>
> Still not getting what you are trying to say here.
>
Often I am only interested in what is sent to stderr and do not want what
is sent to stdout. When both have the same log level I can not really
filter on messages sent to stderr. At the moment I want to see the messages
sent to stderr, I will also get the messages sent to stdout because they
have the same error level.
--
Cecil Westerhof
Re: [systemd-devel] Why are the priorities of stdout and stderr the same
On Sa, 26.08.23 06:14, Cecil Westerhof (cldwester...@gmail.com) wrote:
Please keep mails like this on the mailing list.
> > We should not "assume the worst", hence given that the stderr stream
> > is typically used for all kinds of informational messages we should
> > not always assume its an error, because quite often its just
> > informational.
> >
>
> You have a very good point. When tcl opens a process for reading, it is an
> error when there is something to read on stderr, except when you overrule
> it. But that you can overrule it proves your point.
>
> > Hence, we use LOG_INFO if we have no clue simply because that's the
> > "best assumption".
> >
>
> I agree, but I would suggest a very simple solution.
> There is SyslogLevel which sets the syslog level for stdout and stderr. I
> would suggest adding SyslogLevelStderr. SyslogLevel would still set it for
> both except when there is also SyslogLevelStderr.
When journal redirection of both stdout + stderr is enabled for
systemd services we'll connect a single pipe to both fds, in order to
guarantee ordering, i.e. ensure that if something is written to
stdout, and then something to stderr, we'll definitely process it in
this order too. This however means, that on the receiving side we
cannot distinguish stdout/stderr anymore, it's all one stream. Hence
we can only choose between: guarantee correct ordering OR ability to
distinguish stdout/stderr. We opted for the former, as corrupted
ordering between stdout/stderr is just too confusing for users.
> > We generally recommend apps to use syslog() or sd-journal APIs to
> > generate their log messages and specify the log level for each message
> > explicitly, to avoid any doubts. Many programming language's logging
> > frameworks natively have support for these.
>
> The script I use can be run from the command-line and from a service.
> Because of that I have to use:
> logMsg --simple "${message}" >&2
> and:
> echo "<3>$(logMsg --simple "${message}")" >&2
>
> doable but inconvenient.
>
> > Now when I want the things send to stderr I also get the things send to
> > > stdout.
> >
> > I can't parse that.
> >
>
> To get what is send to stderr I had to do:
> journalctl -p 6 -u aptCacheUsage.service
>
> which gave beside a lot of other things the things send to stdout.
>
> Now I have two different statements I can do:
> journalctl -p 3 -u aptCacheUsage.service
>
> But it would be nice if I did not need two different statements (and the
> logic around that) for that.
Still not getting what you are trying to say here.
Lennart
--
Lennart Poettering, Berlin
