[systemd-devel] Antw: /bin/systemctl vs /usr/bin/systemctl

[Ulrich Windl]

>>> Thomas Güttler  schrieb am 06.08.2019 um
16:37 in
Nachricht <3243dc34-4eec-e3a0-c6fd-491fdfcaf...@thomas-guettler.de>:
> I just realized that the location of systemctl varies across linux 
> distributions.
> 
> Ubuntu: /bin/systemctl
> SuSE: /usr/bin/systemctl

I guess it should be /sbin/systemctl ;-)

> 
> Which one do you think is better?
> 
> Regards,
>Thomas Güttler
> 
> -- 
> Thomas Guettler http://www.thomas-guettler.de/ 
> I am looking for feedback: https://github.com/guettli/programming-guidelines

> ___
> systemd-devel mailing list
> systemd-devel@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] startup hang at 'load/save random seed'

[Chris Murphy]

[   10.281769] fmac.local systemd[1]: Starting Update UTMP about
System Boot/Shutdown...
[   10.295504] fmac.local audit[806]: SYSTEM_BOOT pid=806 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='
comm="systemd-update-utmp" exe="/usr/lib/systemd/systemd-update-utmp"
hostname=? addr=? terminal=? res=success'
[   10.305289] fmac.local systemd[1]: Started Update UTMP about System
Boot/Shutdown.
[   10.305527] fmac.local audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=systemd-update-utmp comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
[   15.264423] fmac.local systemd[1]: systemd-rfkill.service: Succeeded.
[   15.268231] fmac.local audit[1]: SERVICE_STOP pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd"
hostname=? addr=? terminal=? res=success'
[  286.296649] fmac.local kernel: random: crng init done
[  286.301223] fmac.local kernel: random: 7 urandom warning(s) missed
due to ratelimiting
[  286.319857] fmac.local systemd[1]: Started Load/Save Random Seed.
[  286.322850] fmac.local audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=systemd-random-seed comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
[  286.323576] fmac.local systemd[1]: Reached target System Initialization.


I don't know why there's ratelimiting on urandom warnings, I have
printk.devkmsg=on

This also seems relevant.

[chris@fmac ~]$ sudo journalctl -b -o short-monotonic | grep -i seed
[8.870985] fmac.local systemd[1]: Starting Load/Save Random Seed...
[9.021818] fmac.local systemd-random-seed[619]: Kernel entropy
pool is not initialized yet, waiting until it is.
[  286.319857] fmac.local systemd[1]: Started Load/Save Random Seed.
[  286.322850] fmac.local audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=systemd-random-seed comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
[chris@fmac ~]$


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

[systemd-devel] startup hang at 'load/save random seed'

[Chris Murphy]

This is a new problem I'm seeing just today on Fedora Rawhide

5.3.0-0.rc3.git0.1.fc31.x86_64+debug
systemd-243~rc1-1.fc31.x86_64

The problem doesn't happen when reverting to
systemd-242-6.git9d34e79.fc31.x86_64

The hang lasts about 4-5 minutes, then boot proceeds.

Or if I head to early-debug shell and start typing, it almost
immediately clears up and boot proceeds.


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

Re: [systemd-devel] devilspie2 user service issues

[Matt Zagrabelny]

Thanks for the reply, Mantas!

On Tue, Aug 6, 2019 at 2:24 PM Mantas Mikulėnas  wrote:

> On Tue, Aug 6, 2019 at 10:08 PM Matt Zagrabelny 
> wrote:
>
>> Greetings,
>>
>> I am trying to write a service file for a tool called devilspie2.
>>
>> % systemctl --user cat devilspie.service
>> # /home/mzagrabe/.config/systemd/user/devilspie.service
>> [Unit]
>> Description=devilspie
>>
>> [Service]
>> ExecStart=/usr/bin/devilspie2
>>
>> [Install]
>> WantedBy=default.target
>>
>> which I enabled via:
>>
>> % systemctl --user enable devilspie.service
>>
>> but it is not successfully starting on boot/login:
>>
>
>
>> It looks like devilspie2 does not successfully start under a user systemd
>> instance due to "cannot open display".
>>
>> Since I log in via lightdm I am wondering what I am missing.
>>
>
>
> Well, "on boot/login" actually happens before the X display (Xorg) is
> launched. Even without linger mode, the --user default.target is started
> before the session processes themselves (it's done right after lightdm does
> the password check, more or less); at that point in time --user doesn't
> know your $DISPLAY or $XAUTHORITY yet, and there's no Xorg yet anyway –
> there's no display to open.
>
>
>>
>> Any ideas or pointers on how to properly start devilspie2 under a user
>> systemd instance?
>>
>
> Remove it from default.target and place a `systemctl --user start
> devilspie2` in your session's normal autostart files (e.g.
> ~/.config/autostart/*.desktop for GNOME).
>

Sure. I'm using that right now.

I thought it might be nice to just be able to have the distro provide the
service file and then the users could:

systemctl --user enable devilspie2

...but if there is no service that devilspie2 can wait for, then the
sessions "auto started" applications is an okay alternative.

Thanks again!

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

Re: [systemd-devel] devilspie2 user service issues

[Mantas Mikulėnas]

On Tue, Aug 6, 2019 at 10:08 PM Matt Zagrabelny  wrote:

> Greetings,
>
> I am trying to write a service file for a tool called devilspie2.
>
> % systemctl --user cat devilspie.service
> # /home/mzagrabe/.config/systemd/user/devilspie.service
> [Unit]
> Description=devilspie
>
> [Service]
> ExecStart=/usr/bin/devilspie2
>
> [Install]
> WantedBy=default.target
>
> which I enabled via:
>
> % systemctl --user enable devilspie.service
>
> but it is not successfully starting on boot/login:
>


> It looks like devilspie2 does not successfully start under a user systemd
> instance due to "cannot open display".
>
> Since I log in via lightdm I am wondering what I am missing.
>


Well, "on boot/login" actually happens before the X display (Xorg) is
launched. Even without linger mode, the --user default.target is started
before the session processes themselves (it's done right after lightdm does
the password check, more or less); at that point in time --user doesn't
know your $DISPLAY or $XAUTHORITY yet, and there's no Xorg yet anyway –
there's no display to open.


>
> Any ideas or pointers on how to properly start devilspie2 under a user
> systemd instance?
>

Remove it from default.target and place a `systemctl --user start
devilspie2` in your session's normal autostart files (e.g.
~/.config/autostart/*.desktop for GNOME).

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

[systemd-devel] devilspie2 user service issues

[Matt Zagrabelny]

Greetings,

I am trying to write a service file for a tool called devilspie2.

% systemctl --user cat devilspie.service
# /home/mzagrabe/.config/systemd/user/devilspie.service
[Unit]
Description=devilspie

[Service]
ExecStart=/usr/bin/devilspie2

[Install]
WantedBy=default.target

which I enabled via:

% systemctl --user enable devilspie.service

but it is not successfully starting on boot/login:

% systemctl --user status devilspie.service
● devilspie.service - devilspie
   Loaded: loaded (/home/mzagrabe/.config/systemd/user/devilspie.service;
enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2019-08-06 13:39:23 CDT;
3min 14s ago
  Process: 826 ExecStart=/usr/bin/devilspie2 (code=exited, status=1/FAILURE)
 Main PID: 826 (code=exited, status=1/FAILURE)

Aug 06 13:39:23 tombstone systemd[815]: Started devilspie.
Aug 06 13:39:23 tombstone systemd[815]: devilspie.service: Main process
exited, code=exited, status=1/FAILURE
Aug 06 13:39:23 tombstone systemd[815]: devilspie.service: Failed with
result 'exit-code'.

The actual reason isn't making it into the systemctl output, but does show
in the journal (under the "unknown" log entry [826]):

% journalctl --user --since '10 minutes ago'
[...]
Aug 06 13:39:23 tombstone systemd[815]: Started devilspie.
Aug 06 13:39:23 tombstone systemd[815]: Reached target Default.
Aug 06 13:39:23 tombstone systemd[815]: Startup finished in 27ms.
Aug 06 13:39:23 tombstone systemd[815]: Started D-Bus User Message Bus.
Aug 06 13:39:23 tombstone unknown[826]: cannot open display:
Aug 06 13:39:23 tombstone systemd[815]: devilspie.service: Main process
exited, code=exited, status=1/FAILURE
Aug 06 13:39:23 tombstone systemd[815]: devilspie.service: Failed with
result 'exit-code'.

So...

It looks like devilspie2 does not successfully start under a user systemd
instance due to "cannot open display".

Since I log in via lightdm I am wondering what I am missing.

Any ideas or pointers on how to properly start devilspie2 under a user
systemd instance?

Thanks for any help!

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

Re: [systemd-devel] /bin/systemctl vs /usr/bin/systemctl

[Kenneth Porter]

I wasn't aware of this change to the Filesystem Hierarchy Standard and 
looked it up. Here's the details on what happened:




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

Re: [systemd-devel] /bin/systemctl vs /usr/bin/systemctl

[Reindl Harald]

Am 06.08.19 um 16:37 schrieb Thomas Güttler:
> I just realized that the location of systemctl varies across linux
> distributions.
> 
> Ubuntu: /bin/systemctl
> SuSE: /usr/bin/systemctl
> 
> Which one do you think is better?

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

Re: [systemd-devel] /bin/systemctl vs /usr/bin/systemctl

[Andy Pieters]

On Tue, Aug 6, 2019 at 3:44 PM Thomas Güttler 
wrote:

> I just realized that the location of systemctl varies across linux
> distributions.
>
> Ubuntu: /bin/systemctl
> SuSE: /usr/bin/systemctl
>
> Which one do you think is better?
>

Obviously /usr/bin since /bin is a symbolic link to /usr/bin (or should be)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] /bin/systemctl vs /usr/bin/systemctl

[Thomas Güttler]

I just realized that the location of systemctl varies across linux 
distributions.

Ubuntu: /bin/systemctl
SuSE: /usr/bin/systemctl

Which one do you think is better?

Regards,
  Thomas Güttler

--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] lto issues

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 06, 2019 at 09:34:36AM +0200, Michael Biebl wrote:
> Am Di., 6. Aug. 2019 um 09:26 Uhr schrieb Zbigniew Jędrzejewski-Szmek
> :
> >
> > On Sat, Aug 03, 2019 at 07:03:47PM +0200, Michael Biebl wrote:
> > > Hi,
> > >
> > > today I tried compiling systemd v242 (on Debian sid) once using lto
> > > (-Db_lto=true) and once without lto (-Db_lto=false).
> > >
> > > The lto build took approximately twice as long on my laptop (using
> > > dpkg-buildpackage, which introduces a bit of overhead):
> > >
> > > lto:
> > > real 11m22,605s
> > > user 37m9,675s
> > > sys 2m51,041s
> > >
> > > nolto:
> > > real 6m35,615s
> > > user 18m51,782s
> > > sys 2m12,934s
> > >
> > > That's kinda expected. What suprised me though is that using lto
> > > produced larger binaries:
> >
> > I built systemd in F31 (-Doptimization=2 -Db_lto=true/false, and I saw
> > a big increase in binary sizes *before stripping*. After stripping,
> > binaries with lto=true are smaller:
> >
> > $ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
> >   7116384 Aug  6 09:08 build-rawhide/systemd*
> >  11951256 Aug  6 09:07 build-rawhide/src/shared/libsystemd-shared-243.so*
> >   1594912 Aug  6 09:12 build-rawhide-lto/systemd*
> >   3167096 Aug  6 09:11 
> > build-rawhide-lto/src/shared/libsystemd-shared-243.so*
> > $ strip build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
> > $ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
> >   1439640 Aug  6 09:19 build-rawhide/systemd*
> >   2806456 Aug  6 09:19 build-rawhide/src/shared/libsystemd-shared-243.so*
> >   1370008 Aug  6 09:19 build-rawhide-lto/systemd*
> >   2806288 Aug  6 09:19 
> > build-rawhide-lto/src/shared/libsystemd-shared-243.so*
> 
> 
> The sizes I posted i.e. the debdiff is after stripping.
> 
> gcc --version
> gcc (Debian 8.3.0-19) 8.3.0
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> ld --version
> GNU ld (GNU Binutils for Debian) 2.32.51.20190727
> Copyright (C) 2019 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> 
> So with the toolchain I have, mostly has downsides. The only benefit
> it seems to have is that it optimizes unnecessary library dependencies
> away (see how the udev subpackage does not depend on libcap2 (>=
> 1:2.10), libidn2-0 (>= 0.6)

In Fedora, lto seems to have good returns. The final package size was
~10% smaller. We disabled it for a while because there were linking
failures, but I think it's all resolved now.

I forgot to mention. In my test:
gcc-9.1.1-2.fc31.1.x86_64
binutils-2.32-19.fc31.x86_64

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

Re: [systemd-devel] lto issues

[Lennart Poettering]

On Sa, 03.08.19 19:03, Michael Biebl (mbi...@gmail.com) wrote:

> Hi,
>
> today I tried compiling systemd v242 (on Debian sid) once using lto
> (-Db_lto=true) and once without lto (-Db_lto=false).
>
> The lto build took approximately twice as long on my laptop (using
> dpkg-buildpackage, which introduces a bit of overhead):
>
> lto:
> real 11m22,605s
> user 37m9,675s
> sys 2m51,041s
>
> nolto:
> real 6m35,615s
> user 18m51,782s
> sys 2m12,934s
>
> That's kinda expected. What suprised me though is that using lto
> produced larger binaries:

Have you pinged the toolchain maintainers of your distro about this?

Note that systemd doesn't really do much lto stuff on its own anymore,
it's now entirely between meson and your toolchain afaics.

Lennart

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

Re: [systemd-devel] service fails to use the latest value of the slice

[Lennart Poettering]

On Di, 06.08.19 08:58, TARANA, YASHASHVI (yashashvi.tar...@hpe.com) wrote:

> Hi Lennart,
>
> Thank you for getting back. I just subscribed to the systemd-devel mailing 
> list and hence I'm resending the mail.
>
> We were following below article to get around the situation where a process 
> fails to get realtime priority on a system once the CPUAccounting is enabled.
> https://access.redhat.com/articles/3696121
>
> It suggests to create your own slice and use it for your service.
>
> We would like to handle a situation where there are 2 such slices (A.slice & 
> B.slice, created by different applications) on the system.
>
> Sample: test.service
>   [Service]
>   ExecStart=/root/test start
>   ExecStop=/root/test stop
>   Type=oneshot
>   RemainAfterExit=yes
>
> Here, the binary at ExecStart (test) requires realtime priority.
>
> Scenario 1:
> ---
> Steps to Reproduce: 1. Suppose I have 2 slices, A.slice
> (cpu.rt_runtime_us value = 95) and B.slice (cpu.rt_runtime_us
> value = 0) 2. Currently the service test.service is attached to
> A.slice 3. Now I changed cpu.rt_runtime_us values for these slices:
> A.slice to 0 and B.slice to 95 (The values of A.slice and
> B.slice have been exchanged) 4. When I stop and start the service,
> binary at ExecStart determines that B.slice is the eligible slice
> and it updates the slice name in the configuration files and in
> drop-ins.  5. Updated slice information not reflected when start the
> binary and the start fails to set "realtime" priority.  6. Restart
> of the same service again works fine and attaches to correct slice
> (B.slice).

systemd does not support moving services between slices while they are
started. Currently, the cgroup is determined when the service is
started and then says unmodified until the service goes down.

(The kernel doesn't really support migrating processes between cgroups
that well either, the various counters do not fully get updated as one
might expect. The idea is generally that you change cgroup attributes
dynamically, and do not change cgroups/process membership after
initialization.)

> To work around the above problem in scenario 1 , I followed the below steps 
> after step 3 above.
>
> 4. When I stop and start service again, the binary at Execstart determines 
> the right slice( in this case, B.slice) and pushes its pid to B.slice tasks 
> file(/sys/fs/cgroup/cpu,cpuacct/B.slice/tasks) in addition to updating the 
> drop-ins.
> 5. The test service start successfully now but systemctl status
> test.service still shows that test.service is attached to the old
> slice (A.slice), although its pid is part of B.slice now.

Do not write directly to the "tasks" file. If systemd is your PID 1
then it owns the tree of all controllers it manages, and that includes
process membership. It's only OK to manage your own cgroup tree and
process membership therein if you registered a delegated subtree.

https://systemd.io/CGROUP_DELEGATION.html#delegation

But if you alter the process membership in the cgroups systems itself
manages you are basically on your own, it's simply not supported.

Lennart

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

Re: [systemd-devel] service fails to use the latest value of the slice

[TARANA, YASHASHVI]

Hi Lennart,

Thank you for getting back. I just subscribed to the systemd-devel mailing list 
and hence I'm resending the mail.

We were following below article to get around the situation where a process 
fails to get realtime priority on a system once the CPUAccounting is enabled.
https://access.redhat.com/articles/3696121

It suggests to create your own slice and use it for your service.

We would like to handle a situation where there are 2 such slices (A.slice & 
B.slice, created by different applications) on the system. 

Sample: test.service
[Service]
ExecStart=/root/test start
ExecStop=/root/test stop
Type=oneshot
RemainAfterExit=yes

Here, the binary at ExecStart (test) requires realtime priority.

Scenario 1:
---
Steps to Reproduce:
1. Suppose I have 2 slices, A.slice (cpu.rt_runtime_us value = 95) and 
B.slice (cpu.rt_runtime_us  value = 0) 2. Currently the service test.service is 
attached to A.slice 3. Now I changed cpu.rt_runtime_us values for these slices: 
 A.slice to 0 and B.slice to 95 (The values of A.slice and B.slice have 
been exchanged) 4. When I stop and start the service, binary at ExecStart 
determines that B.slice is the eligible slice and it updates the slice name in 
the configuration files and in drop-ins.
5. Updated slice information not reflected when start the binary and the start 
fails to set "realtime" priority.
6. Restart of the same service again works fine and attaches to correct slice 
(B.slice).

Is this expected behavior? Is there a way to reload the systemd configuration 
during runtime (i.e during systemctl start <>) ?

Scenario 2:
--

To work around the above problem in scenario 1 , I followed the below steps 
after step 3 above.

4. When I stop and start service again, the binary at Execstart determines the 
right slice( in this case, B.slice) and pushes its pid to B.slice tasks 
file(/sys/fs/cgroup/cpu,cpuacct/B.slice/tasks) in addition to updating the 
drop-ins.
5. The test service start successfully now but systemctl status test.service 
still shows that test.service is attached to the old slice (A.slice), although 
its pid is part of B.slice now.

I have below queries as part of Scenario 2:
  -  Is there a way to update the slice information for a service at runtime? 
Or by executing some command ?
 - Will it impact the CPUAccounting feature (which is enabled for both slices), 
since the pid is part of different slice(B.slice), but service still reflects 
A.slice?

Regards,
Yashashvi

-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net] 
Sent: Thursday, July 25, 2019 10:45 PM
To: Tiwari, Hari Sahaya 
Cc: systemd-devel@lists.freedesktop.org; TARANA, YASHASHVI 

Subject: Re: [systemd-devel] service fails to use the latest value of the slice

On Do, 25.07.19 13:02, Tiwari, Hari Sahaya (hari-sahaya.tiw...@hpe.com) wrote:

> Hello,
> I have one query on the behaviour I am overserving with systemd service.
>
> Below are the contents of service file,
>
> # cat /usr/lib/systemd/system/qs.service
> [Unit]
> Description=init script
> After=network.target
>
> [Service]
> ExecStartPre=/bin/sh /usr/local/cmcluster/bin/realtimeslice.sh -s 
> /usr/lib/systemd/system/qs.service
> ExecStart=/usr/local/qs/bin/qs
> Type=simple
>
> [Install]
> WantedBy=multi-user.target
>
> What realtimeslice.sh does is to identify a slice having RT quantum
> (cpu.rt_runtime_us) as 95.  Once the slice is identified the 
> service attaches the binary mentioned in ExecStart to that slice.
> This is done because binary(/usr/local/qs/bin/qs) tries to set 
> realtime priority.

I have trouble understanding this. I think there's some misconception about 
what's systemd's slice concept is about.

Also note: systemd owns the cgroup tree. If you make changes to the cgroup tree 
you are on your own, you are not supposed to, except if you asked four own 
delegated subtree.

This means: attaching a process systemd manages for you to a different cgroup 
with your own code is not supported, you are on your own.

That said, you can let systemd create cgroups and then adjust the attributes 
that systemd doesn't manager yourself, such as the RT attributes. For that use 
an ExecStartPre= that just sets these attributes, and maybe make sure With 
CPUWeight=100 that you actually get properly added to the "cpu" hierarchy...

Lennart

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

Re: [systemd-devel] lto issues

[Michael Biebl]

Am Di., 6. Aug. 2019 um 09:26 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:
>
> On Sat, Aug 03, 2019 at 07:03:47PM +0200, Michael Biebl wrote:
> > Hi,
> >
> > today I tried compiling systemd v242 (on Debian sid) once using lto
> > (-Db_lto=true) and once without lto (-Db_lto=false).
> >
> > The lto build took approximately twice as long on my laptop (using
> > dpkg-buildpackage, which introduces a bit of overhead):
> >
> > lto:
> > real 11m22,605s
> > user 37m9,675s
> > sys 2m51,041s
> >
> > nolto:
> > real 6m35,615s
> > user 18m51,782s
> > sys 2m12,934s
> >
> > That's kinda expected. What suprised me though is that using lto
> > produced larger binaries:
>
> I built systemd in F31 (-Doptimization=2 -Db_lto=true/false, and I saw
> a big increase in binary sizes *before stripping*. After stripping,
> binaries with lto=true are smaller:
>
> $ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
>   7116384 Aug  6 09:08 build-rawhide/systemd*
>  11951256 Aug  6 09:07 build-rawhide/src/shared/libsystemd-shared-243.so*
>   1594912 Aug  6 09:12 build-rawhide-lto/systemd*
>   3167096 Aug  6 09:11 build-rawhide-lto/src/shared/libsystemd-shared-243.so*
> $ strip build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
> $ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
>   1439640 Aug  6 09:19 build-rawhide/systemd*
>   2806456 Aug  6 09:19 build-rawhide/src/shared/libsystemd-shared-243.so*
>   1370008 Aug  6 09:19 build-rawhide-lto/systemd*
>   2806288 Aug  6 09:19 build-rawhide-lto/src/shared/libsystemd-shared-243.so*


The sizes I posted i.e. the debdiff is after stripping.

gcc --version
gcc (Debian 8.3.0-19) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ld --version
GNU ld (GNU Binutils for Debian) 2.32.51.20190727
Copyright (C) 2019 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.

So with the toolchain I have, mostly has downsides. The only benefit
it seems to have is that it optimizes unnecessary library dependencies
away (see how the udev subpackage does not depend on libcap2 (>=
1:2.10), libidn2-0 (>= 0.6)



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] lto issues

[Zbigniew Jędrzejewski-Szmek]

On Sat, Aug 03, 2019 at 07:03:47PM +0200, Michael Biebl wrote:
> Hi,
> 
> today I tried compiling systemd v242 (on Debian sid) once using lto
> (-Db_lto=true) and once without lto (-Db_lto=false).
> 
> The lto build took approximately twice as long on my laptop (using
> dpkg-buildpackage, which introduces a bit of overhead):
> 
> lto:
> real 11m22,605s
> user 37m9,675s
> sys 2m51,041s
> 
> nolto:
> real 6m35,615s
> user 18m51,782s
> sys 2m12,934s
> 
> That's kinda expected. What suprised me though is that using lto
> produced larger binaries:

I built systemd in F31 (-Doptimization=2 -Db_lto=true/false, and I saw
a big increase in binary sizes *before stripping*. After stripping,
binaries with lto=true are smaller:

$ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
  7116384 Aug  6 09:08 build-rawhide/systemd*
 11951256 Aug  6 09:07 build-rawhide/src/shared/libsystemd-shared-243.so*
  1594912 Aug  6 09:12 build-rawhide-lto/systemd*
  3167096 Aug  6 09:11 build-rawhide-lto/src/shared/libsystemd-shared-243.so*
$ strip build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}
$ ls -l build-rawhide{,-lto}/{systemd,src/shared/libsystemd-shared-243.so}  
  1439640 Aug  6 09:19 build-rawhide/systemd*
  2806456 Aug  6 09:19 build-rawhide/src/shared/libsystemd-shared-243.so*
  1370008 Aug  6 09:19 build-rawhide-lto/systemd*
  2806288 Aug  6 09:19 build-rawhide-lto/src/shared/libsystemd-shared-243.so*

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