antiX-16-b2.1-full available - Page 10

Dave · posted: 2016-05-19 03:27

@ SamK

Could you try the following for what I think is the version of desktop-session in antiX16 ( I do not have the original as I have been working out an update and as such am going off of github. ) I cannot seem to make the problem come about (with the version I have at least)
Each one would require a check I think.
Also make sure that the NOTIFICATION_DIALOG is set to false in desktop-session.conf

Also perhaps ~/.desktop-session/log might have some indication in it... maybe not....

1) comment out line 84

Code: Select all

#  . /usr/local/lib/desktop-session/desktop-session-xdg-dirs.sh

2) line 87, 88, 89

Code: Select all

 # if [ -f"$xmodmap_config" ]; then
 #      xmodmap"$xmodmap_config"
 # fi

3) line 141 + 136, 137, 138

Code: Select all

#if [ -f"~/.$wm/startup.disabled" ]; then
#    mv ~/.$wm/startup.disabled ~/.$wm/startup
#fi
.......

#mv ~/.$wm/startup ~/.$wm/startup.disabled
[code]

4) comment out lines 93 - 99
[code]
#test -r $config || continue
#if ! /bin/bash -n $config; then
#    shout"Errors in $config, cannot load $config."
#    shout"desktop-session may crash"
#    shout"Copy default config from /usr/local/share/desktop-session/desktop-session.conf"
# continue
# fi
[code]

5) change line 128 by removing echo_cmd
[code]
$WM_EXEC
[code]

SamK · posted: 2016-05-19 09:12

Dave wrote:Could you try the following...

Dave wrote:Also make sure that the NOTIFICATION_DIALOG is set to false in desktop-session.conf

Code: Select all

cat .desktop-session/desktop-session.conf | grep ^NOTIFICATION_DIALOG
NOTIFICATION_DIALOG="false"

Dave wrote:Also perhaps ~/.desktop-session/log might have some indication in it... maybe not....

From a cold boot while IceWM monitors and clock frozen.
nosavestate desktop=icewm vga=791 lang=en_GB quiet
To keep it clean, log retrieved via separate login on tty2

Code: Select all

cat .desktop-session/log
desktop-session: started Thu 19 May 08:27:53 BST 2016 start_time: 33.00
desktop-session: pid: 3552
desktop-session: logging to: /home/demo/.desktop-session/log
desktop-session: launch  @ 3318
desktop-session: look up executable for icewm
desktop-session: save desktop code: icewm
desktop-session: Exporting desktop Variables:
desktop-session: DESKTOP_SESSION_CODE=icewm
desktop-session: DESKTOP_SESSION_WM=icewm
desktop-session: DESKTOP_SESSION_IM=none
desktop-session: Location does not exist; making
desktop-session: Location does not exist; making
desktop-session: run: /usr/bin/icewm-session
desktop-session: Checking for running window manager @ 3331
icewm-session: using /home/demo/.icewm for private configuration files
icewm-session: Warning: File still open: fd=3, target='/var/log/slim.log' (missing FD_CLOEXEC?)
icewm-session: Warning: Closing file descriptor: 3
icewm-session: Warning: File still open: fd=3, target='/var/log/slim.log' (missing FD_CLOEXEC?)
icewm-session: Warning: Closing file descriptor: 3
icewm-session: Warning: File still open: fd=3, target='/var/log/slim.log' (missing FD_CLOEXEC?)
icewm-session: Warning: Closing file descriptor: 3
icewm-session: Warning: File still open: fd=3, target='/var/log/slim.log' (missing FD_CLOEXEC?)
icewm-session: Warning: Closing file descriptor: 3
icewmbg: using /home/demo/.icewm for private configuration files
icewmtray: using /home/demo/.icewm for private configuration files
IceWM: using /home/demo/.icewm for private configuration files
desktop-session: Window manager running or setup forced, setting up desktop @ 3389
desktop-session: Delaying session startup by 2 seconds
desktop-session: run: desktop-session-wallpaper
desktop-session: run: desktop-menu --write-out-global
Writing Menu: fluxbox
Writing Menu: icewm
Writing Menu: jwm
/usr/local/bin/desktop-session: line 170: / etc/desktop-session/file_compare: No such file or directory
desktop-session: run: /home/demo/.desktop-session/startup &
desktop-session: run: conky
Conky: forked to background, pid is 3775
desktop-session: run: xset dpms 3600 3600 3600 s 3600 3600

