[systemd-devel] Antw: [EXT] Re: Read-only /etc, machine-id with an overlay - journald failing

[Ulrich Windl]

>>> Andreas Kempe  schrieb am 27.02.2020 um 16:30 in
Nachricht
<22004_1582817465_5E57E0B9_22004_221_1_20200227153051.GF26693@hitomi.actianordic

se>:
> On Thu, Feb 27, 2020 at 10:04:37AM +0100, Jérémy ROSEN wrote:
>> Le mer. 26 févr. 2020 à 10:59, Andreas Kempe  a
>> écrit :
>> 
>> > Hello everyone,
>> >
>> > I'm working in a project with an embedded Linux system based on
>> > Openembedded using Systemd version 241 as our init process. We're
>> > using a read‑only /etc. To facilitate development, we want to use a
>> > writeable overlay on /etc, but we ran into an issue.
>> >
>> > When we start, Systemd detects that there is no machine‑id file
>> > present in /etc so it generates and mounts a /etc/machine‑id. When our
>> > mount unit then applies the overlay on /etc, it hides the mounted
>> > file. Journald later fails to start because /etc/machine‑id isn't
>> > visible through the overlay.
Sorry for re-posting: I forgot to reply to the list:

I wonder whether this issue can be reduced to the question whether the machine
ID should be part of initrd. Of course mass-produced embedded devices might end
up all with the same machine-ID, but there are many ways do do things the wrong
way...


>> >
>> > At this point we're considering a number of workarounds, but I thought
>> > it worthwhile asking the experts before we go patching Systemd or
>> > similar.
>> >
>> > My gut feeling is that using overlays on /etc can't be that uncommon
>> > and it is likely PEBKAC on our end. Is there some canonical way of
>> > doing overlays with Systemd and we're screwing things up?
>> >
>> > Thank you in advance for any help!
>> > Cordially,
>> > Andreas Kempe
>>
>> I had similar problems with a case of booting with the rootfs read‑only
and
>> then becoming read‑write later...
>> 
>> Basically systemd only checks for machine‑id very early (before reading
any
>> config file) and does not deal well with /etc changing status...
>> 
> 
> It is somewhat comforting knowing that others are seeing similar
> issues. :)
> 
>> I did a complete analysis of what's going on, with a patch that improves
>> the situation here : https://github.com/systemd/systemd/pull/14135 
>> I am not sure how to deal with it in your specific case.
>> the simplest approch would be to mount your overlay in a initrd (or in a
>> small script shell that is run before systemd and exec systemd as its last
>> step)
>> 
> 
> I was contemplating whether it could be acceptable having the same
> static machine‑id file pre‑generated for all systems. I'm not 100% sure
> what it's used for, TBH; would it be a really bad idea?
> 
>> My patch wouldn't really help in your case, but maybe you can "cheat" by
>> having the underlying /etc/machine‑id bein a symlink to the overlay
>> directory... that could work.
>> 
> 
> I had a look at your patch and as you said, it doesn't really solve
> our use case. At the moment, we decided to remove the overlay from the
> affected parts and simply require a new system image if one wants to
> change /etc.
> 
> We were planning on having signed read‑only overlays for configuration
> in the future so I guess we'll have to investigate this further at a
> later date.
> 
> Thank you for taking the time to respond!
> Cordially,
> Andreas Kempe
> ___
> systemd‑devel mailing list
> systemd‑de...@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel 



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Read-only /etc, machine-id with an overlay - journald failing

[Jérémy ROSEN]

Le jeu. 27 févr. 2020 à 16:30, Andreas Kempe  a
écrit :

> On Thu, Feb 27, 2020 at 10:04:37AM +0100, Jérémy ROSEN wrote:
>
> It is somewhat comforting knowing that others are seeing similar
> issues. :)
>
>
And not to far... you're a customer of ours :P
(well... actia in Toulouse is...)


