Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

long startup time due to searchpath '.' #4613

Closed
DorpsGek opened this issue May 14, 2011 · 8 comments
Closed

long startup time due to searchpath '.' #4613

DorpsGek opened this issue May 14, 2011 · 8 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

moormaster85 opened the ticket and wrote:

problem description:
When I try to run openttd from the programs menu in gnome (tested in archlinux) it takes 10-15 minutes (!)
to start openttd. If I run it from the console I get following output:

    moormaster@moormasterpc:~$ openttd -d 9
    dbg: [misc] /home/moormaster/.openttd/ added as search path
    dbg: [misc] /home/moormaster/ added as search path
    dbg: [misc] /usr/share/openttd/ added as search path
    dbg: [misc] /home/moormaster/.openttd/ found as personal directory
    dbg: [misc] Scanning for tars


It seems that openttd unpacks all tar archives it can find in any subdirectory of the search paths. Since
the users home directory is added as search path there can be a lot such files preventing openttd from
starting quickly.

workaround:
Not running openttd from within the home directory but from within an empty directory:

    moormaster@moormasterpc:~$     mkdir tmp
    moormaster@moormasterpc:~$     cd tmp
    moormaster@moormasterpc:~/tmp$ openttd

This way openttd boots up instantly.

suggestion:
I could think of two possible solutions for this problem:

    1. exclusion of '.' from the search path in general

    or 2. be able to control the search path using a command line parameter

Reported version: 1.1.0
Operating system: Linux


This issue was imported from FlySpray: https://bugs.openttd.org/task/4613
@DorpsGek
Copy link
Member Author

frosch wrote:

Since r20166 (2010-07-16), included in 1.0.3, thus also in 1.1.0:
"." is excluded from the search paths if it equals the home directory "~" exactly for that reason; and that exclusion works fine on my side (debian).

So:

  1. Are you indeed using 1.1.0?
  2. Is the openttd binary in your home directory? (since the exclusion is only done for the working directory, not for the binary directory)
  3. Else I can only guess that the archlinux distribution changed something.

This comment was imported from FlySpray: https://bugs.openttd.org/task/4613#comment9923

@DorpsGek
Copy link
Member Author

moormaster85 wrote:

  1. Are you indeed using 1.1.0?

yes i think so:
moormaster@moormasterpc:~$ openttd -h
OpenTTD 1.1.0

  1. no the binary has been installed to /usr/bin

  2. I will check if there are any patches applied in the archlinux package


This comment was imported from FlySpray: https://bugs.openttd.org/task/4613#comment9925

@DorpsGek
Copy link
Member Author

moormaster85 wrote:

http://projects.archlinux.org/svntogit/community.git/tree/openttd/repos/community-i686/PKGBUILD

it doesn't seem as if archlinux would add any patches to openttd 1.1.0


This comment was imported from FlySpray: https://bugs.openttd.org/task/4613#comment9927

@DorpsGek
Copy link
Member Author

Rubidium wrote:

Given it misses a dependency on LZMA, I wonder how it ever did build with those configure flags. Or, I might be grossly misunderstanding the way archlinux builds its packages. Even then, without the build log it's hard to see what actual configure parameters were used/passed.

Or maybe archlinux doesn't set a home directory in there places where it's meant to set them? Where is openttd.cfg actually stored with archlinux? I can't quite believe its somewhere in the home directory, otherwise it would not scan there.

Given I have no clue about the workings of archlinux, I think it would be useful to get some help from the actual OpenTTD maintainers in archlinux; I assume they have archlinux running and know what they need to look at for figuring out what actually is going on.


This comment was imported from FlySpray: https://bugs.openttd.org/task/4613#comment9930

@DorpsGek
Copy link
Member Author

Terkhen wrote:

I also run archlinux and gnome. My OpenTTD log for the version downloaded from archlinux repositories looks similar to yours (when run from ~):

dbg: [misc] /home/terkhen/.openttd/ added as search path
dbg: [misc] /home/terkhen/ added as search path
dbg: [misc] /usr/share/openttd/ added as search path
dbg: [misc] /home/terkhen/.openttd/ found as personal directory
dbg: [misc] Scanning for tars

Adding a OpenTTD 1.1.0 compiled by me to the PATH gives the same search paths. I don't know where is openttd.cfg stored in a "normal" installation in archlinux. I'll check what is the DoScanWorkingDirectory() function doing.


This comment was imported from FlySpray: https://bugs.openttd.org/task/4613#comment9932

@DorpsGek
Copy link
Member Author

moormaster85 wrote:

The openttd-package itself does not contain an openttd.cfg file. This file is being created at the first run in $HOME/.openttd/ dir.

The lzma headers are included in the xz package which is already required by the package manager of archlinux... so it's ok to not have xz as explicit dependency.

I can build the package and send you a log file if you need it :)


This comment was imported from FlySpray: https://bugs.openttd.org/task/4613#comment9933

@DorpsGek
Copy link
Member Author

Terkhen wrote:

It seems that SP_BINARY_DIR is being set to ~ too. Since the "is home" check is only done for SP_WORKING_DIR, /home/user/ is set as a valid search path. See the log for a location that is NOT ~:

dbg: [misc] /home/terkhen/openttd/ added as search path
dbg: [misc] /home/terkhen/.openttd/ added as search path
dbg: [misc] /home/terkhen/openttd/ added as search path <-- duplicate
dbg: [misc] /usr/local/share/games/openttd/ added as search path
dbg: [misc] /home/terkhen/.openttd/ found as personal directory

I don't know the reason for this duplication, but it seems that the path to the executable is only "openttd", which gets resolved to /home/user/ and then set to _searchpaths[SP_BINARY_DIR].


This comment was imported from FlySpray: https://bugs.openttd.org/task/4613#comment9934

@DorpsGek
Copy link
Member Author

frosch closed the ticket.

Reason for closing: Fixed

in r22465; thanks for checking all the stuff on arch


This comment was imported from FlySpray: https://bugs.openttd.org/task/4613

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant