Re: [systemd-devel] systemd-readahead and often used applications

2013-04-17 Thread Lennart Poettering
On Sat, 13.04.13 13:27, Reindl Harald (h.rei...@thelounge.net) wrote:

 Hi
 
 as far as i understand systemd-readahead is catching what is
 loaded directly due boot and 10 seconds after, well that's fine

I changed this to 30 now, btw, since 10s turned out to be too short on
many systems.

 but is there a possibility to feed it with additional applications?
 
 example of the real life here:
 
  * the machine get powered on in the morning
  * due this sitting in the kitchen with a coffee
  * after that login in KDE, plasma and kopete are started
  * finally Thunderbird and Firefox are started
  * mostly Eclipse is the next
  * the machine has 16 GB RAM
 
 it would make pretty much sense that Thunderbird, Firefox and
 so on are pre-loaded or at least their libraries after the
 login-manager appears to use the time between boot and login

As mentioned you can change the time readahead keeps running. In the
long run I think the right approach for the desktops is to simply
re-login after a reboot everybody who was logged in before it, and then
activate the screen lock by default for them.

The other thing I'd like to make happen is that we can collect
username/password when we prompt for the HDD key, and use that first for
decrypting the harddisk and then for authenticating the user. THis would
require us to keep HDD passphrase and user passphrase in sync, but that
should be totally doable and is probably deseriable anyway...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-15 Thread Kok, Auke-jan H
On Sun, Apr 14, 2013 at 2:15 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 14.04.2013 23:06, schrieb Kok:

 [Unit]
 Description=Adaptive readahead daemon

 [Service]
 ExecStart=/usr/sbin/preload -f 1 -l 
 Restart=always
 RestartSec=1
 Nice=19
 IOSchedulingClass=3

 [Install]
 WantedBy=multi-user.target
 

 thanks, i will give it a try
 why not Type=forking?

 in my expierience a service works with simple/forking and only
 one of them while i must say my low-level understanding may
 not be enouh to realize what to use.

The daemon doesn't need to do extra work to fork, and systemd won't
need to do all the work associated with tracking a forked process -
it's a lot less work, thus more efficient, and actually more robust.

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


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-15 Thread Reindl Harald


Am 15.04.2013 19:53, schrieb Kok:
 thanks, i will give it a try
 why not Type=forking?

 in my expierience a service works with simple/forking and only
 one of them while i must say my low-level understanding may
 not be enouh to realize what to use.
 
 The daemon doesn't need to do extra work to fork, and systemd won't
 need to do all the work associated with tracking a forked process -
 it's a lot less work, thus more efficient, and actually more robust

hi

does this mean in recent systemd-versions it is no longer needed
to use Type=forking at all while it was a must for some servcies
in early versions?

i thougt a service which forks by itself and not defined
with Type=forking is killed after the PID changed because
systemd thinks the main-PID died

[root@srv-rhsoft:~]$ systemctl status preload.service
preload.service - Adaptive readahead daemon
   Loaded: loaded (/etc/systemd/system/preload.service; enabled)
   Active: active (running) since Mo 2013-04-15 19:55:10 CEST; 1min 45s ago
  Process: 795 ExecStart=/usr/sbin/preload --verbose 1 (code=exited, 
status=0/SUCCESS)
 Main PID: 801 (preload)
   CGroup: name=systemd:/system/preload.service
   └─801 /usr/sbin/preload --verbose 1



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-15 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Apr 15, 2013 at 07:59:51PM +0200, Reindl Harald wrote:
 
 
 Am 15.04.2013 19:53, schrieb Kok:
  thanks, i will give it a try
  why not Type=forking?
 
  in my expierience a service works with simple/forking and only
  one of them while i must say my low-level understanding may
  not be enouh to realize what to use.
  
  The daemon doesn't need to do extra work to fork, and systemd won't
  need to do all the work associated with tracking a forked process -
  it's a lot less work, thus more efficient, and actually more robust
 
 hi
 
 does this mean in recent systemd-versions it is no longer needed
 to use Type=forking at all while it was a must for some servcies
 in early versions?
It's still necessary, if the service forks. But if the service *can*
be instructed not to fork, then it's beneficial to do so.

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


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-15 Thread Reindl Harald


Am 15.04.2013 20:50, schrieb Zbigniew Jędrzejewski-Szmek:
 On Mon, Apr 15, 2013 at 07:59:51PM +0200, Reindl Harald wrote:


 Am 15.04.2013 19:53, schrieb Kok:
 thanks, i will give it a try
 why not Type=forking?

 in my expierience a service works with simple/forking and only
 one of them while i must say my low-level understanding may
 not be enouh to realize what to use.

 The daemon doesn't need to do extra work to fork, and systemd won't
 need to do all the work associated with tracking a forked process -
 it's a lot less work, thus more efficient, and actually more robust

 hi

 does this mean in recent systemd-versions it is no longer needed
 to use Type=forking at all while it was a must for some servcies
 in early versions?
 It's still necessary, if the service forks. But if the service *can*
 be instructed not to fork, then it's beneficial to do so

thanks!

i will look whioch of our services are running with Type=simple

P.S.:
i love systemd and i loved the idea from the very beginning
only the too realy state in Fedora 15 made me that frustrated!



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-15 Thread Kok, Auke-jan H
On Mon, Apr 15, 2013 at 10:59 AM, Reindl Harald h.rei...@thelounge.net wrote:


 Am 15.04.2013 19:53, schrieb Kok:
 thanks, i will give it a try
 why not Type=forking?

 in my expierience a service works with simple/forking and only
 one of them while i must say my low-level understanding may
 not be enouh to realize what to use.

 The daemon doesn't need to do extra work to fork, and systemd won't
 need to do all the work associated with tracking a forked process -
 it's a lot less work, thus more efficient, and actually more robust

 hi

 does this mean in recent systemd-versions it is no longer needed
 to use Type=forking at all while it was a must for some servcies
 in early versions?

no, which is why I added the '-f' flag to the preload startup in the
service unit that I posted (it keeps preload running in the
foreground).

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


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-15 Thread Reindl Harald


Am 15.04.2013 21:17, schrieb Kok:
 On Mon, Apr 15, 2013 at 10:59 AM, Reindl Harald h.rei...@thelounge.net 
 wrote:


 Am 15.04.2013 19:53, schrieb Kok:
 thanks, i will give it a try
 why not Type=forking?

 in my expierience a service works with simple/forking and only
 one of them while i must say my low-level understanding may
 not be enouh to realize what to use.

 The daemon doesn't need to do extra work to fork, and systemd won't
 need to do all the work associated with tracking a forked process -
 it's a lot less work, thus more efficient, and actually more robust

 hi

 does this mean in recent systemd-versions it is no longer needed
 to use Type=forking at all while it was a must for some servcies
 in early versions?
 
 no, which is why I added the '-f' flag to the preload startup in the
 service unit that I posted (it keeps preload running in the
 foreground)

aaah NOW i got it

forgive a user that he is not so in the deep inside the
details as people breath systemd like the air :-)

P.S:
the After=kdm.service is exactly what i want
preload at the very and at boot and use the time between show
the login-screen and the login happening while feed systemd-readahead
with the results from preload.service in the 10 seconds
___

[root@srv-rhsoft:~]$ systemctl status preload.service
preload.service - Adaptive readahead daemon
   Loaded: loaded (/etc/systemd/system/preload.service; enabled)
   Active: active (running) since Mo 2013-04-15 22:24:27 CEST; 10s ago
 Main PID: 2149 (preload)
   CGroup: name=systemd:/system/preload.service
   └─2149 /usr/sbin/preload -f --verbose 1
___

[root@srv-rhsoft:~]$ cat /etc/systemd/system/preload.service
[Unit]
Description=Adaptive readahead daemon
After=kdm.service

[Service]
Type=simple
ExecStart=/usr/sbin/preload -f --verbose 1
Restart=always
RestartSec=1
Nice=19
IOSchedulingClass=3

[Install]
WantedBy=multi-user.target
___



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-14 Thread Reindl Harald

