Re: [systemd-devel] Minimize systemd for kdump's initramfs

2020-02-24 Thread Zbigniew Jędrzejewski-Szmek 
On Tue, Feb 25, 2020 at 01:12:08PM +0800, Kairui Song wrote:
> On Fri, Jan 3, 2020 at 3:23 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> > On Fri, Jan 03, 2020 at 11:48:53AM +0800, Dave Young wrote:
> > > On 01/03/20 at 11:45am, Dave Young wrote:
> > > > On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote:
> > > > > > Some component, like Systemd, have grown by a lot, here is a list of
> > > > > > the size of part of binaries along with the binaries they required 
> > > > > > in
> > > > > > F31:
> > > > > > /root/image/bin/systemctl
> > > > > > 20M .
> > > > > > /root/image/usr/bin/systemctl
> > > > > > 20M .
> > > > > > /root/image/usr/bin/systemd-cgls
> > > > > > 20M .
> > > > > > /root/image/usr/bin/systemd-escape
> > > > > > 20M .
> > > > > > /root/image/usr/bin/systemd-run
> > > > > > 20M .
> > > > > > ...
> > > > > >
> > > > > > There are overlays between the libraries they used so when installed
> > > > > > into the initramfs, the total size didn't go too big yet. But we can
> > > > > > see the size of systemd binary and libraries it used is much bigger
> > > > > > than others.
> > > > >
> > > > > All systemd binaries will mostly link to the same libraries (because
> > > > > they link to a private shared library, which links to various other
> > > > > shared libraries). So this "20M" will be repeated over and over, but
> > > > > it's the same dependencies.
> > > > >
> > > > > While we'd all prefer for this to be smaller, 20M should is actually
> > > > > not that much...
> > > > >
> > > > > > And as a compare, from version 219 to 243, systemd's library
> > > > > > dependency increased a lot:
> > > > > > (v219 is 5M in total, v243 is 20M in total)
> > > > >
> > > > > This is slightly misleading. Code was moved from individual binaries
> > > > > to libsystemd-shared-nnn.so, so if you look at the deps of just a 
> > > > > single
> > > > > binary, you'll see many more deps (because libsystemd-shared-nnn.so 
> > > > > has
> > > > > more deps). But the total number of deps when summed over all binaries
> > > > > grew much less. A more useful measure would be the size with deps 
> > > > > summed
> > > > > over all systemd binaries that are installed into your image in v219 
> > > > > and
> > > > > v243.
> > > > >
> > > >
> > > > I vaguely remember the size increased before due to linking with libidn2
> > > > previously, so those libraries contribute a lot.
> > > >
> > > > Does every systemd binary depend on all libraries? Or each of the
> > > > systemd binary only depends on those libs when really needed?
> > >
> > > For example if I do not need journalctl, then I can drop journalctl and
> > > those libraries specific for journalctl?
> >
> > It's using standard shared object linking, so yeah, for anything which
> > libsystemd-shared-nnn.so links to, "every systemd binary depend[s] on
> > all libraries", in the sense that the runtime linker will fail to start
> > the executable if any of the libraries are missing.
> >
> 
> Hi, it has been a while since last discuss update, but a second
> thought about the libsystemd-shared-nnn.so problem:
> 
> Now each systemd executable depends on libsystemd-shared-nnn.so, which
> then depend on a lot of things. In older version (eg. version 219),
> each individual systemd executable have it's own dependency, that make
> thing much cleaner for special usages like kdump.
> 
> I'm not sure what is the purpose of this change, could there be any
> work be done to minimize the lib dependency of each systemd binary?

libsystemd-shared-nnn.so holds code used in multiple executables. This
means that if the full suite is installed, shared code is present in
just one copy, and the total footprint of the installation is minimized
(disk, loading time, rss). OTOH, the footprint of installing just a
single executable is unfortunately increased. Our thinking was that
installing many executables is much more common (pretty even a minimal
system with systemd has at least ~30 systemd binaries), so it makes
sense to prioritize that.

See https://github.com/systemd/systemd/pull/3516 for the discussion
of the space savings back when this was originally done. Now we have
many more binaries (and even more shared code since integration of
various components is increasing...), so I expect the savings to
be even bigger.

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

Re: [systemd-devel] Minimize systemd for kdump's initramfs

