OK, there’s lots to say about this.
In fact, openLuup itself starts up in under 2 seconds (before the HTTP port 3480 server starts.) Plugins themselves, can take longer, but that’s up to them. What I think you’re talking about is the startup time after a system reboot? In which case, this is rather out of my control.
Your manual startup procedure:
cd /home/pi/ect/cmh-ludl
/home/pi/ect/cmh-ludl/openLuup_reload
invites some comments:
[ul][li]I continue to be bemused by the appearance of “ect” instead of “etc”. This may be at the root of some problems. Perhaps you have both directory trees on your system somehow. But this must, originally, have been a typo somewhere.[/li]
[li]having done the [tt]cd[/tt] to your openLuup home directory, there’s no need to specify the full path, in fact that could be prone to error. You would be better off simply with [tt]./openLuup_reload[/tt][/li][/ul]
However, this last point may also be key to some of your observations. In fact, the openLuup_reload script is essentially an infinite loop and will never return (or, at least, until you force an exit, not a reload, of openLuup) so you ought to hang there forever.
If you want to detach the process and get on with other things, then use
./openLuup_reload &
or
nohup ./openLuup_reload &
if you want to log out and keep the process running.
I’m not sure where this comes from:
cp: cannot stat ?/www/cmh/skins/default/icons/MString.png?: No such file or directory
but I would guess that it’s from a plugin (perhaps the MultiString plugin) which has tried to use os.execute() to copy a non-existent file. It’s definitely not an openLuup diagnostic message. The fact that the file is not found is almost definitely because the directory [tt]/www/cmh/skins/default/icons/[/tt] does not exist, or, at least, does not contain that file. One option might be to create a symbolic link so this becomes an alias to the openLuup icons/ directory.
You rc.local file contains a [tt]sleep[/tt] directive which will force a 20 second wait anyway. I think this is there to help ensure that network services have started up before openLuup tries anything. But here, the etc/ect bug might be biting you, since it does [tt]/etc/cmh-ludl[/tt]. Again, that’s a directory that may or may not exist, but I think you mean to use the one in your pi home directory. So check your file system for these paths… it’s quite possible, now, that you have multiple copies of an openLuup installation and things might not be where you expect them to be. Don’t know how this has all happened, since I’m not sure how you set up the system in the first place, but it’s not something which the default openLuup_install script has created. Perhaps this was a turnkey system?
So a few things to sort out here, which might be a bit challenging if you’re not that familiar with RPi or Linux, but not really all that difficult. Let us know how you get on.