Re: [systemd-devel] [EXT] Splitting large message written to stdout, explanation?

[Virendra Negi]

@Windl but the logs are sent to rsyslog is over unix socket.

On Thu, May 25, 2023 at 12:22 PM Windl, Ulrich  wrote:

> Maybe syslog is just the wrong thing for your purpose:
> RFC 5424 states: "The reason syslog transport receivers need only support
> receiving up
>to and including 480 octets has, among other things, to do with
>difficult delivery problems in a broken network."
>
> -Original Message-
> From: systemd-devel  On
> Behalf Of Virendra Negi
> Sent: Sunday, May 21, 2023 12:02 PM
> To: systemd-devel@lists.freedesktop.org
> Subject: [EXT] [systemd-devel] Splitting large message written to stdout,
> explanation?
>
> It's been over a week I have been chasing this
> https://github.com/rsyslog/rsyslog/issues/5137
>
> I was unsure how to ensure that the systemd (since I was getting nowhere
> with rsyslog)  split the message instead of the application program doing
> this.
>
> Apparently, today I just removed the following section from the
> `target.service` file
>
> StandardOutput=syslog
> StandardError=syslog
> SyslogIdentifier=sbagent
> And set the MaxMessageSize to 64K and what I saw was the 1.5MB long
> message that was truncating earlier went through this time without
> truncation and a split happened the way I wanted it to be.
>
> I'm unsure what caused it hence for the sake of understanding it. I'm
> writing this. Can someone put some light on it as to why this happened now
> and not earlier.
>
>
> Thanks
>
>
>
>  <
> https://sugarbox.sgp1.cdn.digitaloceanspaces.com/logo-signature-small.jpg>
>
>     <
> https://www.instagram.com/sugarboxnetworks/>   <
> https://in.linkedin.com/company/margo-networks-pvt.-ltd.>
>
>
> Disclaimer: This e-mail and any documents, files, or previous e-mail
> messages appended or attached to it may contain confidential and/or
> privileged information. If you are not the intended recipient (or have
> received this email in error) please notify the sender immediately and
> delete this e-mail. Any unauthorized copying, disclosure or distribution of
> the material in this email is strictly prohibited & unlawful. The recipient
> acknowledges that Margo Networks Private Limited (SugarBox) may be unable
> to exercise control or ensure or guarantee the integrity of the text of the
> email message and the text is not warranted as to completeness and
> accuracy. Before opening and accessing the attachment, if any, please check
> and scan for virus
>
>

-- 

   
  





-- 
**Disclaimer*: This e-mail and any documents, files, or previous e-mail 
messages appended or attached to it may contain confidential and/or 
privileged information. If you are not the intended recipient (or have 
received this email in error) please notify the sender immediately and 
delete this e-mail. Any unauthorized copying, disclosure or distribution of 
the material in this email is strictly prohibited & unlawful. The recipient 
acknowledges that Margo Networks Private Limited (SugarBox) may be unable 
to exercise control or ensure or guarantee the integrity of the text of the 
email message and the text is not warranted as to completeness and 
accuracy. Before opening and accessing the attachment, if any, please check 
and scan for virus*

[systemd-devel] Creating a man page with 'recipes' for common unit dependency combinations

[Kevin P. Fleming]

As I use systemd more and more I find myself needing to express complex 
dependencies between units. While systemd provides many 'building blocks' which 
can be combined to satisfy the requirements, determining which blocks to use, 
and the pros/cons of each combination, is non-trivial.

Attempting to find examples using search engines generally leads to Stack 
Overflow posts with no answers, or with answers which are wildly out of date, 
or are just incorrect.

I'd like to create a man page to be included with all the rest of the systemd 
man pages which details relatively common scenarios, and the various ways that 
each can be achieved using the dependency options available.

For example, right now I've got a situation with two service units, A and B. I 
want B to always be started when A is started, stopped when A is stopped, 
stopped if A stops itself, restarted if A is restarted, but otherwise left 
alone (so it should not be 'upheld' by A). I suspect this is not an uncommon 
combination, and it would be useful to be able to document one (or more) ways 
that unit dependency specifications can be used achieve this goal.

If this was contained in a man page in the systemd tree, it could then be 
updated as new versions are released with changes in dependency behavior, and 
improved when new versions offer additional dependency specifications as well. 
It would also be available on the freedesktop.org site with the rest of the man 
pages, and over time might end up being the place that most searches land.

Is this something that would be welcomed by the systemd team? Are there others 
out there listening who would be willing to help build this (contributing use 
cases, or reviewing/testing proposed solutions)? I'm happy to drive this 
effort, if so.

Re: [systemd-devel] Monotonic time went backwards, rotating log

[Phillip Susi]

Lennart Poettering  writes:

> We want that within each file all records are strictly ordered by all
> clocks, so that we can find specific entries via bisection.

Why *all* clocks?  Even if you want to search on the monotonic time, you
first have to specify a boot ID within which that monotonic time is
valid, don't you?  So the first step in your search would be to find the
boot records, then bisect from there.

