I recall I had a heck of a time in the past with the older kde, in keeping the monitors/screensaver set so it might show a few minutes of the screensaver of choice, and to powerdown the monitor after a few minutes of screen saver. But it can't remember those settings more than a week or so, so I just put a couple entries in my crontab:
*/1 * * * * * xset +dpms */1 * * * * * xset dpms 300 0 600
To see if refreshing its memory hourly will effect a fix.
But it sure would be nice if we didn't have to overpower it like that to keep it working.
In TDE control center, its set 5,0,10 but that seems not to affect it, when it has failed the pheripherals/display/screensaver and display power management are all zeroed out or the checkboxes cleared. It appears is as if a zmalloc has gone astray? Under appearance/screensaver its set to start a slide show after 4 minutes. The memory of whatever it uses for the "elevator music for the eyeball" also seems transient, it switches to either a blank screen or some glx thing that burns up the cpu, again at random intervals that do not seem to correlate with the dpms settings failures.
Info, bug action, your pick. ;-)
Cheers, Gene Heskett
On Friday 20 March 2015 11:31:12 Gene Heskett wrote:
I recall I had a heck of a time in the past with the older kde, in keeping the monitors/screensaver set so it might show a few minutes of the screensaver of choice, and to powerdown the monitor after a few minutes of screen saver. But it can't remember those settings more than a week or so, so I just put a couple entries in my crontab:
*/1 * * * * * xset +dpms */1 * * * * * xset dpms 300 0 600
Actually this is wrong as it then is effectively * * * * * *, the star string s/b * */1 * * * * as it was doing it on the minute, but then cron was emailing me that it could not open display "", so I have now made it hourly, and added -display 0:0 after the xset to see if that works...
Gotta be a way to make this work. I would have and had always assumed that doing something from the crontab was exactly like my typing it into a terminal, so whats the deal with that? Why can't my crontab do anything I can type?
To see if refreshing its memory hourly will effect a fix.
But it sure would be nice if we didn't have to overpower it like that to keep it working.
In TDE control center, its set 5,0,10 but that seems not to affect it, when it has failed the pheripherals/display/screensaver and display power management are all zeroed out or the checkboxes cleared. It appears is as if a zmalloc has gone astray? Under appearance/screensaver its set to start a slide show after 4 minutes. The memory of whatever it uses for the "elevator music for the eyeball" also seems transient, it switches to either a blank screen or some glx thing that burns up the cpu, again at random intervals that do not seem to correlate with the dpms settings failures.
Info, bug action, your pick. ;-)
Cheers, Gene Heskett
Cheers, Gene Heskett
Hi Gene!
You'll have to add a "xhost +" somewhere in your X11 session, otherwise it'll not work.
Nik
Am Freitag, 20. März 2015 schrieb Gene Heskett:
On Friday 20 March 2015 11:31:12 Gene Heskett wrote:
I recall I had a heck of a time in the past with the older kde, in keeping the monitors/screensaver set so it might show a few minutes of the screensaver of choice, and to powerdown the monitor after a few minutes of screen saver. But it can't remember those settings more than a week or so, so I just put a couple entries in my crontab:
*/1 * * * * * xset +dpms */1 * * * * * xset dpms 300 0 600
Actually this is wrong as it then is effectively * * * * * *, the star string s/b * */1 * * * * as it was doing it on the minute, but then cron was emailing me that it could not open display "", so I have now made it hourly, and added -display 0:0 after the xset to see if that works...
Gotta be a way to make this work. I would have and had always assumed that doing something from the crontab was exactly like my typing it into a terminal, so whats the deal with that? Why can't my crontab do anything I can type?
To see if refreshing its memory hourly will effect a fix.
But it sure would be nice if we didn't have to overpower it like that to keep it working.
In TDE control center, its set 5,0,10 but that seems not to affect it, when it has failed the pheripherals/display/screensaver and display power management are all zeroed out or the checkboxes cleared. It appears is as if a zmalloc has gone astray? Under appearance/screensaver its set to start a slide show after 4 minutes. The memory of whatever it uses for the "elevator music for the eyeball" also seems transient, it switches to either a blank screen or some glx thing that burns up the cpu, again at random intervals that do not seem to correlate with the dpms settings failures.
Info, bug action, your pick. ;-)
Cheers, Gene Heskett
Cheers, Gene Heskett
On Friday 20 March 2015 13:05:07 Dr. Nikolaus Klepp wrote:
Hi Gene!
You'll have to add a "xhost +" somewhere in your X11 session, otherwise it'll not work.
Nik
Something like this? Or as a separate command line? 00 * * * * * xhost + xsetp +dpms 01 * * * * * xhost + xset dpms 300 0 600 ?? etc...
Thanks Nic
Cheers, Gene Heskett
Am Freitag, 20. März 2015 schrieb Gene Heskett:
On Friday 20 March 2015 13:05:07 Dr. Nikolaus Klepp wrote:
Hi Gene!
You'll have to add a "xhost +" somewhere in your X11 session, otherwise it'll not work.
Nik
Something like this? Or as a separate command line? 00 * * * * * xhost + xsetp +dpms 01 * * * * * xhost + xset dpms 300 0 600 ?? etc...
Thanks Nic
Cheers, Gene Heskett
Hi Gene!
Not exactly :-)
In your TDE session start konsole and enter: $ xhost + access control disabled, clients can connect from any host
Your chrontab lines should be like before: 00 * * * * * xsetp +dpms 01 * * * * * xset dpms 300 0 600
But keep in mind, the "xhost +"-line has to be entered always when you start a TDE session :-)
Nik
On Friday 20 March 2015 13:21:32 Dr. Nikolaus Klepp wrote:
Am Freitag, 20. März 2015 schrieb Gene Heskett:
On Friday 20 March 2015 13:05:07 Dr. Nikolaus Klepp wrote:
Hi Gene!
You'll have to add a "xhost +" somewhere in your X11 session, otherwise it'll not work.
Nik
Something like this? Or as a separate command line? 00 * * * * * xhost + xsetp +dpms 01 * * * * * xhost + xset dpms 300 0 600 ?? etc...
Thanks Nic
Cheers, Gene Heskett
Hi Gene!
Not exactly :-)
In your TDE session start konsole and enter: $ xhost + access control disabled, clients can connect from any host
Your chrontab lines should be like before: 00 * * * * * xset +dpms 01 * * * * * xset dpms 300 0 600
But keep in mind, the "xhost +"-line has to be entered always when you start a TDE session :-)
So this is a candidate to add to my .bashrc? Or .profile?
Possibly with a " 2>&1 >/dev/null &" appended?
And if this works, then I also ought to be able to:
sudo synaptic
which I cannot do now because root cannot access my display and I had to setup a separate root password in order to run synaptic.
So theoretically I would not, if the "xhost +" was in effect, have had to setup a separate root password, a password that once set, cannot be deleted by any known means except by a bare metal reinstall. BTDT, twice, wheres my T-shirt? :)
Just to be able to run synaptic? Or package-manager? IMNSHO the suckage there is somewhere in the range of 10-41 Torr.
Me, Wanders off shaking head in bewilderment.
Thanks Nik.
Cheers, Gene Heskett
Am Freitag, 20. März 2015 schrieb Gene Heskett:
On Friday 20 March 2015 13:21:32 Dr. Nikolaus Klepp wrote:
Am Freitag, 20. März 2015 schrieb Gene Heskett:
On Friday 20 March 2015 13:05:07 Dr. Nikolaus Klepp wrote:
Hi Gene!
You'll have to add a "xhost +" somewhere in your X11 session, otherwise it'll not work.
Nik
Something like this? Or as a separate command line? 00 * * * * * xhost + xsetp +dpms 01 * * * * * xhost + xset dpms 300 0 600 ?? etc...
Thanks Nic
Cheers, Gene Heskett
Hi Gene!
Not exactly :-)
In your TDE session start konsole and enter: $ xhost + access control disabled, clients can connect from any host
Your chrontab lines should be like before: 00 * * * * * xset +dpms 01 * * * * * xset dpms 300 0 600
But keep in mind, the "xhost +"-line has to be entered always when you start a TDE session :-)
So this is a candidate to add to my .bashrc? Or .profile?
Possibly with a " 2>&1 >/dev/null &" appended?
And if this works, then I also ought to be able to:
sudo synaptic
which I cannot do now because root cannot access my display and I had to setup a separate root password in order to run synaptic.
So theoretically I would not, if the "xhost +" was in effect, have had to setup a separate root password, a password that once set, cannot be deleted by any known means except by a bare metal reinstall. BTDT, twice, wheres my T-shirt? :)
Just to be able to run synaptic? Or package-manager? IMNSHO the suckage there is somewhere in the range of 10-41 Torr.
Me, Wanders off shaking head in bewilderment.
Thanks Nik.
Cheers, Gene Heskett
Hi Gene!
I have things like these in .xinitrc - but as .xinitrc is not executed by TDE, you'll need to add "xhost +" to .xinitrc and add a shortcut to the Autostart folder:
eg.: ~/.xinitrc
#!/bin/bash xhost +
Then make .xinitrc executeable. Now add a shortcut:
$ konqueror ~/.trinity/Autostart right mouse button, "Add shortcut to program", select ~/.xinitrc as the executable.
Now let's test it. Log out of TDE and log in again. Change to a console <ctrl>+<shift>+<F1> and type:
$ xset -display=:0 +dpms
Nik
On Friday 20 March 2015 13:55:53 Dr. Nikolaus Klepp wrote:
Am Freitag, 20. März 2015 schrieb Gene Heskett:
On Friday 20 March 2015 13:21:32 Dr. Nikolaus Klepp wrote:
Am Freitag, 20. März 2015 schrieb Gene Heskett:
On Friday 20 March 2015 13:05:07 Dr. Nikolaus Klepp wrote:
Hi Gene!
You'll have to add a "xhost +" somewhere in your X11 session, otherwise it'll not work.
Nik
Something like this? Or as a separate command line? 00 * * * * * xhost + xsetp +dpms 01 * * * * * xhost + xset dpms 300 0 600 ?? etc...
Thanks Nic
Cheers, Gene Heskett
Hi Gene!
Not exactly :-)
In your TDE session start konsole and enter: $ xhost + access control disabled, clients can connect from any host
Your chrontab lines should be like before: 00 * * * * * xset +dpms 01 * * * * * xset dpms 300 0 600
But keep in mind, the "xhost +"-line has to be entered always when you start a TDE session :-)
So this is a candidate to add to my .bashrc? Or .profile?
Possibly with a " 2>&1 >/dev/null &" appended?
And if this works, then I also ought to be able to:
sudo synaptic
which I cannot do now because root cannot access my display and I had to setup a separate root password in order to run synaptic.
So theoretically I would not, if the "xhost +" was in effect, have had to setup a separate root password, a password that once set, cannot be deleted by any known means except by a bare metal reinstall. BTDT, twice, wheres my T-shirt? :)
Just to be able to run synaptic? Or package-manager? IMNSHO the suckage there is somewhere in the range of 10-41 Torr.
Me, Wanders off shaking head in bewilderment.
Thanks Nik.
Cheers, Gene Heskett
Hi Gene!
I have things like these in .xinitrc - but as .xinitrc is not executed by TDE, you'll need to add "xhost +" to .xinitrc and add a shortcut to the Autostart folder:
eg.: ~/.xinitrc
#!/bin/bash xhost +
Then make .xinitrc executeable. Now add a shortcut:
But would this not be per xsession startup=reboot? It does not remember those settings that long. Hence the need to remind it via a crontab entry. Current up time is 19d 16:29 and it forgot it several days ago.
$ konqueror ~/.trinity/Autostart right mouse button, "Add shortcut to program", select ~/.xinitrc as the executable.
Now let's test it. Log out of TDE and log in again. Change to a console <ctrl>+<shift>+<F1> and type:
$ xset -display=:0 +dpms
Nik
Anyway, I think I have it sussed, so thank you's to both Nik and Gerhardt. :)
Cheers, Gene Heskett
sorry, Typo in last mail, please see below!
Am Freitag, 20. März 2015 schrieb Gene Heskett:
On Friday 20 March 2015 13:05:07 Dr. Nikolaus Klepp wrote:
Hi Gene!
You'll have to add a "xhost +" somewhere in your X11 session, otherwise it'll not work.
Nik
Something like this? Or as a separate command line? 00 * * * * * xhost + xsetp +dpms 01 * * * * * xhost + xset dpms 300 0 600 ?? etc...
Thanks Nic
Cheers, Gene Heskett
Hi Gene!
Not exactly :-)
In your TDE session start konsole and enter: $ xhost + access control disabled, clients can connect from any host
Your chrontab lines should be like before: 00 * * * * * xset -display=:0 +dpms 01 * * * * * xset -display=:0 dpms 300 0 600
But keep in mind, the "xhost +"-line has to be entered always when you start a TDE session :-)
Nik
On Friday 20 March 2015, Dr. Nikolaus Klepp wrote:
Hi Gene!
Not exactly :-)
In your TDE session start konsole and enter: $ xhost + access control disabled, clients can connect from any host
Your chrontab lines should be like before: 00 * * * * * xset -display=:0 +dpms 01 * * * * * xset -display=:0 dpms 300 0 600
But keep in mind, the "xhost +"-line has to be entered always when you start a TDE session :-)
So you might want to put it into .bashrc file (in .profile, X might not be running)
Gerhard
On Friday 20 March 2015 13:05:07 Dr. Nikolaus Klepp wrote:
Hi Gene!
You'll have to add a "xhost +" somewhere in your X11 session, otherwise it'll not work.
Nik
Humm, that falls over and chokes in its oatmeal too.
From a konsole: gene@coyote:/etc/apache2/mods-available$ xhost + access control disabled, clients can connect from any host
Ooookkaaaayy. If thats true, why can't cron do it?
Wheezy gets more and more confused. Or I do, but I like the former argument lots better. :) Saves face at my age yadda yadda.
So what do I do now?
Thanks Nik.
Cheers, Gene Heskett
On Friday 20 March 2015, Gene Heskett wrote:
From a konsole: gene@coyote:/etc/apache2/mods-available$ xhost + access control disabled, clients can connect from any host
Ooookkaaaayy. If thats true, why can't cron do it?
Wheezy gets more and more confused. Or I do, but I like the former argument lots better. :) Saves face at my age yadda yadda.
because the command has to run on that X session to be effective, cron is not running on the X session, it's running in the background not connected to any X session.
Gerhard
On Friday 20 March 2015 13:38:37 Gerhard Zintel wrote:
On Friday 20 March 2015, Gene Heskett wrote:
From a konsole: gene@coyote:/etc/apache2/mods-available$ xhost + access control disabled, clients can connect from any host
Ooookkaaaayy. If thats true, why can't cron do it?
Wheezy gets more and more confused. Or I do, but I like the former argument lots better. :) Saves face at my age yadda yadda.
because the command has to run on that X session to be effective, cron is not running on the X session, it's running in the background not connected to any X session.
Gerhard
So I put it in my .bashrc. It works, AND I can now run a sudo command as before all this denial of service started that made me set a root password. But the only way to get rid of a root password is a bare metal reinstall.
Sigh...
Cheers, Gene Heskett
On Friday 20 March 2015, Gene Heskett wrote:
password. But the only way to get rid of a root password is a bare metal reinstall.
surely not. I don't know the answer by heart, but editing in /etc/passwd or /etc/shadow, or other files for sure gives you the possibility to get rid of the password.
Here seems to be an answer to your question: http://www.debianadmin.com/enable-and-disable-ubuntu-root-password.html
In short: --- snip --- If you want to disable root account in ubuntu you need to lock the root account by using the following command
$sudo passwd -l root --- snip ---
I've not tested it though
Gerhard
On Friday 20 March 2015 14:34:59 Gerhard Zintel wrote:
On Friday 20 March 2015, Gene Heskett wrote:
password. But the only way to get rid of a root password is a bare metal reinstall.
surely not. I don't know the answer by heart, but editing in /etc/passwd or /etc/shadow, or other files for sure gives you the possibility to get rid of the password.
Here seems to be an answer to your question: http://www.debianadmin.com/enable-and-disable-ubuntu-root-password.htm l
In short: --- snip --- If you want to disable root account in ubuntu you need to lock the root account by using the following command
$sudo passwd -l root --- snip ---
I just tried that, an unlike the last time, sudo still works. That could be precisely be the answer.
I've not tested it though
Gerhard
I just did test, but what that -l does is change the expiry time, so I've no clue atm how long it might still be good for.
Thanks Gerhard.
Cheers, Gene Heskett
On Friday 20 March 2015, Gene Heskett wrote:
On Friday 20 March 2015 13:38:37 Gerhard Zintel wrote: password. But the only way to get rid of a root password is a bare metal reinstall.
and from
$ man passwd
-l, --lock Lock the password of the named account. This option disables a password by changing it to a value which matches no possible encrypted value (it adds a ´!´ at the beginning of the password).
Note that this does not disable the account. The user may still be able to login using another authentication token (e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's expire date to Jan 2, 1970).
Users with a locked password are not allowed to change their password.
On Friday 20 March 2015 14:17:30 Gene Heskett wrote:
On Friday 20 March 2015 13:38:37 Gerhard Zintel wrote:
On Friday 20 March 2015, Gene Heskett wrote:
From a konsole: gene@coyote:/etc/apache2/mods-available$ xhost + access control disabled, clients can connect from any host
Ooookkaaaayy. If thats true, why can't cron do it?
Wheezy gets more and more confused. Or I do, but I like the former argument lots better. :) Saves face at my age yadda yadda.
because the command has to run on that X session to be effective, cron is not running on the X session, it's running in the background not connected to any X session.
Gerhard
So I put it in my .bashrc. It works, AND I can now run a sudo command as before all this denial of service started that made me set a root password. But the only way to get rid of a root password is a bare metal reinstall.
Sigh...
Cheers, Gene Heskett
As a delayed PS here, cron, despite my best incantations, is still sending me failure emails, cannot open display 0:0.
Humm, thats is a direct command from crontab to xset. Theory: If I put an sh in front of the command, will that sh then see the results of the xhost + command in the .bashrc?
Worth a try I think.
Cheers, Gene Heskett
On Friday 20 March 2015 22:13:50 Gene Heskett wrote:
On Friday 20 March 2015 14:17:30 Gene Heskett wrote:
On Friday 20 March 2015 13:38:37 Gerhard Zintel wrote:
On Friday 20 March 2015, Gene Heskett wrote:
From a konsole: gene@coyote:/etc/apache2/mods-available$ xhost + access control disabled, clients can connect from any host
Ooookkaaaayy. If thats true, why can't cron do it?
Wheezy gets more and more confused. Or I do, but I like the former argument lots better. :) Saves face at my age yadda yadda.
because the command has to run on that X session to be effective, cron is not running on the X session, it's running in the background not connected to any X session.
Gerhard
So I put it in my .bashrc. It works, AND I can now run a sudo command as before all this denial of service started that made me set a root password. But the only way to get rid of a root password is a bare metal reinstall.
Sigh...
Cheers, Gene Heskett
As a delayed PS here, cron, despite my best incantations, is still sending me failure emails, cannot open display 0:0.
Humm, thats is a direct command from crontab to xset. Theory: If I put an sh in front of the command, will that sh then see the results of the xhost + command in the .bashrc?
Worth a try I think.
And fails exactly the same, my crontab entry cannot access my 0:0 display. Help!
Thanks all.
Cheers, Gene Heskett
Am Samstag, 21. März 2015 schrieb Gene Heskett:
On Friday 20 March 2015 22:13:50 Gene Heskett wrote:
On Friday 20 March 2015 14:17:30 Gene Heskett wrote:
On Friday 20 March 2015 13:38:37 Gerhard Zintel wrote:
On Friday 20 March 2015, Gene Heskett wrote:
From a konsole: gene@coyote:/etc/apache2/mods-available$ xhost + access control disabled, clients can connect from any host
Ooookkaaaayy. If thats true, why can't cron do it?
Wheezy gets more and more confused. Or I do, but I like the former argument lots better. :) Saves face at my age yadda yadda.
because the command has to run on that X session to be effective, cron is not running on the X session, it's running in the background not connected to any X session.
Gerhard
So I put it in my .bashrc. It works, AND I can now run a sudo command as before all this denial of service started that made me set a root password. But the only way to get rid of a root password is a bare metal reinstall.
Sigh...
Cheers, Gene Heskett
As a delayed PS here, cron, despite my best incantations, is still sending me failure emails, cannot open display 0:0.
Humm, thats is a direct command from crontab to xset. Theory: If I put an sh in front of the command, will that sh then see the results of the xhost + command in the .bashrc?
Worth a try I think.
And fails exactly the same, my crontab entry cannot access my 0:0 display. Help!
Thanks all.
Cheers, Gene Heskett
Hi Gene!
Your .bashrc is not evaluated by the TDE session till you open a terminal. That's why I siggested to use the Autostart-shortcut :-)
Nik
On Saturday 21 March 2015 07:10:54 Dr. Nikolaus Klepp wrote:
Am Samstag, 21. März 2015 schrieb Gene Heskett:
On Friday 20 March 2015 22:13:50 Gene Heskett wrote:
On Friday 20 March 2015 14:17:30 Gene Heskett wrote:
On Friday 20 March 2015 13:38:37 Gerhard Zintel wrote:
On Friday 20 March 2015, Gene Heskett wrote:
From a konsole: gene@coyote:/etc/apache2/mods-available$ xhost + access control disabled, clients can connect from any host
Ooookkaaaayy. If thats true, why can't cron do it?
Wheezy gets more and more confused. Or I do, but I like the former argument lots better. :) Saves face at my age yadda yadda.
because the command has to run on that X session to be effective, cron is not running on the X session, it's running in the background not connected to any X session.
Gerhard
So I put it in my .bashrc. It works, AND I can now run a sudo command as before all this denial of service started that made me set a root password. But the only way to get rid of a root password is a bare metal reinstall.
Sigh...
Cheers, Gene Heskett
As a delayed PS here, cron, despite my best incantations, is still sending me failure emails, cannot open display 0:0.
Humm, thats is a direct command from crontab to xset. Theory: If I put an sh in front of the command, will that sh then see the results of the xhost + command in the .bashrc?
Worth a try I think.
And fails exactly the same, my crontab entry cannot access my 0:0 display. Help!
Thanks all.
Cheers, Gene Heskett
Hi Gene!
Your .bashrc is not evaluated by the TDE session till you open a terminal. That's why I siggested to use the Autostart-shortcut :-)
:) OTOH, my reboot normally starts at least 2 nests of mutitab terminals and kmail.
So that I think in my case, is a non-issue.
And, following Petters suggestion to put it all in an ececutable script in my own bin dir looks as if it will work. cron accepts that, and I can exec it, I'll know if cron can do it in 2 more minutes.
Thank you Nik.
Cheers, Gene Heskett
-
Dr. Nikolaus Klepp -
Gene Heskett -
Gerhard Zintel