2020-02-24 Thread Kairui Song 
On Tue, Feb 25, 2020 at 3:07 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Feb 25, 2020 at 01:12:08PM +0800, Kairui Song wrote:
> > On Fri, Jan 3, 2020 at 3:23 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > > On Fri, Jan 03, 2020 at 11:48:53AM +0800, Dave Young wrote:
> > > > On 01/03/20 at 11:45am, Dave Young wrote:
> > > > > On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote:
> > > > > > > Some component, like Systemd, have grown by a lot, here is a list 
> > > > > > > of
> > > > > > > the size of part of binaries along with the binaries they 
> > > > > > > required in
> > > > > > > F31:
> > > > > > > /root/image/bin/systemctl
> > > > > > > 20M .
> > > > > > > /root/image/usr/bin/systemctl
> > > > > > > 20M .
> > > > > > > /root/image/usr/bin/systemd-cgls
> > > > > > > 20M .
> > > > > > > /root/image/usr/bin/systemd-escape
> > > > > > > 20M .
> > > > > > > /root/image/usr/bin/systemd-run
> > > > > > > 20M .
> > > > > > > ...
> > > > > > >
> > > > > > > There are overlays between the libraries they used so when 
> > > > > > > installed
> > > > > > > into the initramfs, the total size didn't go too big yet. But we 
> > > > > > > can
> > > > > > > see the size of systemd binary and libraries it used is much 
> > > > > > > bigger
> > > > > > > than others.
> > > > > >
> > > > > > All systemd binaries will mostly link to the same libraries (because
> > > > > > they link to a private shared library, which links to various other
> > > > > > shared libraries). So this "20M" will be repeated over and over, but
> > > > > > it's the same dependencies.
> > > > > >
> > > > > > While we'd all prefer for this to be smaller, 20M should is actually
> > > > > > not that much...
> > > > > >
> > > > > > > And as a compare, from version 219 to 243, systemd's library
> > > > > > > dependency increased a lot:
> > > > > > > (v219 is 5M in total, v243 is 20M in total)
> > > > > >
> > > > > > This is slightly misleading. Code was moved from individual binaries
> > > > > > to libsystemd-shared-nnn.so, so if you look at the deps of just a 
> > > > > > single
> > > > > > binary, you'll see many more deps (because libsystemd-shared-nnn.so 
> > > > > > has
> > > > > > more deps). But the total number of deps when summed over all 
> > > > > > binaries
> > > > > > grew much less. A more useful measure would be the size with deps 
> > > > > > summed
> > > > > > over all systemd binaries that are installed into your image in 
> > > > > > v219 and
> > > > > > v243.
> > > > > >
> > > > >
> > > > > I vaguely remember the size increased before due to linking with 
> > > > > libidn2
> > > > > previously, so those libraries contribute a lot.
> > > > >
> > > > > Does every systemd binary depend on all libraries? Or each of the
> > > > > systemd binary only depends on those libs when really needed?
> > > >
> > > > For example if I do not need journalctl, then I can drop journalctl and
> > > > those libraries specific for journalctl?
> > >
> > > It's using standard shared object linking, so yeah, for anything which
> > > libsystemd-shared-nnn.so links to, "every systemd binary depend[s] on
> > > all libraries", in the sense that the runtime linker will fail to start
> > > the executable if any of the libraries are missing.
> > >
> >
> > Hi, it has been a while since last discuss update, but a second
> > thought about the libsystemd-shared-nnn.so problem:
> >
> > Now each systemd executable depends on libsystemd-shared-nnn.so, which
> > then depend on a lot of things. In older version (eg. version 219),
> > each individual systemd executable have it's own dependency, that make
> > thing much cleaner for special usages like kdump.
> >
> > I'm not sure what is the purpose of this change, could there be any
> > work be done to minimize the lib dependency of each systemd binary?
>
> libsystemd-shared-nnn.so holds code used in multiple executables. This
> means that if the full suite is installed, shared code is present in
> just one copy, and the total footprint of the installation is minimized
> (disk, loading time, rss). OTOH, the footprint of installing just a
> single executable is unfortunately increased. Our thinking was that
> installing many executables is much more common (pretty even a minimal
> system with systemd has at least ~30 systemd binaries), so it makes
> sense to prioritize that.

Yes, that's very true, this kind of usage (single binary intallation)
is quite rare.

>
> See https://github.com/systemd/systemd/pull/3516 for the discussion
> of the space savings back when this was originally done. Now we have
> many more binaries (and even more shared code since integration of
> various components is increasing...), so I expect the savings to
> be even bigger.
>
> Zbyszek
>

