I'm having a problem with screen. I have a script that I've used for years on Slackware and suddenly (with 12.2, and possibly earlier) it's stopped working as expected.

I can't say what the last version of Slackware was that worked definitively but I'm pretty sure I've used it on most versions from 9 upwards without a problem. The problem only shows itself when executed from /etc/rc.d/rc.local, which I don't always do, but there are several machines I've built which do exactly that.

The script is trivial and just creates several "screen" (screen -A -m -d -S and I've also tried -l because it looked like it might help) sessions for various programs. It works 100% of the time if I'm logged in with no problems at all. However, I sometimes put this script into /etc/rc.d/rc.local so that I have several screen's loaded at startup (before anyone logs in) with various information (this is useful, for example, with things like top, iptraf, watching logs, etc. so that I don't have to remember where they are... I can just login and look at "screen -list" to get any one of them I want and they would have been running from very early on in the boot, so even if I don't login to the machine for a month, the programs would have been collecting information for that long...). I know there are other ways of doing such things, but I quite like my way.

Anyway, I have a machine that DEFINITELY uses an identical script installed in an identical way on an earlier version of Slackware that, when called from rc.local works just fine. But on 12.2, I have a machine that creates the screen sessions just fine but for some reason places the .screen folder in / rather than the normal $HOME. It seems that $HOME is set to / rather than /root in the case of rc.local startups. Although I can understand some rationale for this, has nobody else spotted the change or is it just me?

It's obviously some sort of environment issue but could someone enlighten me to when the change was made, what change was made and why it was made? And does anyone know how it might be possible to workaround the problem - as it is, the programs just die or they end up with a pipe in /.screen/ instead of /root/.screen/ (so the root user doesn't see them under screen -list). But if you login and then issue the screen commands, everything works fine.

1. su - USER_NAME -c YOUR_COMMAND
This will setup your environment. I always do so.

2. If you didn't follow 1., you could still use
HOME=/ screen -r
to re-attach your session.

I know this, but that's no use to me if I want the programs to run in a screen from the very start of the computer booting up. I'd use Virtual Consoles but they really only work when you are local.

Just as an example of the type of usage:

1) Computer runs, say, iptraf, kismet or other console-based program, at startup without any user having to login (blackbox systems).
2) Occasionally I need to login remotely to the device, and see the output of iptraf in a nice graphical way (yes, I can grep logs etc. but that's not what I want to do for a quick check) but I need to see an iptraf that was running from the second the computer was up on the network.

Running it in a screen works perfectly because you can login remotely, resume the screen and see/interact with the program which was running from the first boot and will continue running until you switch the machine off. You can also show that same screen on a VC at the same time. However, screen doesn't want to work (lately, I've done this before, though) from an init script because of this environment issue. The environment gets set up the second you login or su to root, but that's *too late* for the program.

Some of the programs I want to use will even refuse to start if they don't have $HOME set up to a nice writable folder (i.e. something other than /) when you run then, so you end up with, out of seven programs I want to run in this fashion, three running on screens that you have to faff about to connect to and four processes which just die instantly.

I don't really want to play with $HOME from within the rc.local script but if I need to, I will. I just wondered what change was made to do this and why it was made... I've definitely done this before on slackware without problems (not that long ago, either).

If you don't take others' advices, why do you ask for them at all?

It doesn't work simply because you don't try it. I always use "su" for my screen sessions in "rc.local", not only for having a proper "$HOME" but also for dropping some privileges. Here is an example:
If you really don't want to change "$HOME" from "/", you can set "$SCREENDIR" to a proper directory. See the man pages in screen(1).

btw, I've digged out my Slackware 10.2 disc and made sure that "$HOME" is "/" in rc.local.

If you run

su - root -c 'screen command'

Wouldn't that use /root/ as HOME?