[systemd-devel] What are the use cases of journalctl --flush ?

[krave1986121]

Hi, I have already read man page of journalctl and made some experiments
with the command.

All the efforts made me more confused. So, I would like to beg some help
here.

My system is Ubuntu 20.04.3 LTS.

 

My procedures:

 

1. Create a .conf file for systemd-jounald.service with following
content:
[Journal]
Storage=volatile



2. Restart systemd-jounald.service

sudo systemctl restart systemd-jounald.service



3. Check the status of journald and ensure it is writing log into
memory.

systemctl status systemd-jounald.service

The result is like:

Runtime Journal (/run/log/journal/...)
which informed me that .conf file worked well.



4. Comment out the Storage option
[Journal]
#Storage=volatile




5. Restart journald

sudo systemctl restart system-journald



6. check status again and you will see that flush already been done

systemctl status system-journald

with feedback including

Time spent on flushing to /var/log/journal/machineID/ is 282.991ms for 1483
entries.

which means flush had been done.

 

Now that the operation of flush can be done automatically when you switch
from Storage=volatile to #Storage=volatile, why do we still need journalctl
--flush?

 

I believe there are some reasons for the existence of this switch for
journalctl.

Hopefully, I can find some help here.

 

Thank you!

Re: [systemd-devel] Xorg or Wayland Environment

[David Edmundson]

> What would be the proper way to get the DISPLAY environment varible use it as 
> opposed

Having someone else (your desktop) call
"dbus-update-activation-environment --systemd" on startup or an
equivalent
and ensure your service is started after that, such as being after
graphical-session.target

David

Re: [systemd-devel] Xorg or Wayland Environment

[Christopher Cox]

On 9/21/21 9:13 AM, Michael Biebl wrote:

Just curious:

Can someone familiar with KDE/Plasma tell us, if they nowadays (can)
use "systemd --user" to manage a login session.


Seems to be the case on openSUSE Leap 15.3

So, I'll say yes.




Am Di., 21. Sept. 2021 um 12:52 Uhr schrieb Ed Greshko :


On 21/09/2021 18:20, Colin Guthrie wrote:

Ed Greshko wrote on 19/09/2021 12:11:

OK..

I think I see the problem now.  I don't need Environment=.  But the issue is that, I 
assumed, "plasma-core.target" would be
reached only after a user logged in to plasma.

I was wrong and the user's service is run earlier when the login screen appears.


I'm slightly confused by the logic here. Why is a user's systemd even running 
before they've logged in? If the user has lingering enabled, then it might have 
a systemd instance from that, but it certainly shouldn't reach any 
plasma-core.target as the login GUI should be running as a different user to 
your user I would have thought?

e.g. under gnome, the login GUI runs as the "gdm" user. That user has a systemd 
--user instance, and runs various things but only once a real user has logged in will 
it's own systemd instance start and reach the appropriate targets.


I need to find a way such that the service only runs when a user logs on to the 
plasma GUI.


It seems a bit odd to me that your users' plasma-core.target has been run when 
your user hasn't even logged in yet. I think something is odd there, possible 
combined with user lingering and perhaps plasma-core being the default target 
for your user when it shouldn't be...

Hope this helps you debug things.


Yes, that helped.

plasma-core.target isn't the correct target.  I switched to 
graphical-session.target.

I believe one issue remains.

On login, after a reboot, the app is started.  And, on logout the app is 
terminated.

The issue is that if the user logs out and logs back in the service is not run.

How to make sure the service is run each time the user logs in?

Re: [systemd-devel] Xorg or Wayland Environment

[Michael Biebl]

Just curious:

Can someone familiar with KDE/Plasma tell us, if they nowadays (can)
use "systemd --user" to manage a login session.


Am Di., 21. Sept. 2021 um 12:52 Uhr schrieb Ed Greshko :
>
> On 21/09/2021 18:20, Colin Guthrie wrote:
> > Ed Greshko wrote on 19/09/2021 12:11:
> >> OK..
> >>
> >> I think I see the problem now.  I don't need Environment=.  But the issue 
> >> is that, I assumed, "plasma-core.target" would be
> >> reached only after a user logged in to plasma.
> >>
> >> I was wrong and the user's service is run earlier when the login screen 
> >> appears.
> >
> > I'm slightly confused by the logic here. Why is a user's systemd even 
> > running before they've logged in? If the user has lingering enabled, then 
> > it might have a systemd instance from that, but it certainly shouldn't 
> > reach any plasma-core.target as the login GUI should be running as a 
> > different user to your user I would have thought?
> >
> > e.g. under gnome, the login GUI runs as the "gdm" user. That user has a 
> > systemd --user instance, and runs various things but only once a real user 
> > has logged in will it's own systemd instance start and reach the 
> > appropriate targets.
> >
> >> I need to find a way such that the service only runs when a user logs on 
> >> to the plasma GUI.
> >
> > It seems a bit odd to me that your users' plasma-core.target has been run 
> > when your user hasn't even logged in yet. I think something is odd there, 
> > possible combined with user lingering and perhaps plasma-core being the 
> > default target for your user when it shouldn't be...
> >
> > Hope this helps you debug things.
>
> Yes, that helped.
>
> plasma-core.target isn't the correct target.  I switched to 
> graphical-session.target.
>
> I believe one issue remains.
>
> On login, after a reboot, the app is started.  And, on logout the app is 
> terminated.
>
> The issue is that if the user logs out and logs back in the service is not 
> run.
>
> How to make sure the service is run each time the user logs in?
>
>

Re: [systemd-devel] Pre-installed portable services ?

[Luca Boccassi]

On Tue, 21 Sept 2021 at 09:30, Umut Tezduyar Lindskog
 wrote:
>
> Hi,
>
> On 2021-09-20, 5:19 PM, "Lennart Poettering"  wrote:
>
> On Mo, 20.09.21 11:24, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) 
> wrote:
>
> > Hi. Is there such thing as “pre-installed” portable services? If
> > not, what is the best way to achieve it. One option can be to place
> > the files that “attach” command creates on the distro but I am
> > worried that the files might be outdated depending on the systemd
> > version the distro is shipped.
>
> What do you mean by "pre-installed" precisely?
>
> I mean, portable services can be dropped into /usr/lib/portables/,
> i.e. a dir that typically is included in the base OS image? (As
> opposed to /var/lib/portables/, where they are usually dropped, given
> they should be able to be added anytime).
>
> Or do you mean that they are also "pre-attached" and "pre-enabled"? If
> you want that you could either call "portablectl attach" at boot, or
> just package the symlinks/files the call creates.
>
> This.
>
> Seems like 20-portable.conf is created not symbol linked. If we package the 
> files ourself, then we need to make sure they are up to date as new versions 
> of systemd might tweak them. I guess.
>
> We could also add some special dirs that may contain images we'll
> automatically attach + enable during boot as we discover them. That'd
> be a new feature though.
>
> Cool! If the feature is not there by the time we put our hands on portable 
> services, we would send a patch upstream.
>
> Thanks for your feedback.

Well we should have enough tooling already for image builds to make
this seamless, without needing runtime action, no? In my experience of
image building it's much easier to delegate as much as possible to
build time, than runtime, as it's much easier to validate and debug.

Re: [systemd-devel] Xorg or Wayland Environment

[Ed Greshko]

On 21/09/2021 18:20, Colin Guthrie wrote:

Ed Greshko wrote on 19/09/2021 12:11:

OK..

I think I see the problem now.  I don't need Environment=.  But the issue is that, I 
assumed, "plasma-core.target" would be
reached only after a user logged in to plasma.

I was wrong and the user's service is run earlier when the login screen appears.


I'm slightly confused by the logic here. Why is a user's systemd even running 
before they've logged in? If the user has lingering enabled, then it might have 
a systemd instance from that, but it certainly shouldn't reach any 
plasma-core.target as the login GUI should be running as a different user to 
your user I would have thought?

e.g. under gnome, the login GUI runs as the "gdm" user. That user has a systemd 
--user instance, and runs various things but only once a real user has logged in will 
it's own systemd instance start and reach the appropriate targets.


I need to find a way such that the service only runs when a user logs on to the 
plasma GUI.


It seems a bit odd to me that your users' plasma-core.target has been run when 
your user hasn't even logged in yet. I think something is odd there, possible 
combined with user lingering and perhaps plasma-core being the default target 
for your user when it shouldn't be...

Hope this helps you debug things.


Yes, that helped.

plasma-core.target isn't the correct target.  I switched to 
graphical-session.target.

I believe one issue remains.

On login, after a reboot, the app is started.  And, on logout the app is 
terminated.

The issue is that if the user logs out and logs back in the service is not run.

How to make sure the service is run each time the user logs in?

Re: [systemd-devel] when mount is delayed - start unit which depends on it - ?

[Colin Guthrie]

Mantas Mikulėnas wrote on 18/09/2021 09:41:


On Fri, Sep 17, 2021 at 2:40 PM lejeczek > wrote:


Hi guys.