Am 14.04.2013 06:42, schrieb Kok:
 On Sat, Apr 13, 2013 at 2:24 PM, Reindl Harald h.rei...@thelounge.net wrote:
 - extend the collector to run much longer

 which scre to change in teh config?
 
 You can modify systemd-readahead-done.timer, basically change:
 
 OnActiveSec=10s
 
 to whatever value you like

thanks, i give it a try with 3600 seconds what should cover
also a long coffee and mostly powner on with WOL and sync
work-data while drive to the office

is there any way to get informations what is collected
and where are the informations stored?

locate seems not to show any related file
that feels all a little bit like a blackbox

a reason i would love to define specific applications which should
always get preloaded on boot independent what is collected at runtime
what about starting the machine remove vis WOL and never login because
some data sync and shutdown 2 hours later - will the desktop get lost
from the readahead-collection - questions over questions...

[harry@srv-rhsoft:~]$ cat /etc/systemd/system/systemd-readahead-done.timer
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Stop Read-Ahead Data Collection 3600s After Completed Startup
Documentation=man:systemd-readahead-replay.service(8)
DefaultDependencies=no
Conflicts=shutdown.target
After=default.target
Before=shutdown.target

[Timer]
OnActiveSec=3600s

[Install]
Also=systemd-readahead-collect.service



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-14 Thread Mantas Mikulėnas
On Sun, Apr 14, 2013 at 7:13 PM, Reindl Harald h.rei...@thelounge.net wrote:
 is there any way to get informations what is collected

/usr/lib/systemd/systemd-readahead analyze

 and where are the informations stored?

/.readahead

 locate seems not to show any related file

updatedb

--
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-14 Thread Reindl Harald


Am 14.04.2013 20:08, schrieb Mantas Mikulėnas:
 On Sun, Apr 14, 2013 at 7:13 PM, Reindl Harald h.rei...@thelounge.net wrote:
 is there any way to get informations what is collected
 
 /usr/lib/systemd/systemd-readahead analyze

thanks for that, alias set

[root@rh:~]$ which readahead_analyze
alias readahead_analyze='/usr/lib/systemd/systemd-readahead analyze'
/usr/lib/systemd/systemd-readahead

 and where are the informations stored?
 /.readahead

thanks, i discovered this after searching around

 locate seems not to show any related file
 updatedb

well, i did not expect it directly in / and so missed the first match

remeians only the problem that the collector stops after 2 minutes
and so the timer and it's settings are quite useless currently as
also that if you do not login within the timespan you lose readahead
of the desktop and the 3600s may bring the problem that too much
useless stuff is covered

IMHO there should be a way to enforce readahead for a defined set

practical example:
i update / reboot my home-machine regulary from the office
well, there will happen no graphical login after that
but that doe snot mean my first action at evening is not start KDE
as well as firefox, thunderbird, kopete and so on

yes, the preload package would cover this, but it is badly
maintained and is still missing a systemd-unit and having two
readahead/preload mechanisms leaves a bad taste compared with
one well working solution



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-14 Thread Kok, Auke-jan H
On Sun, Apr 14, 2013 at 9:13 AM, Reindl Harald h.rei...@thelounge.net wrote:

 Am 14.04.2013 06:42, schrieb Kok:
 On Sat, Apr 13, 2013 at 2:24 PM, Reindl Harald h.rei...@thelounge.net 
 wrote:
 - extend the collector to run much longer

 which scre to change in teh config?

 You can modify systemd-readahead-done.timer, basically change:

 OnActiveSec=10s

 to whatever value you like

 thanks, i give it a try with 3600 seconds what should cover
 also a long coffee and mostly powner on with WOL and sync
 work-data while drive to the office

take care that the new readahead file only gets written at the end of
the 3600s, it's not updated continuously.

 is there any way to get informations what is collected
 and where are the informations stored?

$ man systemd-readahead

you can run

$ /usr/lib/systemd/systemd-readahead analyze

to see what's in the readahead file.

 a reason i would love to define specific applications which should
 always get preloaded on boot independent what is collected at runtime
 what about starting the machine remove vis WOL and never login because
 some data sync and shutdown 2 hours later - will the desktop get lost
 from the readahead-collection - questions over questions...

feel free to contribute code or algorithm's to improve, I'll be more
than welcome to take concrete contributions as I've been trying to
improve on readahead for several years now. There is certainly room
for improvement, but the devil is in the details.

Cheers,

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


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-14 Thread Reindl Harald
Am 14.04.2013 20:49, schrieb Kok:
 a reason i would love to define specific applications which should
 always get preloaded on boot independent what is collected at runtime
 what about starting the machine remove vis WOL and never login because
 some data sync and shutdown 2 hours later - will the desktop get lost
 from the readahead-collection - questions over questions...
 
 feel free to contribute code or algorithm's to improve, I'll be more
 than welcome to take concrete contributions as I've been trying to
 improve on readahead for several years now. There is certainly room
 for improvement, but the devil is in the details

if i only could C/C++ additionally to PHP/SQL and had time to
work that out by 3 fulltime-jobs for one man :-(

playing around with /usr/lib/systemd/systemd-readahead collect
it looks like it re-creates /.readahead from scratch, meaning
you lose also anything covered from the boot-run

what about a dbus-triggered instance like cups and other services
are fired up after login which creates a /.readahead-usersession
proceeded at boot the same way as /.readahead

not saying i am able to implement anything, sorry, but i try
to brain-storm ideas here

 seems like i covered a bug
 the collector stops after exactly 2 minutes

 src/readahead/readahead.c has:

 usec_t arg_timeout = 2*USEC_PER_MINUTE;

 so, it's by design to stop after 2 minutes.

 That's for a good reason, I'm not sure if changing it makes much sense
 - most people will never want to use non-standard values, and 2
 minutes helps everyone (it could help some non-standard cases more,
 but it doesn't hurt anyone)

well, but that makes systemd-readahead-done.timer useless as also
extend how long the collector should run



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-14 Thread Kok, Auke-jan H
On Sun, Apr 14, 2013 at 12:05 PM, Reindl Harald h.rei...@thelounge.net wrote:
 Am 14.04.2013 20:49, schrieb Kok:
 a reason i would love to define specific applications which should
 always get preloaded on boot independent what is collected at runtime
 what about starting the machine remove vis WOL and never login because
 some data sync and shutdown 2 hours later - will the desktop get lost
 from the readahead-collection - questions over questions...

 feel free to contribute code or algorithm's to improve, I'll be more
 than welcome to take concrete contributions as I've been trying to
 improve on readahead for several years now. There is certainly room
 for improvement, but the devil is in the details

 if i only could C/C++ additionally to PHP/SQL and had time to
 work that out by 3 fulltime-jobs for one man :-(

 playing around with /usr/lib/systemd/systemd-readahead collect
 it looks like it re-creates /.readahead from scratch, meaning
 you lose also anything covered from the boot-run

 what about a dbus-triggered instance like cups and other services
 are fired up after login which creates a /.readahead-usersession
 proceeded at boot the same way as /.readahead

it does more damage to do excessive readahead at boot for services
that don't need to start until way, way after boot. The whole idea is
to only read things you are going to need, and not more. Otherwise you
could just read everything you can possibly read from disk into
memory.

 seems like i covered a bug
 the collector stops after exactly 2 minutes

 src/readahead/readahead.c has:

 usec_t arg_timeout = 2*USEC_PER_MINUTE;

 so, it's by design to stop after 2 minutes.

 That's for a good reason, I'm not sure if changing it makes much sense
 - most people will never want to use non-standard values, and 2
 minutes helps everyone (it could help some non-standard cases more,
 but it doesn't hurt anyone)

 well, but that makes systemd-readahead-done.timer useless as also
 extend how long the collector should run

most people won't ever need to have it run more than 10 seconds until
after the system is done booting, so it has good value. Longer isn't
better (see my earlier argument, which holds especially true for
rotating media).

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


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-14 Thread Reindl Harald

Am 14.04.2013 21:18, schrieb Kok:
 On Sun, Apr 14, 2013 at 12:05 PM, Reindl Harald h.rei...@thelounge.net 
 wrote:
 what about a dbus-triggered instance like cups and other services
 are fired up after login which creates a /.readahead-usersession
 proceeded at boot the same way as /.readahead
 
 it does more damage to do excessive readahead at boot for services
 that don't need to start until way, way after boot. The whole idea is
 to only read things you are going to need, and not more. Otherwise you
 could just read everything you can possibly read from disk into
 memory

oh, now i realized that systemd-readahead covers any file-type
surely it would be bad preloading anything including data

please have a look at 
http://koji.fedoraproject.org/koji/buildinfo?buildID=393183
this is covering only libraries but seems to be in a bad maintaining-state
because still no systemd-unit and all of te last updates where auto 
mass-rebuilds

i wrote a systemd-unit for my machine which starts after kdm.service
https://bugzilla.redhat.com/show_bug.cgi?id=951956

 well, but that makes systemd-readahead-done.timer useless as also
 extend how long the collector should run
 
 most people won't ever need to have it run more than 10 seconds until
 after the system is done booting, so it has good value. Longer isn't
 better (see my earlier argument, which holds especially true for
 rotating media)

correct for readahead any file-type

with the preload-package above systemd-readahead covers also user-apps
between several reboots without graphical login because it sees the
preloading of the adaptive service and ONLY libraries

maybe this logic over the long in systemd can make preload obsolete

[root@rh:~]$ /usr/lib/systemd/systemd-readahead analyze | grep thunderbird
   100% ( 1)11192: /usr/lib64/thunderbird/libmozalloc.so
   100% ( 1)16560: /usr/lib64/thunderbird/components/libdbusservice.so
   100% ( 1)15280: /usr/lib64/thunderbird/libldif60.so
   100% ( 1)19592: /usr/lib64/thunderbird/libxpcom.so
   100% ( 1)24304: /usr/lib64/thunderbird/libprldap60.so
   100% ( 1)38680: /usr/lib64/thunderbird/components/libmozgnome.so
   100% ( 1)84960: /usr/lib64/thunderbird/thunderbird
   100% ( 1)   223656: /usr/lib64/thunderbird/libldap60.so
   100% ( 1)   393632: 
/usr/lib64/thunderbird/langpacks/langpack...@thunderbird.mozilla.org.xpi
   100% ( 1)  8372428: /usr/lib64/thunderbird/omni.ja

[root@rh:~]$ /usr/lib/systemd/systemd-readahead analyze | grep java
   100% ( 1) 7344: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/bin/java
   100% ( 1)   181312: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/lib/amd64/libjava.so
   100% ( 1)94888: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/lib/amd64/libnet.so
   100% ( 1)73856: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/lib/amd64/libnio.so
   100% ( 1)61248: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/lib/amd64/libverify.so
   100% ( 1)36448: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/lib/amd64/libzip.so
   100% ( 1)91994: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/lib/jce.jar
   100% ( 1)   679167: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/lib/jsse.jar
   100% ( 1)  2540855: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/lib/resources.jar
   100% ( 1)57904: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/lib/amd64/jli/libjli.so
   100% ( 1)69689: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/lib/ext/pulse-java.jar
   100% ( 1)   452955: 
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.17.x86_64/jre/lib/ext/gnome-java-bridge.jar
   100% ( 1)   186530:
/usr/local/Zend/ZendStudio/plugins/org.zend.sdk_1.0.6.201210091843/lib/openshift-java-client-2.0.0.jar
   100% ( 1)   113129:
/usr/local/Zend/ZendStudio/configuration/org.eclipse.osgi/bundles/474/1/.cp/lib/svnkit-javahl.jar
   100% ( 1)   189996:
/usr/local/Zend/ZendStudio/configuration/org.eclipse.osgi/bundles/475/1/.cp/lib/svnkit-javahl.jar
   100% ( 1)  4973536: /usr/lib64/libjavascriptcoregtk-1.0.so.0.13.11




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-14 Thread Garry T. Williams
On 4-13-13 23:24:22 Reindl Harald wrote:
 Am 13.04.2013 23:08, schrieb Kok:
  A lot of things are possible and would help this:
  
  - change your system to auto-logon your account and start the
  applications for you. This is possible without any coding.
 
 well, that's a no-go

You might be interested to know that when I set the option to log into
a locked KDE desktop, I see all of the KDE desktop-related files in
systemd-readahead analyze after two boots without changing the
OnActiveSec=10s.  This is truly effective.

(I know this may not be possible for you, but I just wanted to note
that the suggestion worked well here where I almost always log into
the desktop.  The rare occasion when I do not want that now means I am
forced to log out immediately.)

$ cat /etc/kde/kdm/kdmrc
...
[X-:0-Core]
AutoLoginEnable=true
AutoLoginLocked=true
AutoLoginUser=garry

-- 
Garry T. Williams

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


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-14 Thread Kok, Auke-jan H
On Sun, Apr 14, 2013 at 1:01 PM, Reindl Harald h.rei...@thelounge.net wrote:

 Am 14.04.2013 21:18, schrieb Kok:
 On Sun, Apr 14, 2013 at 12:05 PM, Reindl Harald h.rei...@thelounge.net 
 wrote:
 what about a dbus-triggered instance like cups and other services
 are fired up after login which creates a /.readahead-usersession
 proceeded at boot the same way as /.readahead

 it does more damage to do excessive readahead at boot for services
 that don't need to start until way, way after boot. The whole idea is
 to only read things you are going to need, and not more. Otherwise you
 could just read everything you can possibly read from disk into
 memory

 oh, now i realized that systemd-readahead covers any file-type
 surely it would be bad preloading anything including data

 please have a look at 
 http://koji.fedoraproject.org/koji/buildinfo?buildID=393183
 this is covering only libraries but seems to be in a bad maintaining-state
 because still no systemd-unit and all of te last updates where auto 
 mass-rebuilds

 i wrote a systemd-unit for my machine which starts after kdm.service
 https://bugzilla.redhat.com/show_bug.cgi?id=951956

that unit file should just go into the project upstream, I'd also
suggest removing the kdm dependency, running with -f, making log
output go to stdout and removing the Type=forking, so it becomes:



[Unit]
Description=Adaptive readahead daemon

[Service]
ExecStart=/usr/sbin/preload -f 1 -l 
Restart=always
RestartSec=1
Nice=19
IOSchedulingClass=3

[Install]
WantedBy=multi-user.target

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


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-14 Thread Reindl Harald

Am 14.04.2013 22:49, schrieb Garry T. Williams:
 On 4-13-13 23:24:22 Reindl Harald wrote:
 Am 13.04.2013 23:08, schrieb Kok:
 A lot of things are possible and would help this:

 - change your system to auto-logon your account and start the
 applications for you. This is possible without any coding.

 well, that's a no-go
 
 You might be interested to know that when I set the option to log into
 a locked KDE desktop, I see all of the KDE desktop-related files in
 systemd-readahead analyze after two boots without changing the
 OnActiveSec=10s.  This is truly effective

yes, but you should not do this in my usecase having the same
machine at office and at home and sync data and userhome twice
a day (in the morning to the office and at evening back) to
have everywheer the same desktop, settings and profiles :-)

that's why i search ways to optimize read-ahead without lose
the informations on headless boots




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-14 Thread Reindl Harald


Am 14.04.2013 23:06, schrieb Kok:
 On Sun, Apr 14, 2013 at 1:01 PM, Reindl Harald h.rei...@thelounge.net wrote:
 oh, now i realized that systemd-readahead covers any file-type
 surely it would be bad preloading anything including data

 please have a look at 
 http://koji.fedoraproject.org/koji/buildinfo?buildID=393183
 this is covering only libraries but seems to be in a bad maintaining-state
 because still no systemd-unit and all of te last updates where auto 
 mass-rebuilds

 i wrote a systemd-unit for my machine which starts after kdm.service
 https://bugzilla.redhat.com/show_bug.cgi?id=951956
 
 that unit file should just go into the project upstream, I'd also
 suggest removing the kdm dependency, running with -f, making log
 output go to stdout and removing the Type=forking, so it becomes:

upstream seems to be dead

maybe there are no bugs and development to improve things
in this case upstream would not need to be more alive :-)

but i doubt that is the truth and so maybe systemd can step
into over the long...


 [Unit]
 Description=Adaptive readahead daemon
 
 [Service]
 ExecStart=/usr/sbin/preload -f 1 -l 
 Restart=always
 RestartSec=1
 Nice=19
 IOSchedulingClass=3
 
 [Install]
 WantedBy=multi-user.target
 

thanks, i will give it a try
why not Type=forking?

in my expierience a service works with simple/forking and only
one of them while i must say my low-level understanding may
not be enouh to realize what to use.



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-13 Thread Kok, Auke-jan H
On Sat, Apr 13, 2013 at 4:27 AM, Reindl Harald h.rei...@thelounge.net wrote:
 Hi

 as far as i understand systemd-readahead is catching what is
 loaded directly due boot and 10 seconds after, well that's fine

 but is there a possibility to feed it with additional applications?

 example of the real life here:

  * the machine get powered on in the morning
  * due this sitting in the kitchen with a coffee
  * after that login in KDE, plasma and kopete are started
  * finally Thunderbird and Firefox are started
  * mostly Eclipse is the next
  * the machine has 16 GB RAM

 it would make pretty much sense that Thunderbird, Firefox and
 so on are pre-loaded or at least their libraries after the
 login-manager appears to use the time between boot and login

A lot of things are possible and would help this:

- change your system to auto-logon your account and start the
applications for you. This is possible without any coding.

- do per-user readahead, so that when a user logs in readahead-collect
runs again but with a different pack, stored in the users home folder.
Most of this should be possible with little work, but you'd have to
write some xdg autostart files and possibly patch the readahead

- extend the collector to run much longer

- manually create a pack and disable the collector

one of the problems is that it's hard to create something that
generally works well for all situations, and autologon+lock desktop
benefits from simplicity since readahead catches almost all of it.

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


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-13 Thread Reindl Harald


Am 13.04.2013 23:08, schrieb Kok:
 On Sat, Apr 13, 2013 at 4:27 AM, Reindl Harald h.rei...@thelounge.net wrote:
 it would make pretty much sense that Thunderbird, Firefox and
 so on are pre-loaded or at least their libraries after the
 login-manager appears to use the time between boot and login
 
 A lot of things are possible and would help this:
 
 - change your system to auto-logon your account and start the
 applications for you. This is possible without any coding.

well, that's a no-go

 - do per-user readahead, so that when a user logs in readahead-collect
 runs again but with a different pack, stored in the users home folder.
 Most of this should be possible with little work, but you'd have to
 write some xdg autostart files and possibly patch the readahead
 
 - extend the collector to run much longer

which scre to change in teh config?

 - manually create a pack and disable the collector
 
 one of the problems is that it's hard to create something that
 generally works well for all situations, and autologon+lock desktop
 benefits from simplicity since readahead catches almost all of it

my idea is not any generic and collecting thing

it is more that have a config file where the professional user can
manually add application paths which are caught by systemd-readahead

P.S.:
yes i know about preload but since systemd assimilates mayn things
in the past few years including readahead i feel this would be the
right direction to make systemd-readahead complete and sadly
i am a webdeveloper and can not provide code/patches :-(



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-readahead and often used applications

2013-04-13 Thread Kok, Auke-jan H
On Sat, Apr 13, 2013 at 2:24 PM, Reindl Harald h.rei...@thelounge.net wrote:


 Am 13.04.2013 23:08, schrieb Kok:
 On Sat, Apr 13, 2013 at 4:27 AM, Reindl Harald h.rei...@thelounge.net 
 wrote:
 it would make pretty much sense that Thunderbird, Firefox and
 so on are pre-loaded or at least their libraries after the
 login-manager appears to use the time between boot and login

 A lot of things are possible and would help this:

 - change your system to auto-logon your account and start the
 applications for you. This is possible without any coding.

 well, that's a no-go

 - do per-user readahead, so that when a user logs in readahead-collect
 runs again but with a different pack, stored in the users home folder.
 Most of this should be possible with little work, but you'd have to
 write some xdg autostart files and possibly patch the readahead

 - extend the collector to run much longer

 which scre to change in teh config?

You can modify systemd-readahead-done.timer, basically change:

OnActiveSec=10s

to whatever value you like.


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