Crontab #reboot command not attaching to a screen [closed] - linux

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Improve this question
I run a minecraft server on a remotely hosted linux VPS. Recently, a migration was done at my host's data center where the VPS image was copied to a new setup (new hardware, new IP, new virtual infrastructure I believe).
Before the migration, the server had the below command crontab'd and it worked fine; after a full reboot, I could type "screen -x" to get into the server console. After the migration, I cannot do this anymore. The command itself starts the minecraft server... but not the 'screen'. I have asked the host to explore why and he tested it out and replied he can't find the reason either.
The main changes I know of at the time of migration... upgrade from 13.x to 14.04 Ubuntu; update from Java 6 to Java 8... update to newest MySQL... storage upgraded to SSD. Changed from "Xen" to "KVM"... and new setup supported by OpenStack.
#reboot cd /home/mcma && screen -dmS minecraft /home/mcma/MCMA2_Linux_x86_64
I wish I could provide more info but this is everything I have at hand, I don't know how to troubleshoot further. Any assistance would be greatly appreciated.

Some ideas to try:
Check if the cron daemon is running.
If it does, check the logs to see if it attempts to start the given cron job. Might need to crank up the log level for this.
If the job does get launched, check the the error.
Try using absolute path to screen.
If /home/mcma/MCMA2_Linux_x86_64 is a script, try adding sh before it.
Have you tried running the command by hand?
The Internets seem to imply there might be a bug with non-root #reboot jobs on some Ubuntus. Which cron daemon are you using?
Check Ubuntu bug 574773. It might be the issue you are having.
Let me know if you gather any additional data from above, so we can try a few more things as needed.

Related

Why are there different ways to restart apache2 and networking in Debian? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I have two virtual machines with Debian. One I got from school. The other one I made myself.
The way you restart apache2 on the school machine is service apache2 restart and they way you restart networking is service networking restart.
However, when I tried these commands in the machine I set up myself, I found out that they don't work and that I have to use systemctl apache2 restart for apache2 and systemctl restart networking for networking instead.
My question is why I have two use two different commands to do the same thing on these machines, even tho they are both running Debian.
Thank you in advance.
The answer to your question: On the machine, you set up for yourself, you have a newer distribution of Debian than the one from your school. The service command was replaced with systemctl .
A more detailed answer with differences between these two commands you can find here.
In the older versions, for the same task we used:
/etc/init.d/{service name} {comand}
example:
/etc/init.d/apache2 restart
Then at a later stage, the service command came in.
Now on current distributions, you should use systemctl instead of service, and it is recomended even on distributions what suport both or all three comands (like ubuntu 20.04 for example).