Conky: desktop window (81) is root window
Conky: window type - normal
Conky: drawing to created window (0x800001)
desktop-session: run: wmctrl -F -r Conky (antix1) -b add,below
Conky: drawing to double buffer
desktop-session: Running first time run script
desktop-session: run: /usr/local/lib/desktop-session/first-run-script

** (volumeicon:3772): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
icewmbg: MappingNotify
IceWM: MappingNotify

Appended to above log after manually restarting IceWM via antiX menu

Code: Select all

IceWM: using /home/demo/.icewm for private configuration files
icewmbg: MappingNotify
IceWM: MappingNotify

Dave wrote:1) comment out line 84
Code: Select all
#  . /usr/local/lib/desktop-session/desktop-session-xdg-dirs.sh

From cold boot
nosavestate desktop=icewm vga=791 persist_root lang=en_GB quiet
Result
Clock: Frozen showing incorrect time
Monitors: Frozen

Restart IceWM via antiX Menu, or Menu-->Logout-->Restart Session
Result
Clock: Shows correct time
Monitors: Works

Change reverted

Dave wrote:2) line 87, 88, 89
Code: Select all
# if [ -f"$xmodmap_config" ]; then
#      xmodmap"$xmodmap_config"
# fi

From cold boot
nosavestate desktop=icewm vga=791 persist_root lang=en_GB quiet
Result
Clock: Frozen showing incorrect time
Monitors: Frozen

Restart IceWM via antiX Menu, or Menu-->Logout-->Restart Session
Result
Clock: Shows correct time
Monitors: Works

Changes reverted

Dave wrote:3) line 141 + 136, 137, 138

Code: Select all

#if [ -f"~/.$wm/startup.disabled" ]; then
# mv ~/.$wm/startup.disabled ~/.$wm/startup
#fi
.......

#mv ~/.$wm/startup ~/.$wm/startup.disabled

From cold boot
nosavestate desktop=icewm vga=791 persist_root lang=en_GB quiet
Result
During boot up while loading slim, error message Failed to execute login command
Slim login screen displayed
Attempt to login as demo, error message Failed to execute login command
Cycle repeats at each login attempt

Attempt to enter reboot command in slim login screen
Dropped to text login screen
Login as root
As root enter reboot command

Changes reverted

Dave wrote:4) comment out lines 93 - 99

Code: Select all

#test -r $config || continue
#if ! /bin/bash -n $config; then
# shout"Errors in $config, cannot load $config."
# shout"desktop-session may crash"
# shout"Copy default config from /usr/local/share/desktop-session/desktop-session.conf"
# continue
# fi

From cold boot
nosavestate desktop=icewm vga=791 persist_root lang=en_GB quiet
Result
Clock: Frozen showing incorrect time
Monitors: Frozen

Restart IceWM via antiX Menu, or Menu-->Logout-->Restart Session
Result
Clock: Shows correct time
Monitors: Works

Changes reverted

Dave wrote:5) change line 128 by removing echo_cmd
Code: Select all
$WM_EXEC

From cold boot
nosavestate desktop=icewm vga=791 persist_root lang=en_GB quiet
Result
Clock: Frozen showing incorrect time
Monitors: Frozen

Restart IceWM via antiX Menu, or Menu-->Logout-->Restart Session
Result
Clock: Shows correct time
Monitors: Works

Changes reverted

Dave · posted: 2016-05-19 11:09

Hmm. What are the two lines used in slim.conf when desktop-session is enabled and disabled?

Is there anything in ~ / . xsession-errors when it is working without desktop-session being used?

Does waiting for a minute or two before logging in have any change on the outcome?

Also could have run
Ps -ef | grep -i 'ice'
When it is working and when it is not? I do not know if that will tell anything but maybe if the processes are orphaned.

SamK · posted: 2016-05-19 12:56

Perhaps another clue about the frozen clock, but not the frozen monitors.

Boot to frozen state of both clock and monitors
Menu-->Run
In gExec, specify geany, run as root, OK
When the password box is presented, cancel without entering anything
The IceWM clock now shows the correct time, but the monitors remain frozen

It seems that CC gksu-properties default screen grab mode enable is sufficient to clear the blockage for the clock. If it is set to screen grab mode disable the clock remains frozen.

Maybe we are dealing with two problems rather than one.

SamK · posted: 2016-05-19 14:32

Dave wrote:What are the two lines used in slim.conf when desktop-session is enabled and disabled?

I'm not sure I get your meaning.

Code: Select all

...
# This command is executed after a succesful login.
# you can place the %session and %theme variables
# to handle launching of specific commands in .xinitrc
# depending of chosen session and slim theme
#
# NOTE: if your system does not have bash you need
# to adjust the command according to your preferred shell,
# i.e. for freebsd use:
# login_cmd         exec /bin/bash -login / etc/X11/Xsession %session 
#################OLD COMMAND####################
# login_cmd         exec /bin/bash -login ~/.xinitrc %session >~/.xsession-errors$DISPLAY 2>&1
################################################
#LOGIN COMMAND FOR DESKTOP SESSION BELOW#
#############################################################################################
login_cmd   setsid /usr/local/bin/desktop-session %session
#############################################################################################

# login_cmd exec dbus-launch /bin/bash -login ~/.xinitrc %session >~/.xsession-errors 2>&1

# Commands executed when starting and exiting a session.
# They can be used for registering a X11 session with
# sessreg. You can use the %user variable
#
sessionstart_cmd   /usr/bin/sessreg -a -l $DISPLAY %user
sessionstop_cmd       /usr/bin/sessreg -d -l $DISPLAY %user

# Start in daemon mode. Valid values: yes | no
# Note that this can overridden by the command line
# option"-d"
# daemon    yes

# Available sessions (first one is the default).
# The current chosen session name is replaced in the login_cmd
# above, so your login command can handle different sessions.
# see the xinitrc.sample file shipped with slim sources
sessions rox-fluxbox,space-fluxbox,fluxbox,herbstluftwm,rox-icewm,space-icewm,icewm,rox-jwm,space-jwm,jwm
...

Dave wrote:Is there anything in ~ / . xsession-errors when it is working without desktop-session being used?

When desktop-session is enabled the file does not exist.

When desktop-session is disabled the file contains

Code: Select all

Xsession: X session started for demo at Thu 19 May 15:56:29 BST 2016
localuser:demo being added to access control list
VBoxClient: the VirtualBox kernel service is not running.  Exiting.
icewm-session: using /home/demo/.icewm for private configuration files
icewmbg: using /home/demo/.icewm for private configuration files
icewmtray: using /home/demo/.icewm for private configuration files
IceWM: using /home/demo/.icewm for private configuration files
head: cannot open ‘/home/demo/.desktop-session/desktop-code.0’ for reading: No such file or directory

Dave wrote:Does waiting for a minute or two before logging in have any change on the outcome?

Yes. Waiting approx 70 seconds at the slim login screen then login, clock shows correct time and monitors work as expected in five successive tests.

Dave wrote:Also could have run
Ps -ef | grep -i 'ice'
When it is working and when it is not? I do not know if that will tell anything but maybe if the processes are orphaned.

When clock and monitors are frozen

Code: Select all

