Now please explain to use why this doesn’t apply to you:
If you set the setuid bit back (so did I), I understand that it works, but it should have been part of your answer, because simply saying: “just run startx” is not going to help anyone and is a wrong (or at least incomplete) piece of advice.
And as Carlos said, starting X outside of a session manager is not exactly the same thing. Of course if you have been written your own Xsession files and xinit scripts since 1998, you can achieve the same and even a better result… but users wondering why .xsession-errors grows are not ready to do that.
On 08/13/12 14:53, Carlos E. R. pecked at the keyboard and wrote:
> On 2012-08-13 20:14, Ken Schneider wrote:
>
>> Been using S.u.S.E./openSUSE since 1998 ver. 5.something. You run startx as a user and su (-)
>> to root to run what you need to run. Actually I ssh -X to the box I want to admin so still no
>> need to have “X” running on a server.
> It is a procedure not recommended by the devs, so much so that it doesn’t work by default any
> longer. And if you do manage to make it work, then there are further problems, with some
> functionalities of the desktops not working because they depend on kdm/gdm.
>
And when you have no physical access to the server (due to it being
100’s of miles/kilometers away) you have no choice but to use ssh.
On 08/13/12 17:16, please try again pecked at the keyboard and wrote:
> kensch;2479895 Wrote:
>> On 08/12/12 17:56, please try again pecked at the keyboard and wrote:
>>> kensch;2479706 Wrote:
>>>> Actually just use startx. When you log out you’ll be at the tty
>> prompt
>>>> without “X” running.
>>> Did you try that under openSUSE ? … or supposing you’re not an
>> expert
>>> or haven’t read 11.4 Releases Notes? (and you’re not starting X as
>>> root).
>>>
>>>
>> Been using S.u.S.E./openSUSE since 1998 ver. 5.something. You run
>> startx
>> as a user and su (-) to root to run what you need to run. Actually I
>> ssh
>> -X to the box I want to admin so still no need to have “X” running on
>> a
>> server.
>>
>> And I upgraded from 11.4 prior to it’s EOL.
> Now please explain to use why this doesn’t apply to you:
>
>
> “openSUSE 11.4 Releases Notes” Wrote:
>> Removing the Xorg setuid bit
>>
>> The setuid bit on /usr/bin/Xorg is needed for starting X as an
>> unprivileged user, e.g., via startx. This method has been deprecated for
>> years in favor of using a display manager. Modern environments rely on
>> device ACLs and polkit privileges, which in turn depend upon consolekit
>> tracking the active console, which is performed by the display manager.
>>
>> Users who depend on the old configuration can set the setuid bit
>> themselves in /etc/permissions.local by removing the comment sign from
>> the following line:
>>
>> #/usr/bin/Xorg root:root 4711
>>
>> and running SuSEconfig --module permissions afterwards.
>>
> If you set the setuid bit back (so did I), I understand that it works,
> but it should have been part of your answer, because simply saying:
> “just run startx” is not going to help anyone and is a wrong (or at
> least incomplete) piece of advice.
>
> And as Carlos said, starting X outside of a session manager is not
> exactly the same thing. Of course if you have been written your own
> Xsession files and xinit scripts since 1998, you can achieve the same
> and even a better result… but users wondering why .xsession-errors
> grows are not ready to do that.
>
>
You don’t need to have “X” running to start GUI tools on a remote
machine period.
On 08/13/12 21:06, please try again pecked at the keyboard and wrote:
> kensch;2479970 Wrote:
>> You don’t need to have “X” running to start GUI tools on a remote
>> machine period.
> It has nothing to do with startx. And this thread is not about ssh and
> remote connections.
My remarks were in response to this part of this thread:
On 08/12/12 11:31, Martin Helm pecked at the keyboard and wrote:
Am 12.08.2012 17:06, schrieb dd@home.dk:
> On 08/12/2012 02:43 PM, Martin Helm wrote:
>> What about redirecting the whole crap to /dev/null by symlinking?
> or how about not running an instance of X 24x7 on a server?
>
> just boot to run level 3.
>
> then when/if the ‘administrator’ needs a window s/he can init 5 to a
> gui, then back to init 3 (as the deity intended)…
>
+1
Which /is/ about running “X” so the “Admin” can go to a GUI and do some
work. Whether you use “init 5” or “startx” they both get you to the same
place. And this thread is/was about the OP’s .xsession-errors file
growing out of control.
If you use KDE (and/or kdm) than you can edit your kdmrc to use another
place for this millions of “very important” messages. I personal use
tmpfs for /tmp and than i replace ClientLogFile at two places with this:
On 08/14/2012 05:34 AM, Ken Schneider wrote:
> Whether you use “init 5” or “startx” they both get you to the same place.
that was right for a long time…but, not now–because since 11.4, in
a default install, ‘startx’ just returns an error.
hmmm…and the way they are ‘messing with’ systemD (vs systemV) it may
soon be that ‘init 5’ (or 3) will also return an error…(or already may
be the case with 12.1–don’t know, have not tried it yet)
maybe you missed the reason i posted what i did, which is: real server
admins don’t need a ‘windows’ running (which avoid the OP’s errors
filling his hard drive!!)
[of course, we now have “college educated system engineers and
administrators” that don’t have a clue about how to ‘ping’ without a GUI
running.]
one thing for SURE: this ride is a fast moving train and stuff learned
in SuSE 5, 6, 7, 8, 9 or SUSE 10 may be helpful to a new to
Linux/openSUSE user…or maybe it is all wrong, and just confusing…
there are lots of examples of stuff that was right on 10.x and 11.x is
not right on 12.1)
@kensch,
It gets you to the same place but not through the same ways. You can walk over fields to work but you will get there with dirt on your shoes. Running a single script and entering a runlevel obviously doesn’t do the same thing, even if in the case of startx, you end up with a usable X desktop. The reason why it makes only little difference is that most daemons are started in both runlevels (whether it is clever is debatable).
As for startx, please install openSUSE - on more time in 15 years - and try to execute it as user on a fresh standard installation before advising others to do so. You will notice that it does not work.
Or/and - if reading the Releases notes is boring or time consuming (which I can perfectly agree with) , take a look at this script - if we’re talking about the one shipped with openSUSE:
# sed '/^$/d;1,/retval/d' /usr/bin/startx
if "$retval" != 0 -a ! -u "/usr/bin/Xorg" ]; then
echo "-------------------------------------------------------------------------------------------"
echo "xinit failed. /usr/bin/Xorg is not setuid, maybe that's the reason?"
echo "If so either use a display manager (strongly recommended) or adjust /etc/permissions.local"
fi
if x"$enable_xauth" = x1 ] ; then
if x"$removelist" != x ]; then
xauth remove $removelist
fi
if x"$xserverauthfile" != x ]; then
rm -f "$xserverauthfile"
fi
fi
exit $retval
Nothing against startx though. I use it too, and I love this script so much that I rewrote it completely, so that it would take the window manager, the server name (for remote connections) or the layout (right or left monitor, ot both) as argument, or even be executed within X to start a new X session in another tty. But we all do things differently and it’s not a problem, as long as we can agree about what is possible or not, advisable or not for most users and under most circumstances.
I also agree with the fact that Linux should not be started in GUI, and the first thing I do on a new system is to set the default runlevel (for both sysvinit and systemd) to something more reasonable:
# set default runlevel to console
if ! -f /etc/inittab.orig -a -f /etc/inittab ] ; then
echo "- setting default runlevel to $Runlevel (user defined)"
cp /etc/inittab{,.orig}
cat << EOFINITTAB | sed -f - /etc/inittab.orig > /etc/inittab
s|id:5:initdefault:|id:$Runlevel:initdefault:|
EOFINITTAB
ln -sfn /lib/systemd/system/runlevel3.target /etc/systemd/system/default.target
fi
People would avoid a lot of problems by doing so … but it is less sexy, and Linux distros don’t do it by default.
Finally notice that booting in runlevel 3 doesn’t imply that you should use ‘startx’ to start the GUI. The right way is to run “init 5” (even if it gets you to the same place) or under systemd:
# systemctl isolate runlevel5.target
where runlevel5.target is a symlink to graphical.target. Thus the command above is equivalent to:
# systemctl isolate graphical.target
Even running gdm or kdm from the command line would be more advisable that startx, because when X is started from a session manager, it becomes a session from the XGD point of view, variables such as DESKTOP_SESSION get set in the environment, autostarted programs get executed (not talking about KDE kind of things) and free desktop compliant window managers are happy.
So please avoid startx - generally speaking … unless you are aware of its limitations and use your own Xsession scripts to do what you want - which doesn’t seen to be the case of the majority of users (even after 15 years of openSUSE).
On 2012-08-14 02:37, Ken Schneider wrote:
> On 08/13/12 14:53, Carlos E. R. pecked at the keyboard and wrote:
>> On 2012-08-13 20:14, Ken Schneider wrote:
>>
>>> Been using S.u.S.E./openSUSE since 1998 ver. 5.something. You run startx as a user and su (-)
>>> to root to run what you need to run. Actually I ssh -X to the box I want to admin so still no
>>> need to have “X” running on a server.
>> It is a procedure not recommended by the devs, so much so that it doesn’t work by default any
>> longer. And if you do manage to make it work, then there are further problems, with some
>> functionalities of the desktops not working because they depend on kdm/gdm.
>>
> And when you have no physical access to the server (due to it being 100’s of miles/kilometers
> away) you have no choice but to use ssh.
Yes, of course. But that has nothing to do with running startx that I can see :-?
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)