Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy

[saintless]

Hi, Sergey.
I am also happy XFCE speaks Russian
Thank you!

Toni

[sklimkin]

Hi All!

Cleaning xsession-errors
In the user's home directory there is a file. Xsession-errors which is appended STDERR output of applications running in the GUI.

The problem is that. Xsession-errors file only knows how to "grow" and need to flush it out somehow or deny Append.

Provides a global way for all users through editing script Xsession, performed by startx or desktop manager such as xdm, gdm, kdm.

patch:

Code: Select all

debian:/etc/X11# diff -u /etc/X11/Xsession.orig  /etc/X11/Xsession
--- /etc/X11/Xsession.orig      2007-11-19 04:50:31.000000000 +0300
+++ /etc/X11/Xsession   2007-11-19 04:50:56.000000000 +0300
@@ -91,7 +91,7 @@
   errormsg "unable to create X session log/error file; aborting."
 fi

-exec >>"$ERRFILE" 2>&1
+exec >"$ERRFILE" 2>&1

 echo "$PROGNAME: X session started for $LOGNAME at $(date)

link (Russian): http://avreg.net/howto_icewm.html

Sergey.

[fredx181]

Hi Sergey, thanks for the keyboard switch tips.

Hi Toni
About the changes-EXIT I realize that I was to fast with finding a solution, it will however work when exiting as puppy user but it's not foul-proof when other users are created also.
I will come later with "real" solution.

Fred

[mcewanw]

I'm not sure if the second "wait" above is important - I'll try without it.

EDIT: Actually, removing the & from the end of line: /usr/bin/rox -p ... pinbd, and also removing both 'wait' commands seemed to work for me too. Result:

/opt/bin/start-up

Code: Select all

#!/bin/bash
/usr/bin/rox -p /root/.config/rox.sourceforge.net/ROX-Filer/pinbd
ls /root/Startup/* | while read J
do
   "$J" &
done

But as I say, I haven't tested this much for reliability yet. Perhaps (?) it is more reliable with the wait(s) but I'd try without first.

In regard to my post above at http://www.murga-linux.com/puppy/viewto ... 525#756525

Further testing suggests that a shell "wait" is required after running rox pinbd &, which waits until that background command has completed finished before continuing with the rest of the script. Without it, things are usually fine, but occasionally an annoying small X window will appear over the xterm icon. I have had no problem at all so far with the following in /opt/bin/start-up in conjunction with the rest of the scheme I described at http://www.murga-linux.com/puppy/viewto ... 525#756525:

Code: Select all

#!/bin/bash
/usr/bin/rox -p /root/.config/rox.sourceforge.net/ROX-Filer/pinbd &
wait
ls /root/Startup/* | while read J
do
   "$J" &
done

There are plenty of ways of re-arranging these startup scripts, but that wait after "rox ... pinbd &" seems to be the key thing.

[sunburnt]

I have WallPapers gui working, but there`s a snag in DebianDog. Root has 1 process and puppy has 2.
The first puppy process for wallpapers is the same process number as the process that was running in root.
And sometimes after switching back and forth between root and puppy, there will be 3 process showing.
# It looks like the wallpaper`s process is not terminated when logging out. Are $HOME/Startup apps killed.?

Using ps is trouble because it acts differently in different Linuxes, and it`s rather unreliable in general.
But I know of no other way to tell if wallpapers is running. This is important for starting and stopping it.
And if it has 2 or 3 processes running, then there`s no way to tell which one is relevant. Kill all of them.?

# I`m guessing... Root stays running when logged in as puppy.? So kill the last process in the list.?

I wanted it to detect what app runs the desktop, but I gave up, both Rox and IceWM run at the same time.
.

[mcewanw]

I have WallPapers gui working, but there`s a snag in DebianDog. Root has 1 process and puppy has 2

Best way could be to save the wallpaper gui pid in an exported variable (e.g. export WALLPAPER_PID=$!) when it is first started and then to kill the pid at logout. Not quite so good would be to save the pid to a file for killiing at logout, but that isn't foolproof. Problem really is finding what iceWM calls at logout though I did come across something aboug "Logout" in one of its config files (but would have to recheck and find it again).

EDIT: in /usr/share/icewm/preferences there is a line:

Code: Select all

#  Command to start logout
# LogoutCommand=""

I've been looking at that for other reasons, but I haven't tried seeing if it can be used to do anything relevant at logout yet; your guess is as good as mine till tried :-) Not sure if /etc/bash.logout or .bash_logout in users home directory would be usefully relevant here or if some other script is currently run on logout. Would be good to know. It would probably be best if it was a more general purpose logout script that didn't rely on bash being the startup shell - that's why I was thinking of iceWM behaviour at logout.

[sunburnt]

A good Q is what methods are used to shutdown processes at logout.?

I believe the dir. /etc/init.d has a master script that does (App) start and (App) stop.
This may be the best place to boot start WallPapers. But how to do the "stop".?
Maybe write to the start/stop file itself, there`s one less file to read that way.
Delete last 2 lines, and write a new "kill pid" line to the start/stop script like this:
sed -i '$d;$d' /etc/init.d/wallpapers ; echo "kill $$" >> /etc/init.d/wallpapers

Code: Select all

#!/bin/sh
case "$1" in
	start|restart)
		xxxxxxxxxxx
		xxxxxxxxxxx
		exit ;;
	stop)
		xxxxxxx ;;
esac

kill 12345

I`ve always thought that adding env. variables for this stuff is a good idea too.
$PID_KILL = A list to add pids to for killing at logout or shutdown.

# At least with both of these methods you know where to go and what to do to kill it.
.

[saintless]

Hi, all.
I will try all your suggestions in the next days.

Fred, I will wait for your word on save=EXIT

Terry, I'm sure root stays active when puppy log in. When I logout from puppy and type exit I get stright logged in as root.

William, I will try your suggestions after rereading your posts careful.

Sergey, I will check out your suggestion about xsession

Still much to fix for the beta.

Toni

[mcewanw]

I believe the dir. /etc/init.d has a master script that does (App) start and (App) stop.
This may be the best place to boot start WallPapers.
.

Aahhh, I forgot about that - you are quite right, a stop script in there should be involved to keep with the way Debian does it.

[saintless]

Hi, Terry, William.
Here is what I see about wallpapers.d process in lxtask:
First boot as root I see only one wallpapers.d in lxtask
Logout and login as puppy I see only one wallpapers.d owned by puppy
Logout from puppy login and startx as root I see 2 wallpapers.d owned by root and from time to time one or two more wallpapers.d appears for a few seconds in lxtask. + wmctrl shows up from time to time.

Is it this what you see also, Terry?

Toni

[saintless]

EDIT: in /usr/share/icewm/preferences there is a line:

Code: Select all

#  Command to start logout
# LogoutCommand=""

Hi, William.
I don't know if this helps but in porteus-wheezy Fred uses this to add command to point obshutdown on logout click and it works.

Toni

[mcewanw]

EDIT: in /usr/share/icewm/preferences there is a line:

Code: Select all

#  Command to start logout
# LogoutCommand=""

Hi, William.
I don't know if this helps but in porteus-wheezy Fred uses this to add command to point obshutdown on logout click and it works.

Toni

Yes, I had it in mind that it could be used like that and was/am planning to think about how it could be used to stop a normal user being able to drop down to a root shell. But I'm not sure if that can be prevented with current scheme where root is automatically logged in via inittab during booting. Still summer here, so too many distractions...

One other thing is that I have lost track of what the most recent Debian Light download is - I may be using it, but I'm not sure. Could you point me to the post where most recent download is, or should I just visit smokey's download site and see what is there? I wanted to also check out the wallpaper issue. Lxtask is a great tool - that's what I used to work out how icewm-session was being started up (checked back through the parent PID's) - except I did also have to read through the relevant scripts to piece it all together.

[saintless]

This is the working module for testing. Just replace 01-filesystem.squashfs with this one.
http://smokey01.com/saintless/Light-Whe ... 3.squashfs
Wallpapers separate for user are not included there yet.
I will continue updating one module for testing the changes. This way will be easier for all.
DebianDog-PorteusDog.iso is most for me and Fred to see how we can make it work best. Wallpapers separate for user are incuded here.

Toni

[saintless]

I'm not sure if the second "wait" above is important - I'll try without it.

EDIT: Actually, removing the & from the end of line: /usr/bin/rox -p ... pinbd, and also removing both 'wait' commands seemed to work for me too. Result:

/opt/bin/start-up

Code: Select all

#!/bin/bash
/usr/bin/rox -p /root/.config/rox.sourceforge.net/ROX-Filer/pinbd
ls /root/Startup/* | while read J
do
   "$J" &
done

But as I say, I haven't tested this much for reliability yet. Perhaps (?) it is more reliable with the wait(s) but I'd try without first.

In regard to my post above at http://www.murga-linux.com/puppy/viewto ... 525#756525

Further testing suggests that a shell "wait" is required after running rox pinbd &, which waits until that background command has completed finished before continuing with the rest of the script. Without it, things are usually fine, but occasionally an annoying small X window will appear over the xterm icon. I have had no problem at all so far with the following in /opt/bin/start-up in conjunction with the rest of the scheme I described at http://www.murga-linux.com/puppy/viewto ... 525#756525:

Code: Select all

#!/bin/bash
/usr/bin/rox -p /root/.config/rox.sourceforge.net/ROX-Filer/pinbd &
wait
ls /root/Startup/* | while read J
do
   "$J" &
done

There are plenty of ways of re-arranging these startup scripts, but that wait after "rox ... pinbd &" seems to be the key thing.

Hi, William.
Unfortunately it is not working the same for me
With the original configuration and gzip compression it works withou issue on 128 Mb computer.
I testes exactly as you suggest and I get this annoying small X window appear over the xterm icon all the time. Even if I use gzip compression instead xz for the squashfs module.
At least for my hardware it creates more problems.
I don't mind to change it the way you suggest but I doubt someone else test on old hardware like mine. If it works on my hardware it should work on any. I'm sure Fred has the same problem because he test 3 modules with maximum xz compression loaded on boot instead of only one module.

Some thoughts to all interested from DebianDog:
Even if we make it work well now we will continue to load more and more graphic improovemnts and this problem will appear again even for computer with 1 Gb RAM.
At the beginning we started with one desktop wallpaper and 2 desktops. Then the system works fast on very-low-ram computer.
Then we started desktop-drive-icons and pup-volume-monitor on boot.
Then we added rox pinboard with icons.
Then we added volumeicon on boot.
Then we added /root/Startup folder like in puppy on boot.
Then Terry made 4 different wallpapers for 4 desktops with option for more desktops with different wallpapers.
Then he gave us option for different walppaers for every user and all this is loaded on boot.
All this options are very good and I like them, but for me they should stay only options to be decided from user to use or not.

We should not autostart on boot so many processes. Instead we can make them easy to be started from menu or desktop icons.
This is my opinion about this problem and the only real solution to this annoying small X window appear over the xterm icon. This will also save us all many hours work lost in such small fixes.

Any thoughts and suggestions?

Toni

[mcewanw]

Hi, William.
Unfortunately it is not working the same for me :(

Oh well, that's a pity. Can only really find a solution, if there is one, if we can determine what it is that actually causes that annoying xwindow to appear. Strange that the default startup scripts often result in that xwindow on my machine, whereas the scripts I described don't... Did you also try /opt/bin/start-up with two waits as below?

Code: Select all

#!/bin/bash
/usr/bin/rox -p /root/.config/rox.sourceforge.net/ROX-Filer/pinbd &
wait
ls /root/Startup/* | while read J
do
   "$J" &
   wait
done

As far as your other comments go, yes, I agree, you should limit default startup processes for normal users.

But to be Puppy-like you surely need the default root login to gui to provide equal facilities to that expected on Puppy, which includes desktop drive icons, volume control and so on.

As far as multiuser is concerned, we need to test all these facilities (and applications) are able to work correctly as a normal user (some via sudo) but the available facilities/tray items and so on, don't, I feel, all need to be provided by default.

The most important thing, I feel, when it comes to multiuser capability, is that nothing we do breaks that capability or makes it insecure. And any installed applications should be tested as working as a normal user (or they are basically badly designed and no use for example on full Debian systems).

There are however not many such apps being considered for the proposed default iso release to worry about at the moment - the exception is probably the wallpaper app, which has to be very carefully constructed so as not to consume too many resources, and to be able to be run many times (by different logged in users) and also to be able to carefully clean up after itself. Perhaps we shouldn't care too much about different wallpapers for every desktop for every possible user logged in at the moment - just have something more simple that works for root user logged in and less desktops by default. Enhancements to that could be considered later? But bear in mind that, as you say, very few users will be running this on a very low powered machine with only 128MB RAM!

Personally, I don't care if nothing fancy is provided by the gui - as long as the basic system is working correctly in single and multiuser mode. Resources/facilities can indeed always be offered as options, some being selectable by the normal user, and others set up for them (following granted requests) by root user. It isn't about making everything available for everyone - but it is about making it all work as and when required.

[saintless]

Did you also try /opt/bin/start-up with two waits as below?

Code: Select all

#!/bin/bash
/usr/bin/rox -p /root/.config/rox.sourceforge.net/ROX-Filer/pinbd &
wait
ls /root/Startup/* | while read J
do
   "$J" &
   wait
done

Hi, William
Just tested - at least this way it works well with gzip compression. I will test it with xz compression today ptoper.

But bear in mind that, as you say, very few users will be running this on a very low powered machine with only 128MB RAM!

I know and I have low-ram-on/off start menu option for this. It simple renames /root/.isewm/startup and restarts x.

It isn't about making everything available for everyone - but it is about making it all work as and when required.

I agree. The best is to make it work well with all extra loaded on boot. I start to think it is related to combination xterm -> icewm. I will do some testing today to be sure.

Toni

[mcewanw]

Even if we make it work well now we will continue to load more and more graphic improovemnts and this problem will appear again even for computer with 1 Gb RAM.
...
We should not autostart on boot so many processes. Instead we can make them easy to be started from menu or desktop icons.
This is my opinion about this problem and the only real solution to this annoying small X window appear over the xterm icon.

Hi Toni, It must be afternoon where you are, and early hours of the morning for me who is about to disappear till tomorrow...

But it would nevertheless be good to find out what exactly causes that "annoying small X window". It seems to be a timing issue (since it is often a bit random in occurrence) and system loading (compression techniques and so on) may well be effecting that. However, I feel there must be a way of starting processes in such a way that that small X does not occur, despite compression methods or loading on the system - that's why I was trying 'wait'.

William

[fredx181]

Hi Toni
Just for info:
About the "annoying small X window" I have no solution but I have puppy as autologin user in /etc/inittab and did a lot of reboots with savefile and it didn't show even once.
EDIT: I just mean running as puppy user I don't have this problem.

I found good solution for changes=EXIT when running as normal user but I need to know:
- Do you have any plans to make reboot/halt work for user without having to enter password?
- Do you like to use this? (see picture)
If you do I will add to new changes-EXIT archive.
It's script using yad and uses su (not sudo)
Got it from here (Graphical frontend for su):
http://code.google.com/p/yad/wiki/Examples
It depends on "empty-expect" package (111Kb only)
Say name of script is "pass" and it's in PATH you can put at start of e.g. frisbee:

Code: Select all

[ "`whoami`" != "root" ] && exec pass ${0}

Fred

[fredx181]

Hi Toni, William
Maybe this helps:
http://www.linuxformat.com/forums/viewtopic.php?p=99350

Fred

[saintless]

Hi, Fred

EDIT: I just mean running as puppy user I don't have this problem.

I guess it is because you have much more RAM and some processes are not started for user? I don't know.
I have the same issue when I boot as user with the squashfs module with changed inittab I made for William.

- Do you have any plans to make reboot/halt work for user without having to enter password?

No, user account will be able to reboot only by typing root password.

- Do you like to use this? (see picture)

Yes, I like it.
But I think we can't use it for reboot and shutdown this way as you suggest for frisbee. I need to check this again.

Code: Select all

[ "`whoami`" != "root" ] && exec pass ${0}

Maybe this helps:
http://www.linuxformat.com/forums/viewtopic.php?p=99350

Thanks, Fred.
This makes clear it is really timing issue. If I put sleep 3 instead sleep 1 in /etc//icewm/startup it also fixes this. I'm experimenting with the startup configuration from William now. One is sure - we have to make the startup appearing slower than it is now and I don't like this.
Maybe if we put the sleep or wait command only for frisbee and volumeicon it will be enough? Seems the issue is only with taskbar.

Toni