ps -ef | grep -i 'ice' | grep -v 'grep'
demo      3984  3955  0 15:14 ?        00:00:00 /usr/bin/icewm-session
demo      3993  3984  0 15:14 ?        00:00:00 icewmbg
demo      3994  3984  1 15:14 ?        00:00:00 icewm
demo      3995  3984  0 15:14 ?        00:00:00 icewmtray

When clock shows correct time and monitors working following a manual restart of IceWM

Code: Select all

ps -ef | grep -i 'ice' | grep -v 'grep'
root      3552     1  0 15:14 ?        00:00:00 /usr/sbin/gpm -m /dev/input/mice -t exps2
demo      3984  3955  0 15:14 ?        00:00:00 /usr/bin/icewm-session
demo      3993  3984  0 15:14 ?        00:00:00 icewmbg
demo      3994  3984  1 15:14 ?        00:00:02 icewm --restart
demo      3995  3984  0 15:14 ?        00:00:00 icewmtray

When clock shows correct time and monitors working following a delayed login

Code: Select all

ps -ef | grep -i 'ice' | grep -v 'grep'
root      3559     1  0 15:22 ?        00:00:00 /usr/sbin/gpm -m /dev/input/mice -t exps2
demo      4000  3971  0 15:23 ?        00:00:00 /usr/bin/icewm-session
demo      4009  4000  0 15:23 ?        00:00:00 icewmbg
demo      4010  4000  1 15:23 ?        00:00:00 icewm
demo      4011  4000  0 15:23 ?        00:00:00 icewmtray

dolphin_oracle · posted: 2016-05-19 14:58

Dave wrote:
Does waiting for a minute or two before logging in have any change on the outcome?
Yes. Waiting approx 70 seconds at the slim login screen then login, clock shows correct time and monitors work as expected in five successive tests.

now that is interesting, and implies something isn't finished loading with slim starts.

Dave · posted: 2016-05-19 15:16

Yes that is what I was wondering as the other post disabled everything really to the point of just having exec icewm-session in xinitrc. So I was thinking maybe the way it was called in slim or some service (acpi maybe? ) not being loaded or being reloaded later on.

dolphin_oracle · posted: 2016-05-19 15:23

Dave wrote:Yes that is what I was wondering as the other post disabled everything really to the point of just having exec icewm-session in xinitrc. So I was thinking maybe the way it was called in slim or some service (acpi maybe? ) not being loaded or being reloaded later on.

the debian etc/init.d/slim script is slightly different from ours. Posting here for convienence (no code tags because of all the /etc. My untrained eye doesn't see any big deals...

I have seen references around the 'net to using dbus-launch to start the wm, but nothing definitive to this situation.

#!/bin/sh

# Largely adapted from xdm's init script:
# Copyright 1998-2002, 2004, 2005 Branden Robinson <branden@debian.org>.
# Copyright 2006 Eugene Konev <ejka@imfi.kspu.ru>

### BEGIN INIT INFO
# Provides: slim
# Required-Start: dbus $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Should-Start: xfs $named slapd
# Should-Stop: xfs $named slapd
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start daemon at boot time
# Description: Debian init script for the SLiM.
### END INIT INFO

test -z"$HEED_DEFAULT_DISPLAY_MANAGER" && HEED_DEFAULT_DISPLAY_MANAGER=true
DEFAULT_DISPLAY_MANAGER_FILE=/etc/X11/default-display-manager

NAME="slim"
DESC="X display manager"
DAEMON=/usr/bin/slim
PIDFILE=/var/run/slim.lock

SSD_START_ARGS="--pidfile $PIDFILE --name $(basename $DAEMON) --startas $DAEMON -- -d"
SSD_STOP_ARGS="--pidfile $PIDFILE --name $(basename $DAEMON) --retry TERM/5/TERM/5"

test -x $DAEMON || exit 0
. /lib/lsb/init-functions

case $1 in
start)
if ["$HEED_DEFAULT_DISPLAY_MANAGER" ="true" ] &&
[ -e $DEFAULT_DISPLAY_MANAGER_FILE ] &&
["$(cat $DEFAULT_DISPLAY_MANAGER_FILE)" !="$DAEMON" ]; then
log_daemon_msg"Not starting $DESC ($NAME); it is not the default display manager.""$NAME"
else
log_daemon_msg"Starting $NAME""$NAME"
start-stop-daemon --start --quiet $SSD_START_ARGS
log_end_msg $?
fi
;;