> The message is debug level, no?

log_ratelimit_info(), which appears to be printed by default when I log
in, and I presume my session systemd instance is started.  I guess
that's the problem: it should be debug.

Also though, why doesn't it first note that the boot ID changed?

[systemd-devel] udev rule, continue to next rule only if preb failed

[daggs]

Greetings,

I'm trying to implement the following behavior:
if a usb is added ot removed, run a script before all other existing rules but 
continue to existing iff the script failed
I've added the following rule to /etc/udev/rules.d/5-usb_vm.rules:
ACTION=="add", SUBSYSTEM=="usb", RUN="/usr/local/bin/handle_udev_action"
ACTION=="remove", SUBSYSTEM=="usb", RUN="/usr/local/bin/handle_udev_action"

/usr/local/bin/handle_udev_action runs exit 1 iff the device is a specific one 
(for testing)
but the code continues to the next rule.
is there any way to stop it if the script returned 9?

Thanks

Dagg

Re: [systemd-devel] [EXT] Re: Why does stopping mount units kill user sessions?

[Benjamin Godfrey]

Windl Ulrich rebutted:

Actually I don't quite get it:
If some process is inside $HOME, $HOME shouldn't be unmounted (i-node busy,
or so).
But when there is no process inside $HOME (and no other fd opened on it),
when not allowing to unmount $HOME?
Where does opening an extra fd on $HOME help?


Benjamin Godfrey replied:



Perhaps, I don't understand your objection. Maybe, you are concerned about
a scenario wherein the situation below is true, i.e. there is an open fd in
the $HOME directory keeping the directory open for an active process, and
another fd is added by yet another process, stalling the unmount.


The file descriptor is used as a signal to systemd-login to stay mounted.
For example, User Ulrich is running a media player and/or a text editor
inside the home directory, and let’s say Ulrich’s system is also collecting
data from another server about an unexplained atmospheric phenomenon (UAP)
that needs to be processed on Ulrich’s computer because it has the fastest
processing time.  This UAP data is collected via an automated process.   In
this condition, the computer would keep an fd inside the $HOME directory to
make sure that the home directory stays mounted.

Ulrich forgets he has important UAP data coming in, and he notices his
system is running a little slow.  Ulrich takes a break, turning off his
music, saving his work from the text editor, and logs out.   Here, you
don’t want your system to unmount until after the UAP data is finished, so
it’s good to have an open fd in the $HOME directory.  (Hopefully, when the
UAP data process is finished it closes the fd.)  Once systemd-login spots
that the file descriptor is closed, then it can unmount the home
directory.

You don’t want signal interruptions that could cause data to be lost or
delayed, and: it is generally a good idea to keep an open fd in a user's
home directory, even if there are no processes currently accessing it. This
will help to prevent problems if a process needs access to the home
directory in the future.



On Wed, May 24, 2023 at 11:44 PM Windl, Ulrich  wrote:

> Actually I don't quite get it:
> If some process is inside $HOME, $HOME shouldn't be unmounted (i-node
> busy, or so).
> But when there is no process inside $HOME (and no other fd opened on it),
> when not allowing to unmount $HOME?
> Where does opening an extra fd on $HOME help?
>
> -Original Message-
> From: systemd-devel  On
> Behalf Of Benjamin Godfrey
> Sent: Friday, May 19, 2023 4:59 PM
> To: systemd-devel@lists.freedesktop.org
> Subject: [EXT] Re: [systemd-devel] Why does stopping mount units kill user
> sessions?
>
> Lennart Poettering, wrote:
>
>
>  I think we probably should change systemd-logind to
> implicitly and unconditionally keep an open fd to the home dir of a
> user around as long as there's at least one session of them around,
> simply to make clear that sessions keep home dirs busy. This, as side
> effect would then also mean that autofs wouldn#t be tempted to
> consider the home dir idle as long as there's a session.
>
>
>
> Benjamin Godfrey's reply:
>
>
> That seems like a good idea.  This can be done simply by modifying the
> logind_handle_homedir_umount function to:
>
> C
> static void
> logind_handle_homedir_umount(struct logind_client *client,
>   const char *homedir)###  The function takes
> two arguments client and homedir. client points to a struct loginid_client
> object###  and homedir is a string that points to the users homedir.  {
> struct logind_session *session;
> bool active_sessions = false;  ###  This sets the variable to false by
> default
>
> session = logind_client_find_session_by_homedir(client, homedir);
> if (session) {
> active_sessions = true;  ### There is an active session
> }
>
> if (active_sessions) {
> return;  ###  A session is active, don't shut
> down.
> }
>
> logind_session_kill(session); ###  Shut it down because there is no
> active session by default.
> }
>

Re: [systemd-devel] By what mechanism are locale-related environment variables (LC_*) set in services?

[Andrei Borzenkov]

On 25.05.2023 17:12, Farblos wrote:

Running on systemd 252 (252.6-1) on Debian testing.