VNC4Server/vncserver – always use desktop number 1 after starting of the vnc server [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I am using vncserver on a Ubuntu 14.04.3 LTS server machine to connect remotely and perform administrative tasks. I do not automatically start VNC. I first connect over SSH and call "vncserver -geometry 1024x800 &" to start it.
However normally vncserver always created desktop 1. Only if I had forgotten about a already running desktop it used 2 or 3 for the second session. But as soon as I killed all processes it started clean at desktop 1 again.
Now since I did some changes in startup by running multiple sessions for testing at a time and also after I changed the hostname of the server it always keeps starting with desktop 2 meanwhile 3. While 1 and 2 is definitively not running. I also removed all logs in my vnc home dir of previous sessions.
Well I'm wondering why and out of what reason it keeps increasing the desktop number sometimes. Also I would like to get it back to desktop 1 and fix it somehow. So that I can easily save the server Ip (IP:1) in my Remote-Profile without the need of changing it from time to time because vnsserver starts from an higher number.
Any ideas why it won't take desktop 1 any more?
:(
Thanks
vncserver will take the first available port from 5901 and onwards. There can be a few reasons why this does not work, like the port already being taken for something else. Or that vncserver is actually still running. Check out the file specified as log file for a clue.
You can check whether there still are vncserver processes running with:
vncserver -list
Without more information it's difficult to answer your question to the fullest. The various vnc implementations also behaves differently.
You can try to force it to open on display :1 by specifying it on the command line
vncserver :1 -geometry 1024x800

cannot execute startkde using X2GO client on windows [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I am using a X2GO client on a Windows 7 (64-bit) laptop in order to login to a remote machine running Fedora 20. However, when I try to connect choosing KDE as a session type, I get a "cannot execute startkde" error.
Is there something I need to configure on my laptop or Fedora machine?
This worked for an ubuntu server but may work for fedora/centos. In the session preferences tab of the x2go client, change the "session type" to XFCE
At this point I'm almost sure the OP has already fixed the issue or just tried another DE. Anyways, just for the record, for other people that may come across this error, this is my experience and how I solved it.
In my case the problem was that the version of KDE I was using didn't have a startkde command, at all. Apparently, newer versions of KDE use startplasma-x11 (or startplasma-wayland) instead.
In X2GO, I selected "Custom desktop environment" (or something like that, I'm using another language), then pasted the startplasma-x11 command in the field. It worked after that.
To check if that's also your problem, try to SSH to the machine, write which startkde and, if it fails, then try which startplasma-x11 and it should return a path. If it does, then you just follow the steps above and it should work.
Running sudo yum install #kde on the remote machine resolved the issue. I was now able to login to the remote machine using X2GO client.
If the command is not setup up properly in the available PATH,:
then the error like
"Cannot run 'startkde' occours
Please check that the requested application is in the system PATH and that you have the rights to execute it."
you need to login to the super user mode by pressing
ctrl + alt + f1
Whether the PATH is set or not can be checked by executing
which startkde
or more generally, 'echo $PATH'
The correct path must be set in /etc/profile or /etc/csh.login, depending on the shell the user is using.
And now when you try to log in from windows desktop after doing all this if error again appears Cannot run ‘startkde’. …
make sure you have the appropriate credentials to access .
on ubuntu I had to install XFCE, then select that in the windows client and then it worked.

Linux system waits for 90 seconds after "poweroff" is invoked before shutdown in VMware [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I am running Arch Linux (installed from archlinux-2014.01.05-dual.iso) on VMware Player and have installed vmtoolsd (which belongs to open-vm-tools).
Now my problem is that, whenever I do poweroff or reboot, the system just leaves me with a black screen with only a cursor flashing at the top-left corner. If I don't do anything to it, the system will shutdown or reboot in one or two minutes.
I've searched Google for this problem. Some people suggest that I modify /usr/lib/systemd/system/vmtoolsd.service and that I add one line for KillSignal=SIGKILL or TimeoutStopSec=2. However, none of these works. Actually when I do systemctl stop vmtoolsd, it seems to stop quickly.
I guess maybe some other service is in the similar state as is discussed in those posts I see. Is there a workaround on this so that I can shutdown my virtual machine immediately and gracefully, or that I can figure out what is going on during poweroff is executing so that I can tell if any service is blocked?
Update March 4, 2014: Now the problem becomes strange. I reinstalled Arch Linux but the problem just continues. Now I guess that it may not necessarily be a problem of vmtoolsd or any service I installed, but of VMware tools or the system. (But I am sure that Ubuntu does not have this problem running in VMware.) Now I am trying to figure out what really caused the problem.
By the way, is there any report that Arch Linux or other system based on that has similar issue when running in VMware?
Update March 4, 2014: I used Arch Linux Live CD and similar problem happens with error message: A stop job is running for User Manager for 0. Then I thought this might be a bug which is reported here: https://bugs.freedesktop.org/show_bug.cgi?id=70593 which is a bug of systemd and was fixed in update 209 or 210. I then did an update using pacman -Syu and the delay was gone. However, I think I have updated my Arch Linux last time when I have open-vm-tools installed (before I reinstall the entire system). Now I plan to install open-vm-tools again and see if the same error occurs.
Maybe you've installed some services or programs that take some time to stop, you could investigate on this (ps, top commands) or simply kill everything (see xkill) before try to sudo halt. Also if you are using internet and downloading/installing many programs you should either take a look at RK Hunter or something similar.
Hope this helps
regards,
LX
The problem you describe is a bug. I have personally seen this bug on a Virtualbox machine. I can't really help you much more. Hopefully, it will be fixed soon. Take care.

Getting IO privileges in Linux [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I have installed flashrom software. When i try to run sudo flashrom command it gives me "Could not get I/O privileges (Operation not permitted). You need to be root" error. Also I tried su command to switch root and run again. I also tried sudo -i command to login as root. However any of them did not work
#if defined (__OpenBSD__)
msg_perr("If you are root already please set securelevel=-1 in /etc/rc.securelevel and\n"
"reboot, or reboot into single user mode.\n");
#elif defined(__NetBSD__)
msg_perr("If you are root already please reboot into single user mode or make sure\n"
"that your kernel configuration has the option INSECURE enabled.\n");
#endif
Reading this from the FlashRom.org pastebin site should give some insight.
This is the only file in Flashrom that contains the line, "You must be root"
Therefore, in my opinion, this is the only place the error can be coming from.
I changed secure boot option in bios settings as disabled. So I can run the flashrom program. But it gives this output.
WARNING! You seem to be running flashrom on an unsupported laptop.
Laptops, notebooks and netbooks are difficult to support and we
recommend to use the vendor flashing utility. The embedded controller
(EC) in these machines often interacts badly with flashing. See the
manpage and http://www.flashrom.org/Laptops for details.
If flash is shared with the EC, erase is guaranteed to brick your
laptop and write may brick your laptop. Read and probe may irritate
your EC and cause fan failure, backlight failure and sudden poweroff.
You have been warned.
So there is nothing to do. I have to search another tool to flash my bios

Resources