I'm trying to have unit to start...
well,
I have a luks device which waits for manual passphrase
input, when that happens 'systemd' mounts, without user
intervention(which is great), that luks device.
fstab:
/dev/mapper/luks.devs /devs   ext4
noatime,nobarrier,noatime,x-systemd.device-timeout=2,nofail 1 2
and now I'll have many units/services which depend on that
mount, because they need to get to paths to get their
configs & other bits.

Question - how do I make such a unit to re/start when
'systemd' does the mount? Naturally, ideally without any
ways external to 'systemd'.


If units need this mount, then *actually* make them depend on this mount 
– as in, "Requires=devs.mount" and "After=devs.mount" in each service's 
[Unit].


I agree this is correct, but I don't think it does what the user wants. 
i.e. when the mount eventually happens (e.g. after all the jobs have 
timed out and the user manually mounts it), the rest of the transaction 
continues where it left off rather than just sitting their failed/unstarted.


I think there is possibly something you could do with a udev rule, a 
custom target unit and PartOf= in the dependant services?


Or perhaps a path unit based on a file inside the mounted filesystem 
which again triggers a target (again coupled with PartOf in the 
dependant services).



HTHs


--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: [systemd-devel] Xorg or Wayland Environment

[Colin Guthrie]

Ed Greshko wrote on 19/09/2021 12:11:

OK..

I think I see the problem now.  I don't need Environment=.  But the 
issue is that, I assumed, "plasma-core.target" would be

reached only after a user logged in to plasma.

I was wrong and the user's service is run earlier when the login screen 
appears.


I'm slightly confused by the logic here. Why is a user's systemd even 
running before they've logged in? If the user has lingering enabled, 
then it might have a systemd instance from that, but it certainly 
shouldn't reach any plasma-core.target as the login GUI should be 
running as a different user to your user I would have thought?


e.g. under gnome, the login GUI runs as the "gdm" user. That user has a 
systemd --user instance, and runs various things but only once a real 
user has logged in will it's own systemd instance start and reach the 
appropriate targets.


I need to find a way such that the service only runs when a user logs on 
to the plasma GUI.


It seems a bit odd to me that your users' plasma-core.target has been 
run when your user hasn't even logged in yet. I think something is odd 
there, possible combined with user lingering and perhaps plasma-core 
being the default target for your user when it shouldn't be...


Hope this helps you debug things.

Col




--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

[systemd-devel] Proc protection of services and TemporaryFileSystem=/

[John]

TemporaryFileSystem=/ can be used to limit the file system with just some 
necessary paths set by BindReadOnlyPaths/BindPaths to some files, depending on 
what the service needs. This does not mount /proc and /sys.

There are some [service] settings regarding proc such as: ProtectProc, 
ProtectKernelTunables, ProtectControlGroups, ProcSubset which re-introduce 
/proc. My question is if their most protective functions are active just 
because /proc is not present. If so, systemd-analyze security could be improved 
by recognizing that /proc isn't available.

Examples:
ProtectProc=invisible
ProtectKernelTunables=true
ProtectControlGroups=true
ProcSubset=pid

On another note, ProtectHostname=true seems to cause a systemd error in a 
limited file system.

Any insights are appreciated.

Re: [systemd-devel] Pre-installed portable services ?

[Umut Tezduyar Lindskog]

Hi,

On 2021-09-20, 5:19 PM, "Lennart Poettering"  wrote:

On Mo, 20.09.21 11:24, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) 
wrote:

> Hi. Is there such thing as “pre-installed” portable services? If
> not, what is the best way to achieve it. One option can be to place
> the files that “attach” command creates on the distro but I am
> worried that the files might be outdated depending on the systemd
> version the distro is shipped.

What do you mean by "pre-installed" precisely?

I mean, portable services can be dropped into /usr/lib/portables/,
i.e. a dir that typically is included in the base OS image? (As
opposed to /var/lib/portables/, where they are usually dropped, given
they should be able to be added anytime).

Or do you mean that they are also "pre-attached" and "pre-enabled"? If
you want that you could either call "portablectl attach" at boot, or
just package the symlinks/files the call creates.

This. 

Seems like 20-portable.conf is created not symbol linked. If we package the 
files ourself, then we need to make sure they are up to date as new versions of 
systemd might tweak them. I guess. 

We could also add some special dirs that may contain images we'll
automatically attach + enable during boot as we discover them. That'd
be a new feature though.

Cool! If the feature is not there by the time we put our hands on portable 
services, we would send a patch upstream. 

Thanks for your feedback. 

Lennart

--
Lennart Poettering, Berlin