/var/lock/SuSEfirewall2.booting was mentioned in a log and was still present minutes after booting and after login to KDE.
cyrus-imapd needed to be started manually after some reboots (but not all)
wwwoffle needed to be started manually after reboot
All these things finally found one solution:
“jexec” hangs on boot.
(Switched back to the console 1 to see the “traffic light” from booting.)
There
Starting jexec…
was the last line and no success/fail behind.
I disabled jexec in yast/system/runlevels, now all the listed symptoms are gone…
What I still don’t know, is what jexec is good for, but so far I saw no problems. So I feel much better off without it for the moment…
A prison or jail usually means that a process gets started in a limited environment, where it doesn’t have access to the whole system. (So e.g. it can’t run havoc on your whole system by accident or if the code is malicious)
In /etc/rc.d/jexec you find:
JEXEC=/usr/java/default/lib/jexec
so it is some java related stuff.
And a link to The binfmt_misc Homepage
which talks about additional binary formats. (But doesn’t mention jexec)
So my best guess right now is something like jexec is used to execute java (.class) files just a one would start a executable file compiled for linux. But instead it is handed to jexec which executes the java byte code.
This also matches nicely with the output from
/usr/java/default/lib/jexec
Usage: java -options] class [args…]
(to execute a class)
or java -options] -jar jarfile [args…]
(to execute a jar file)
In that case I wouldn’t miss it much - if it is not used behind the scenes, where I can’t just add the needed ‘java …’ in front.