Thanks for the info, the PR reference is very useful. Will check it
for more background knowledge.

-- 
Best Regards,
Kairui Song

Re: [systemd-devel] Minimize systemd for kdump's initramfs

2020-02-24 Thread Kairui Song 
On Fri, Jan 3, 2020 at 3:23 PM Zbigniew Jędrzejewski-Szmek
 wrote:
> On Fri, Jan 03, 2020 at 11:48:53AM +0800, Dave Young wrote:
> > On 01/03/20 at 11:45am, Dave Young wrote:
> > > On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote:
> > > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote:
> > > > > Some component, like Systemd, have grown by a lot, here is a list of
> > > > > the size of part of binaries along with the binaries they required in
> > > > > F31:
> > > > > /root/image/bin/systemctl
> > > > > 20M .
> > > > > /root/image/usr/bin/systemctl
> > > > > 20M .
> > > > > /root/image/usr/bin/systemd-cgls
> > > > > 20M .
> > > > > /root/image/usr/bin/systemd-escape
> > > > > 20M .
> > > > > /root/image/usr/bin/systemd-run
> > > > > 20M .
> > > > > ...
> > > > >
> > > > > There are overlays between the libraries they used so when installed
> > > > > into the initramfs, the total size didn't go too big yet. But we can
> > > > > see the size of systemd binary and libraries it used is much bigger
> > > > > than others.
> > > >
> > > > All systemd binaries will mostly link to the same libraries (because
> > > > they link to a private shared library, which links to various other
> > > > shared libraries). So this "20M" will be repeated over and over, but
> > > > it's the same dependencies.
> > > >
> > > > While we'd all prefer for this to be smaller, 20M should is actually
> > > > not that much...
> > > >
> > > > > And as a compare, from version 219 to 243, systemd's library
> > > > > dependency increased a lot:
> > > > > (v219 is 5M in total, v243 is 20M in total)
> > > >
> > > > This is slightly misleading. Code was moved from individual binaries
> > > > to libsystemd-shared-nnn.so, so if you look at the deps of just a single
> > > > binary, you'll see many more deps (because libsystemd-shared-nnn.so has
> > > > more deps). But the total number of deps when summed over all binaries
> > > > grew much less. A more useful measure would be the size with deps summed
> > > > over all systemd binaries that are installed into your image in v219 and
> > > > v243.
> > > >
> > >
> > > I vaguely remember the size increased before due to linking with libidn2
> > > previously, so those libraries contribute a lot.
> > >
> > > Does every systemd binary depend on all libraries? Or each of the
> > > systemd binary only depends on those libs when really needed?
> >
> > For example if I do not need journalctl, then I can drop journalctl and
> > those libraries specific for journalctl?
>
> It's using standard shared object linking, so yeah, for anything which
> libsystemd-shared-nnn.so links to, "every systemd binary depend[s] on
> all libraries", in the sense that the runtime linker will fail to start
> the executable if any of the libraries are missing.
>

Hi, it has been a while since last discuss update, but a second
thought about the libsystemd-shared-nnn.so problem:

Now each systemd executable depends on libsystemd-shared-nnn.so, which
then depend on a lot of things. In older version (eg. version 219),
each individual systemd executable have it's own dependency, that make
thing much cleaner for special usages like kdump.

I'm not sure what is the purpose of this change, could there be any
work be done to minimize the lib dependency of each systemd binary?


--
Best Regards,
Kairui Song

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

[systemd-devel] Infinite loop at startup on var fsck failure

2020-02-24 Thread Vito Caputo 
Hello list,

Today I experienced an unclean shutdown due to battery dying unexpectedly,
and it left my /var in a state requiring a manual fsck to repair errors.

The normal startup process failed and dropped me to a rescue shell after
asking for my root password.  But I was unable to immediately run fsck
manually, because systemd was endlessly trying to fsck /var.

Stopping, disabling, masking, none of those obvious options to prevent
'systemd-fsck@dev-mapper-ssd\x2var.service' from starting again in
this loop worked, and I don't recall seeing any guidance in the journal on
what was the appropriate course of action.

Eventually I resorted to `systemctl emergency` which seemed to get things
quieted down enough for me to run the fsck manually.

