This has been an ongoing trial - in edgy I couldn't get adesklets to load except to the root window (which was then covered by the wallpaper) using the startup programs bit in the session manager.

Now, with feisty, I have entered beryl manager and emerald to the startup sessions and yet they do not start.

I'm having the same problem, every time I add a program to the startup menu, it disappears the next time I open the session menu, and the program never starts when I boot up.

When I run Sessions in terminal and try to add a program (in this case Gaim) it gives me this:
I must honestly say that I have no idea what to do.

Well, in my case the entry remains... I suspect there is a conflict with "remember settings" on logout but it is unconfirmed.

I have a number of applications starting from Sessions including Gaim, Firestarter, Perl and Bash scripts. My ~/.config/autostart directory has some text files created by the Sessions GUI, including this one for Gaim. All were marked as executable.

[Desktop Entry]
Name=No name
Encoding=UTF-8
Version=1.0
Name[en_US]=Gaim
Exec=gaim
X-GNOME-Autostart-enabled=true

Have you tried listing the programs in /ect/rc.local? Programs listed there run at boot time.

How should I list the commands in the rc.local file?
I tried simply using the boot commands, but it didn't work.

I'm not real clear but think you just give the command with any arguments. Make sure it is above the "Exit" line already there. AFAIK, rc.local is the last file run upon booting. I've not used it myself but did look into it when trying to troubleshoot another problem. You might try googling for more info.

Assuming you have single user systems, you're sure doing things the hard way. True /etc/rc.local is where to place system startup commands. rc.local is a bash shell file which will be called during boot. It has to exit properly as its called like a function. The file has some comments in it relating to its use. If you use the sessions GUI you won't have to worry about any of this. In that case the programs are started with X after the boot is complete. They are only started for that user and by this time the connection to the Internet is complete as required by some applications like firestarter. You don't have to worry about permissions for example. A copy of my rc.local follows. The bit I added is for starting bluetooth on my system.

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

#Start Bluetooth for Palm E2
modprobe l2cap
modprobe rfcomm
mknod /dev/rfcomm0 c 216 0
sdptool add --channel=10 OPUSH
rfcomm bind /dev/rfcomm0 00:07:E0:6F:85E 10

exit 0

I don't want them to run at boot - I want them to run after login.

Ubuntu provides for what you want with System-> Preferences-> Sessions-> Startup Programs tab. You may add your startup applications here. This where I start firestarter, gaim and a Perl script for registering a dynamic DNS. With the new button you get a popup where you can enter a meaningful label and the command to start the application. For example the command I used to start firestarter was "sudo firestarter --start-hidden". In this case sudo will prompt with a password window during startup.

Uh, fragos, both Simon and i are aware of the Sessions menu and the Startup Programs function. The problem is that these things aren't working properly.

All I can say is that they work correctly for me and others. My advice would be to remove all the changes you may have made to try and get this working and carefully start again.

I just registered because I had this same problem.

However, I also managed to fix it quite simply

I was getting the same error if I ran the session properties from terminal.

I figured it's probably a permissions problem, so I just loaded up a root session of Nautilus, allowed others to read & write, and create & delete files in /home/[username]/.config/autostart/

This fixed the problem, and changes in the Session Manager now stick instead of reverting.

By default my system allowed me to make those changes. In your home directory the owner should have RW permissions. Although that could be "broken" from the command line.

fragos: already tried changing everything back and redoing... no dice. Even had a chance to do a complete clean install and it still wouldn't stick. Note, in my case, the actual settings will keep displaying, just the process doesn't always start.