> > I did a complete analysis of what's going on, with a patch that improves
> > the situation here : https://github.com/systemd/systemd/pull/14135
> > I am not sure how to deal with it in your specific case.
> > the simplest approch would be to mount your overlay in a initrd (or in a
> > small script shell that is run before systemd and exec systemd as its
> last
> > step)
> >
>
> I was contemplating whether it could be acceptable having the same
> static machine-id file pre-generated for all systems. I'm not 100% sure
> what it's used for, TBH; would it be a really bad idea?
>

As long as two machines with the same machine-id are never in contact you
should be fine...

Theoretically the machine-id should never cross the network, but you never
know what individual apps might do

The only place where that could be problematic is the journal : if you mix
the logs of multiple machines with the
same machine-id, you won't be able to tell them appart and that might have
other side-effects I wouldn't know about...


>
> > My patch wouldn't really help in your case, but maybe you can "cheat" by
> > having the underlying /etc/machine-id bein a symlink to the overlay
> > directory... that could work.
> >
>
> I had a look at your patch and as you said, it doesn't really solve
> our use case. At the moment, we decided to remove the overlay from the
> affected parts and simply require a new system image if one wants to
> change /etc.
>
> We were planning on having signed read-only overlays for configuration
> in the future so I guess we'll have to investigate this further at a
> later date.
>
> Thank you for taking the time to respond!
> Cordially,
> Andreas Kempe



-- 
[image: SMILE]  

20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique

[image: email] jeremy.ro...@smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]


[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Configuration option to filter logs sent via systemd-journal-upload

[P.R.Dinesh]

I am using systemd-journal-upload and systemd-journal-remote to sync logs
between two systems.
Do we have any configuration to filter the logs that are sent by
systemd-journal-upload?  Mainly I am interested in filtering the logs by
using message-id.

I am using systemd version 243.

Thank you

-- 
With Kind Regards,
P R Dinesh
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Configuration option to set the ownership of coredump files

[P.R.Dinesh]

Do we have a configuration option to change the ownership of core dump
files generated by systemd-coredump?

Mainly I would like to set the ownership group of the coredumps to a custom
group.

I am using systemd version 243.

-- 
With Kind Regards,
P R Dinesh
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Read-only /etc, machine-id with an overlay - journald failing

[Mantas Mikulėnas]

On Wed, Feb 26, 2020 at 11:59 AM Andreas Kempe 
wrote:

> Hello everyone,
>
> I'm working in a project with an embedded Linux system based on
> Openembedded using Systemd version 241 as our init process. We're
> using a read-only /etc. To facilitate development, we want to use a
> writeable overlay on /etc, but we ran into an issue.
>
> When we start, Systemd detects that there is no machine-id file
> present in /etc so it generates and mounts a /etc/machine-id. When our
> mount unit then applies the overlay on /etc, it hides the mounted
> file. Journald later fails to start because /etc/machine-id isn't
> visible through the overlay.
>
> At this point we're considering a number of workarounds, but I thought
> it worthwhile asking the experts before we go patching Systemd or
> similar.
>
> My gut feeling is that using overlays on /etc can't be that uncommon
> and it is likely PEBKAC on our end. Is there some canonical way of
> doing overlays with Systemd and we're screwing things up?
>

If you have an initramfs, consider setting up the /etc overlay there
instead.

-- 
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Read-only /etc, machine-id with an overlay - journald failing

[Andreas Kempe]

On Thu, Feb 27, 2020 at 10:04:37AM +0100, Jérémy ROSEN wrote:
> Le mer. 26 févr. 2020 à 10:59, Andreas Kempe  a
> écrit :
> 
> > Hello everyone,
> >
> > I'm working in a project with an embedded Linux system based on
> > Openembedded using Systemd version 241 as our init process. We're
> > using a read-only /etc. To facilitate development, we want to use a
> > writeable overlay on /etc, but we ran into an issue.
> >
> > When we start, Systemd detects that there is no machine-id file
> > present in /etc so it generates and mounts a /etc/machine-id. When our
> > mount unit then applies the overlay on /etc, it hides the mounted
> > file. Journald later fails to start because /etc/machine-id isn't
> > visible through the overlay.
> >
> > At this point we're considering a number of workarounds, but I thought
> > it worthwhile asking the experts before we go patching Systemd or
> > similar.
> >
> > My gut feeling is that using overlays on /etc can't be that uncommon
> > and it is likely PEBKAC on our end. Is there some canonical way of
> > doing overlays with Systemd and we're screwing things up?
> >
> > Thank you in advance for any help!
> > Cordially,
> > Andreas Kempe
>
> I had similar problems with a case of booting with the rootfs read-only and
> then becoming read-write later...
> 
> Basically systemd only checks for machine-id very early (before reading any
> config file) and does not deal well with /etc changing status...
> 

It is somewhat comforting knowing that others are seeing similar
issues. :)

