-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The /etc/init.d scripts no longer work as documented in SuSE 9.3. What we knew, and what is documented in chapter 7 of the admin book, no longer is true. We knew that all scripts (symlinks) in the corresponding runlevel directory (for example, /etc/init.d/rc5.d/) were executed in numerical order: those whose first letter is S during boot, and those with K during halt. Forget it! I have discovered that you may have a symlink there that never gets executed. They are ignored! The mechanism is different (see my thread "Strange problem starting services in SuSE 9.3" for detailed info on how I discovered it). The proof, told in brief, is that I had '/etc/init.d/rc5.d/S17postfix', and it never executed, nor '//etc/init.d/rc5.d/K05postfix', because the ".depend.*" files had wrong info. The new mechanism is based in "make" and files like '/etc/init.d/.depend.start', '.depend.stop', '.depend.boot', and 'Makefile', and it is not documented - not in the SuSE admin book, nor in init.d(7). The new code is this: # Stop/Start services with make like feature of startpar # if test "$USE_MAKE" = "yes" -a -n "$startpar" ; then startopt="-p4 -t 30 -T 3 $(splashmake)" eval $($startpar $startopt -M stop -P $PREVLEVEL -R $RUNLEVEL) failed="${failed:+$failed }$failed_service" skipped="${skipped:+$skipped }$skipped_service" eval $($startpar $startopt -M start -P $PREVLEVEL -R $RUNLEVEL) failed="${failed:+$failed }$failed_service" skipped="${skipped:+$skipped }$skipped_service" unset failed_service skipped_service unset startopt startpar else ... the standard old way. There is a triffle more info in startpar(8). - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCbi6KtTMYHG2NR9URAu+yAJ9z837xhmZSwBbenQrf3uJF3WLC8gCcDtE2 4fwJRKJWEF7W3mJlx/cJZjY= =KkTW -----END PGP SIGNATURE-----
Also the last update for ethereal messed up entire gtk-qt-engine (SuSE 9.2 pro) ... feels like I am using windoes(not) and their crapy updates. I guess that software testing it is not a priority for Novell. Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
The /etc/init.d scripts no longer work as documented in SuSE 9.3.
What we knew, and what is documented in chapter 7 of the admin book, no longer is true. We knew that all scripts (symlinks) in the corresponding runlevel directory (for example, /etc/init.d/rc5.d/) were executed in numerical order: those whose first letter is S during boot, and those with K during halt.
Forget it!
I have discovered that you may have a symlink there that never gets executed. They are ignored! The mechanism is different (see my thread "Strange problem starting services in SuSE 9.3" for detailed info on how I discovered it).
The proof, told in brief, is that I had '/etc/init.d/rc5.d/S17postfix', and it never executed, nor '//etc/init.d/rc5.d/K05postfix', because the ".depend.*" files had wrong info.
The new mechanism is based in "make" and files like '/etc/init.d/.depend.start', '.depend.stop', '.depend.boot', and 'Makefile', and it is not documented - not in the SuSE admin book, nor in init.d(7). The new code is this:
# Stop/Start services with make like feature of startpar # if test "$USE_MAKE" = "yes" -a -n "$startpar" ; then
startopt="-p4 -t 30 -T 3 $(splashmake)" eval $($startpar $startopt -M stop -P $PREVLEVEL -R $RUNLEVEL) failed="${failed:+$failed }$failed_service" skipped="${skipped:+$skipped }$skipped_service"
eval $($startpar $startopt -M start -P $PREVLEVEL -R $RUNLEVEL) failed="${failed:+$failed }$failed_service" skipped="${skipped:+$skipped }$skipped_service"
unset failed_service skipped_service unset startopt startpar else ... the standard old way.
There is a triffle more info in startpar(8).
- -- Cheers, Carlos Robinson
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76
iD8DBQFCbi6KtTMYHG2NR9URAu+yAJ9z837xhmZSwBbenQrf3uJF3WLC8gCcDtE2 4fwJRKJWEF7W3mJlx/cJZjY= =KkTW -----END PGP SIGNATURE-----
On Tue, Apr 26, 2005 at 03:35:15PM +0300, Ground Zero wrote:
Also the last update for ethereal messed up entire gtk-qt-engine (SuSE 9.2 pro) ... feels like I am using windoes(not) and their crapy updates. I guess that software testing it is not a priority for Novell.
Actually the gtk-qt-engine RPM got updated. What does not work for you? Ciao, Marcus
Fonts in gtk apps like ethereal, xchat, gaim etc are huge ... Before the gtk-qt-engine was updated modifyng /opt/gnome/share/themes/.... /gtkrc worked. Now we have to modify .gtk-qt-engine inside home directory. Marcus Meissner wrote:
On Tue, Apr 26, 2005 at 03:35:15PM +0300, Ground Zero wrote:
Also the last update for ethereal messed up entire gtk-qt-engine (SuSE 9.2 pro) ... feels like I am using windoes(not) and their crapy updates. I guess that software testing it is not a priority for Novell.
Actually the gtk-qt-engine RPM got updated.
What does not work for you?
Ciao, Marcus
On Tue, Apr 26, 2005 at 03:48:41PM +0300, SuSE Ground Zero wrote:
Fonts in gtk apps like ethereal, xchat, gaim etc are huge ... Before the gtk-qt-engine was updated modifyng /opt/gnome/share/themes/.... /gtkrc worked. Now we have to modify .gtk-qt-engine inside home directory.
The gtk-qt-engine is configurable in a KDE kcontrol module according to our KDE maintainers. Ciao, Marcus
It is NOT working ... rpm gtk-qt-engine it is containig a kcmgtk control but we cannot find this control in kde control center, and more "kcmshell kcmgtk" says no kcmgtk module found and also kcmshell --list does NOT contain something about gtk. What says your KDE maintainer about that. BTW ... after last firefox (crapy beta test update) gtk-qt-engine is broken AGAIN. Now modifyng /opt/gnome/*/*/gtkrc is ignored and also ignored is .rcgtk-qt-engine (or something). Now is a known thing: because Novell cannot mess with the SuSE brand is messing the usability of it. I just fear updating to 9.3. Using 9.2 pro. Marcus Meissner wrote:
On Tue, Apr 26, 2005 at 03:48:41PM +0300, SuSE Ground Zero wrote:
Fonts in gtk apps like ethereal, xchat, gaim etc are huge ... Before the gtk-qt-engine was updated modifyng /opt/gnome/share/themes/.... /gtkrc worked. Now we have to modify .gtk-qt-engine inside home directory.
The gtk-qt-engine is configurable in a KDE kcontrol module according to our KDE maintainers.
Ciao, Marcus
On Tue, 2005-04-26 at 14:05 +0200, Carlos E. R. wrote:
The new mechanism is based in "make" and files like '/etc/init.d/.depend.start', '.depend.stop', '.depend.boot', and 'Makefile', and it is not documented - not in the SuSE admin book, nor in init.d(7). The new code is this:
# Stop/Start services with make like feature of startpar # if test "$USE_MAKE" = "yes" -a -n "$startpar" ; then
startopt="-p4 -t 30 -T 3 $(splashmake)" eval $($startpar $startopt -M stop -P $PREVLEVEL -R $RUNLEVEL) failed="${failed:+$failed }$failed_service" skipped="${skipped:+$skipped }$skipped_service"
eval $($startpar $startopt -M start -P $PREVLEVEL -R $RUNLEVEL) failed="${failed:+$failed }$failed_service" skipped="${skipped:+$skipped }$skipped_service"
unset failed_service skipped_service unset startopt startpar else ... the standard old way.
What is the old saying.. "If it isn't broke, don't fix it." It looks like someday things are go to be -fixed- to the point they don't work anymore. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
participants (4)
-
Carlos E. R. -
Ken Schneider -
Marcus Meissner -
SuSE Ground Zero