gene heskett posted on Sun, 10 Apr 2011 10:03:32 -0400 as excerpted:
> On Sunday, April 10, 2011 08:45:58 AM Duncan did opine:
>
>> gene heskett posted on Sun, 10 Apr 2011 01:56:17 -0400 as excerpted:
>> If you're seeing actual code in that file (plasma-desktop-appletsrc),
>> you're either looking at the wrong one, or it's /seriously/ corrupted!
>
> No, what I saw was the [] sections, multiplied several to the line in
> some cases, with name=whatever's following.
>
> See my plasma-desktop-appletsrc at:
> <http://gene.homelinux.net:85/gene/stuff4george/plasma-desktop-appletsrc>
> as it exists this morning. And I had to restart httpd just now, no idea
> what killed it. You can back out to just the 'gene' and see what keeps
> me out of the bars _most_ of the time. ;-) I need to redo the front
> page pix though, I was in the process of doing something about my
> weight, about 200 lbs there in 2004, from a high of about 215 10 years
> ago to 165 now. The beard is a little shorter now as the weather is
> warming, and the hair is shoulder length today. And a few more dings on
> my face from the dermatologists scalpel. I should wear more sunscreen,
> but I have enough allergies as it is. Mrs #3, 21 years and counting. A
> Good girl. The pix are generally dual linked by jigl.pl, so if you
> click on a thumb, you get a slide, click on the slide and get the camera
> output.
Just FWIW, backing out to just http://gene.homelinux.net:85 yields a
simple "server alive" message. I don't run my own server and don't claim
to have the skills to do so (tho I could certainly learn them), so take
this with that caveat, but I've /read/ that crackers see such generic
homepages as an indication that the server may not be well configured,
properly updated, etc -- IOW, an invitation to probe and potentially
exploit any weakness found.
So I'd recommend pointing that at something, perhaps your /gene page,
whatever. Unless you intentionally do that as a honeypot or something.
Meanwhile, you do have it on a non-standard port, 85, making it a bit more
obscure. That's good, but as I'm sure you know, it won't keep the port-
scanners from finding it.
Unless you have it behind an IP-filtering firewall and just let my IP in,
of course, as I believe you could have gotten it from the headers of my
post.
Meanwhile, I guess you're shorter than I am. I'm about 295 or so
(285-305), holding after dropping from 325 or so, peak, but don't believe
I appear /that/ much heavier, so gotta be taller. The challenges of being
a geek and spending all that time in front of the computer instead of at
the gym/pool/field/whatever...
Of course as you implied earlier with the diabetes mention, there are
health implications... When I go above 300, I hardly need to look at the
scale to know as I feel it. I've started biking again, and changed my
diet some, thus stabilizing just below 300, but I don't believe in yoyo
dieting, so while reversing the previous trend of gaining 5-10 pounds a
year to losing that would be nice, currently, stabilizing at a bit under
300 is reasonable.
> I might have a question about what I can start in one of these []
> sections.
> I have several background, non gfx apps that I have to start by hand
> after a reboot because putting them in rc.local is too early. X (kde)
> seriously needs its own version of rc.local that is user specific.
> Maybe it does, but I haven't found it. My own version of ~/gene/etc if
> you will. One in particular needs to be run as soon as kmail has done
> its initial check-mail scan and is settling down to rebuilding the
> indices.
This particular file (plasma-desktop-applets) is only config info for
plasma-desktop. It describes containers (activities, panels) and
plasmoids, the applets that run in them. These aren't apps on their own
and run in plasma context, so you can't and wouldn't want to run just any
app from here.
kde /does/ have a facility such as you describe, however.
Graphically, it is managed from kcontrol (the kde3 name, I refuse to call
it the way too generic and not descriptive systemsettings that kde4 uses,
as in general at least as shipped by kde, it's not in general global
systemsettings at all, but rather, user-specific kde settings, thus the
kde3 term precisely applies, the generic kde4 term most definitely does
*NOT* apply, and like that guy in "The Emperor's New Clothes", I'm not
going to be forced into pretending it does!), system administration
(umm...! tho a few of these actually /are/ or can be system level, date
and time, for instance), startup and shutdown (NOT system level, user
level), autostart.
What that does is place either *.desktop files (if using add program) or
symlinks (for scripts) into appropriate startup (or shutdown) dirs.
The *.desktop files mechanism is apparently freedesktop.org cooperative
standard compliant, and should launch the apps the *.desktop files point
to for any compliant window-manager/desktop-environment (not just kde).
The directory used for *.desktop files is accordingly determined by the
freedesktop.org standards, and is $XDG_CONFIG_HOME/autostart/ . Like the
$KDEHOME var discussed earlier, $XDG_CONFIG_HOME denotes the variable that
will determine location if found in kde's environment when it starts. The
default location if unset is ~/.config , so the default location for these
*.desktop files is ~/.config/autostart/ . Of course, since this is an X
related mechanism, the only option for *.desktop files is startup.
Presumably you could manage the *.desktop startup directory manually by
adding/removing desktop files to/from it as appropriate, tho I've not
tried it.
The scripts mechanism is kde specific. For startup, the location used is
configured in kcontrol, common appearance and behavior, account details,
paths. I don't actually remember for sure the default as mine has been
customized for so long, but IIRC it was $KDEHOME/Autostart or some such.
By default (checkbox in the graphical script-add mechanism), kde creates
symlinks to the script files as added, instead of copying the scripts
themselves. Presumably you can manage the location manually by adding the
scripts or symlinks yourself.
If you add a script in the GUI, it defaults to startup when added.
However, once added, the run-on column in the kcontrol applet becomes a
drop-down box, and it's possible to select two other options as well,
shutdown, or pre-kde-startup.
While kde allows you to add arbitrarily named startup scripts, if you
attempt to switch the dropdown to shutdown or pre-kde-startup, it'll
protest that only *.sh extension files can be used. Never-the-less, it
moves the symlink to the associated dir, even without the .sh extension.
Whether it actually runs it in that case, I don't know.
Unlike the location of the dir for kde startup scripts, I don't see a GUI
setting for the shutdown and pre-kde-start dirs. However, they appear to
be $KDEHOME/shutdown (for shutdown, of course) and $KDEHOME/env (for pre-
kde-start). The previously discussed $KDEHOME explanation of course
applies-- it'll be ~/.kde4 by default. After discovery of the GUI method
for managing the shutdown dir, I actually did create a script and manually
symlink it into that dir, for an earlier kde4 version, and it worked, tho
I don't need it any longer. So I know manual management of the shutdown
dir works as I used it. (FWIW, the script I had killed the akonadi mysql
backend which would otherwise continue running under my desktop username,
even after all login and X sessions for it were gone. I no longer need
the script as the sqlite backend matured and I use it now. sqlite is more
appropriate for the akonadi usage than a full-fledged mysql session,
anyway, IMO, tho it wasn't thread-safe when kde4/akonadi was originally
released thus the mysql default until the sqlite solution matured.)
Presumably the pre-kde-start/env dir works similarly.
A couple notes:
1) The scripts do I believe have to have execute permissions set or they
won't run.
2) I don't know for sure as I've never had occasion to try it, but I
expect that if you put a script in the pre-kde-start/env dir and it starts
anything you want kept running, you may have to background it and probably
disown it as well, using standard shell ops, to keep it from holding up kde
start until it's finished running or from dying with the script. This,
because as the name of the dir suggests, it's designed for setting up the
environment and other such things, so kde itself likely won't run until
the scripts located in the env dir terminate.
> And I just had to kill yet another copy of knotify4, hung at 95% of a
> core,
> bouncing from core to core. When I went to bed it was about 20 down in
> an htop display, using no cpu. And it has now been restarted, by
> kdeinit I assume, running normally again.
Sounds like you may need to setup a babysitter script, to watch for
knotify4 runtime abuse and kill it when necessary.
Or simply (well, perhaps not-so-simply, but anyway...) find whatever
notification is bad and fix it. Presumably the problem is being triggered
when a notification tries to play a corrupt soundfile or some such. Find
said soundfile and fix it, or said notification and either disable it or
point it at a different soundfile, and the problem will likely go away.
Notification config is in kcontrol as well.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