All's well that ends well, but what an *awful* user experience.  Is this
really how things are supposed to play out when a fsck on something like
/var fails?  I was very much left in the dark at a root shell with systemd
pointlessly spinning its wheels hopelessly running the same fsck
repeatedly.

It's possible this is already better in a newer systemd release, but I just
wanted to document this experience in case it's an area that still needs
improvement.

This is on an old release (v232) in Debian 9.11 amd64.

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

Re: [systemd-devel] systemd kills user's scopes/sessions before shutdown service

2020-02-24 Thread Kamal Rathi 
Hi team,

Any suggestions for the issue.

Regards,
Kamal Rathi


On Fri, Feb 21, 2020 at 8:09 AM Kamal Rathi  wrote:

> Hi Team,
>
> The suggestion offered for design stop service was successfully
> integrated but the issue is still same as the User.slices still got kill.
>
> I am pasting my service here
>
> grep -v ^# /etc/systemd/system/stop.service
> [Unit]
> Description=Service to auto stop the EBS application
> After=user.slice
> [Service]
> ExecStart=
> ExecStop=/startdb/stop/stop.sh
> RemainAfterExit=true
> [Install]
> WantedBy=user.slice
>
>
> Now service runs but still issue is that I want my service to stop the
> processes not systemd
>
> Issue might be similar like this
>
> https://lists.freedesktop.org/archives/systemd-devel/2016-November/037916.html
>
>
> Regards,
> Kamal
>
> On Thu, Feb 20, 2020 at 10:15 PM Kamal Rathi  wrote:
>
>> Hi Lennart,
>>
>> THe suggestion you have offered for design stop service was successfully
>> integrated but the issue is still same as the User session in User.slice
>> still got kill.
>>
>> I am pasting my service here
>>
>>
>> grep -v ^# /etc/systemd/system/stop.service
>> [Unit]
>> Description=Service to auto stop the EBS application
>> After=-.slice system.slice user.slice
>> [Service]
>> ExecStart=
>> ExecStop=/startdb/stop/stop.sh
>> RemainAfterExit=true
>> [Install]
>> WantedBy=user.slice
>>
>>
>> Now service runs but still issue is that I want my service to stop the
>> processes not systemd
>>
>> Issue might be similar like this
>>
>> https://lists.freedesktop.org/archives/systemd-devel/2016-November/037916.html
>>
>>
>> Regards,
>> Kamal
>>
>>
>>
>> On Thu, Jan 2, 2020 at 6:34 PM Lennart Poettering 
>> wrote:
>>
>>> On Di, 31.12.19 11:04, Kamal Rathi (kr30ap...@gmail.com) wrote:
>>>
>>> > Hi Git-Hub Mailing List,
>>> >
>>> > I am designing a stop service which has to be run before the kill of
>>> user's
>>> > scope / session .
>>>
>>> How could this work? Users can log out or be terminated any time,
>>> i.e. their scope/sessions can go away during runtime all the time, and
>>> they won't tell us beforehand about it beforehand, hence how could we
>>> run something beforehand?
>>>
>>> Lennart
>>>
>>> --
>>> Lennart Poettering, Berlin
>>>
>>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd stop info

2020-02-24 Thread Reindl Harald 



Am 24.02.20 um 12:03 schrieb Bao Nguyen:
> Hi everyone,
> 
> When rebooting the system, I notice systemd print out:
> 
> [[0;32m OK [0m] Stopped Account Service
> 
> What do 0;32m and 0m means?

https://misc.flogisoft.com/bash/tip_colors_and_formatting
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd stop info

2020-02-24 Thread Mantas Mikulėnas 
On Mon, Feb 24, 2020 at 1:04 PM Bao Nguyen  wrote:

> Hi everyone,
>
> When rebooting the system, I notice systemd print out:
>
> [[0;32m OK [0m] Stopped Account Service
>
> What do 0;32m and 0m means?
>

With invisible characters included, "ESC [ <…> m" is an ANSI/ECMA-48 "SGR"
text formatting code
 – mostly
used for changing text colors.

Parameter 0 means "reset all formatting", 32 selects foreground color
(green).

It is unusual to see this in Linux console – normally the code should
remain invisible and just make text green.

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

[systemd-devel] Systemd stop info

2020-02-24 Thread Bao Nguyen 
Hi everyone,

When rebooting the system, I notice systemd print out:

[[0;32m OK [0m] Stopped Account Service

What do 0;32m and 0m means?

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