stop)
log_daemon_msg"Stopping $DESC""$NAME"
start-stop-daemon --stop --quiet $SSD_STOP_ARGS
log_end_msg $?
rm -f $PIDFILE
;;

restart)
$0 stop
sleep 2
$0 start
;;

force-reload)
/etc/init.d/slim restart
;;

status)
status_of_proc /usr/bin/$NAME $NAME
;;

*)
echo"Usage: /etc/init.d/slim {start|stop|restart|force-reload|status}"
exit 1
;;
esac

# End of file

anticapitalista · posted: 2016-05-19 15:24

Try using the bootchart option in F4 and when you get to the desktop, type in a user terminal pybootchartgui.
Maybe we can see something there.

SamK · posted: 2016-05-20 04:41

anticapitalista wrote:Try using the bootchart option...

Attached. I'm not sure if you wanted a particular set of boot params, so this is basic live with UK lang and time.

Dave · posted: 2016-05-20 12:08

SamK is this when the monitors are frozen or when they are working after waiting?
Also can you wait any less than 70s or is that the lowest you can wait ?

Ideally a chart of when they are frozen to when they are working would help to compare.
Trying to find what starts 70 seconds after slim. (or what extras are being started that need 70s to load) 70 seconds seems a very long time for anything however so I am not sure what could be found.

dolphin_oracle · posted: 2016-05-20 12:39

OK, call me crazy, but on my bootchart here in a virtualbox, ntpdate runs way before slim starts and is finished pretty much just before slim does the autologin thing. but in sam's bootchart, ntpdate runs way after the desktop would start, and depending on how you measure, 10 to 15 seconds after slim starts. and its after the icewmtray starts, so it possible tries to do whatever it does after sam's monitor start.

Dave · posted: 2016-05-20 12:47

Well then to proceed I would figure set the time to use system time or disable the time sync completely and see if it works

dolphin_oracle · posted: 2016-05-20 12:50

Dave wrote:Well then to proceed I would figure set the time to use system time or disable the time sync completely and see if it works

yeah, this apparently runs when a network interface is brought up. its not called from etc/init or etc/init.d as far as I can tell. that startup looks to be in etc/network/ifup.d

I wouldn't think setting the date would cause an issue, but heck, we've tried everything else.

SamK · posted: 2016-05-20 14:30

Dave wrote:SamK is this when the monitors are frozen or when they are working after waiting?

That bootchart was not using any form of persistence so the desktop defaults to shipped GUI state i.e. IceWM without monitors in taskbar.

Dave wrote:Also can you wait any less than 70s or is that the lowest you can wait ?

The 70 seconds was chosen following the successful test of the clock updating in the panel of Fluxbox. That happens every 60 seconds. When testing IceWM the period of 70 seconds was to ensure a complete minute had passed therefore the clock in the taskbar should have advanced by 1 minute.

It is probable a shorter wait time will work. Establishing what the minimum is will be quite tricky. I will test a shorter wait time.

Dave wrote:Ideally a chart of when they are frozen to when they are working would help to compare.

Currently the only way to boot to an"unfrozen" state is to wait a while at the slim login screen before login. So I'm not certain that will provide much useful info. Will you or d_o confirm if either of you would like to see it anyway.

I can capture a bootchart of the frozen condition by using auto-login with persistence. Again will you or d_o confirm if either of you want to see that one even if the bootchart for a manual login is not wanted..