It seems that systemd services, also transient ones, get the full set of locale 
environment variables (LANG, LANGUAGE, LC_*) as defined in /etc/default/locale.

I only have found environment variable $LANG mentioned in systemd.exec(5) as "Set or 
Propagated by the Service Manager".

And I have found the following mentioned in locale.conf(5):

   Depending on the operating system, other configuration files might be
   checked for locale configuration as well, however only as fallback.

I guess from that:

1) On Debian, systemd consults /etc/default/locale for locale settings as 
fallback.



I do not know. May be Debian has downstream patch to do it. In principle 
it is also possible to push variable into systemd, so it could be done 
outside of systemd itself.


... hmm, briefly testing systemd-localed does check for 
/etc/default/locale on Ubuntu.



2) systemd does not only propagate $LANG, but also all other locale-related 
environment variables to the processes it invokes.



Yes. systemd system instance will import locale variables on startup 
(from locale.conf or kernel command line), it imports all variables that 
are set.



Is that correct?

Is there any other systemd documentation on that which I might have missed?

If not, should I open whatever doc bugs on GitHub to get the man page(s) 
extended?



I would sat yes.

[systemd-devel] By what mechanism are locale-related environment variables (LC_*) set in services?

[Farblos]

Running on systemd 252 (252.6-1) on Debian testing.

It seems that systemd services, also transient ones, get the full set of locale 
environment variables (LANG, LANGUAGE, LC_*) as defined in /etc/default/locale.

I only have found environment variable $LANG mentioned in systemd.exec(5) as 
"Set or Propagated by the Service Manager".

And I have found the following mentioned in locale.conf(5):

  Depending on the operating system, other configuration files might be
  checked for locale configuration as well, however only as fallback.

I guess from that:

1) On Debian, systemd consults /etc/default/locale for locale settings as 
fallback.

2) systemd does not only propagate $LANG, but also all other locale-related 
environment variables to the processes it invokes.

Is that correct?

Is there any other systemd documentation on that which I might have missed?

If not, should I open whatever doc bugs on GitHub to get the man page(s) 
extended?

Thanks!

Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?

[Lennart Poettering]

On Do, 25.05.23 10:08, Andrea Pappacoda (and...@pappacoda.it) wrote:

> Il giorno mer 24 mag 2023 alle 14:35:05 +02:00:00, Lennart Poettering
>  ha scritto:
> > Note that in systemd git main there's already support for generating
> > UKIs dynamically when a kernel RPM/DEB is installed (as long as the
> > "kernel-install" infra is in use). It can be signed with a local key,
> > that can be enrolled with MOK.
>
> This sounds really interesting! Could you please point to some documentation
> about this feature? I'd like to try it out on my Debian system, if possible.

This has not been released yet in a stable release. It has been merged
into git main though.

See this for the original PR:

https://github.com/systemd/systemd/pull/27262

Lennart

--
Lennart Poettering, Berlin

Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?

[Lennart Poettering]

On Mi, 24.05.23 19:01, Felix Rubio (fe...@kngnt.org) wrote:

> Hi Lennart,
>
> "Sorry, but GPG is a no-go. Not in 2023."
>
> Yes, I understand that. What I am trying to get is a simple way to verify
> that the initramfs has not been tampered with. UKI comes with its own
> challenges, using encryption tied to a measured boot looks overkill, and I
> fully agree in which adding an authentication layer is not
> desirable.

I am not sure what "challenges" you specifically have in mind, but a
UKI with an initrd in a PE envelope (i.e. the "add-on" concept I
mentioned), then you should be pretty close to current behaviour, no?

> Then... what alternatives are available for just performing verification of
> the initramfs? I was giving a look at IMA now, so this could be sorted with
> a policy... but I think this is not supported in sd-boot.

IMA verifies files after the kernel is up, not before. It's not
suitable for validating initrds.

Anway, you should really ask yourself what cryptographic key you want
to authenticate against. Local or vendor one, and where shall it be
stored. That dictates your choices more than anything else.

> In the case I wrap the initramfs on a PE envelope, as you suggested, when
> then its signature be validated automatically? when it gets loaded? Because,
> if so... this would work enough for this use case.

In the "add-on" module for UKIs I mentioned the validation of both the
UKI and the add-ons are done via regular UEFI SecureBoot or via
shim. Both UKIs and add-ons are just PE files after all that thus can
be verified that way. Because the files can be authenticated via shim
you get MOK and so on.

Lennart

--
Lennart Poettering, Berlin

Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?

[Andrea Pappacoda]

Il giorno mer 24 mag 2023 alle 14:35:05 +02:00:00, Lennart Poettering 
 ha scritto:

Note that in systemd git main there's already support for generating
UKIs dynamically when a kernel RPM/DEB is installed (as long as the
"kernel-install" infra is in use). It can be signed with a local key,
that can be enrolled with MOK.


This sounds really interesting! Could you please point to some 
documentation about this feature? I'd like to try it out on my Debian 
system, if possible.


Thanks!