> I did a complete analysis of what's going on, with a patch that improves
> the situation here : https://github.com/systemd/systemd/pull/14135
> I am not sure how to deal with it in your specific case.
> the simplest approch would be to mount your overlay in a initrd (or in a
> small script shell that is run before systemd and exec systemd as its last
> step)
> 

I was contemplating whether it could be acceptable having the same
static machine-id file pre-generated for all systems. I'm not 100% sure
what it's used for, TBH; would it be a really bad idea?

> My patch wouldn't really help in your case, but maybe you can "cheat" by
> having the underlying /etc/machine-id bein a symlink to the overlay
> directory... that could work.
> 

I had a look at your patch and as you said, it doesn't really solve
our use case. At the moment, we decided to remove the overlay from the
affected parts and simply require a new system image if one wants to
change /etc.

We were planning on having signed read-only overlays for configuration
in the future so I guess we'll have to investigate this further at a
later date.

Thank you for taking the time to respond!
Cordially,
Andreas Kempe
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Is there a way to uninstall the file system first and then stop all services?I

[www]

Dear all,


In systend, the order of power off is: first stop all services, and then 
uninstall the file system to oldroot. In special applications, if the systemd 
need to stop most services first (need to keep some services communicating with 
the outside world over the network), then uninstall the file system to oldroot, 
then perform special operations(update the system), and then stop other 
services, then turn off the system. What should I do if I want to achieve such 
a function?Are there any good suggestions?Or how do you modify the code for 
systemd?


Or is there a way to uninstall the file system first and then stop all services?


thanks,
Byron___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Read-only /etc, machine-id with an overlay - journald failing

[Jérémy ROSEN]

I had similar problems with a case of booting with the rootfs read-only and
then becoming read-write later...

Basically systemd only checks for machine-id very early (before reading any
config file) and does not deal well with /etc changing status...

I did a complete analysis of what's going on, with a patch that improves
the situation here : https://github.com/systemd/systemd/pull/14135
I am not sure how to deal with it in your specific case.
the simplest approch would be to mount your overlay in a initrd (or in a
small script shell that is run before systemd and exec systemd as its last
step)

My patch wouldn't really help in your case, but maybe you can "cheat" by
having the underlying /etc/machine-id bein a symlink to the overlay
directory... that could work.

Regards
Jeremy

Le mer. 26 févr. 2020 à 10:59, Andreas Kempe  a
écrit :

> Hello everyone,
>
> I'm working in a project with an embedded Linux system based on
> Openembedded using Systemd version 241 as our init process. We're
> using a read-only /etc. To facilitate development, we want to use a
> writeable overlay on /etc, but we ran into an issue.
>
> When we start, Systemd detects that there is no machine-id file
> present in /etc so it generates and mounts a /etc/machine-id. When our
> mount unit then applies the overlay on /etc, it hides the mounted
> file. Journald later fails to start because /etc/machine-id isn't
> visible through the overlay.
>
> At this point we're considering a number of workarounds, but I thought
> it worthwhile asking the experts before we go patching Systemd or
> similar.
>
> My gut feeling is that using overlays on /etc can't be that uncommon
> and it is likely PEBKAC on our end. Is there some canonical way of
> doing overlays with Systemd and we're screwing things up?
>
> Thank you in advance for any help!
> Cordially,
> Andreas Kempe
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>


-- 
[image: SMILE]  

20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique

[image: email] jeremy.ro...@smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]


[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel