This error seems to have occurred after erasing and recreating the user of uid 1000.
How do we deal with this?
error image
enter image description here
Check /lib/systemd/system/nfs-common.service with ls -l and delete /dev/null symbolic links
rm /lib/systemd/system/nfs-common.service
systemctl daemon-reload
Related
I am trying to run a redis image in gke. It works except I get the dreaded "Transparent Huge Pages" warning:
WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
Redis is currently too slow to be useful... So I tied turning off THP:
sheena#gke-projectwaxd-cluster-default-pool-23593a74-wxrv ~ $ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
sheena#gke-projectwaxd-cluster-default-pool-23593a74-wxrv ~ $ echo never > /sys/kernel/mm/transparent_hugepage/enabled
-bash: /sys/kernel/mm/transparent_hugepage/enabled: Permission denied
sheena#gke-projectwaxd-cluster-default-pool-23593a74-wxrv ~ $ sudo echo never > /sys/kernel/mm/transparent_hugepage/enabled
-bash: /sys/kernel/mm/transparent_hugepage/enabled: Permission denied
These permission errors are disconcerting. Redis wants THP off so it can work properly.
I did a little digging and found that google uses a special os image that makes /sys/ a read-only path. There's an alternative image that's based on Debian 7. It got me all excited but in the end I have exactly the same problem.
So how do I stop redis from being effected by THP on Google container engine?
It's not like I'm doing something unique here. Running databases in containers is pretty normal. And it's pretty normal for a database to malfunction when THP is enabled. So... what am I missing here?
Your command is slightly incorrect: echo runs as root but the redirection itself (>) runs as user so it can't write /sys/.
The following command works fine both on container-vm (debian based) and gci (chromeos based):
sudo sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled'
Persisting this setting on container-vm
Add this kernel command line parameter into /etc/default/grub (don't forget to run sudo update-grub and sudo reboot afterwards):
GRUB_CMDLINE_LINUX="... transparent_hugepage=never"
Persisting this setting on gci
First, using the cloud console copy the instance template that is in use by the node pool.
Second, under metadata change the value for userdata:
#cloud-config
write_files:
- path: /etc/systemd/system/hugepage.service
permissions: 0644
owner: root
content: |
[Unit]
Description=Disable THP
[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
[Install]
WantedBy=kubernetes.target
...
runcmd:
- ...
- systemctl enable hugepage.service
- systemctl start kubernetes.target
Third, change the instance template to the newly created one:
gcloud compute instance-groups managed set-instance-template \
gke-YOUCLUSTER-YOURPOOL-grp \
--template=YOURNEWTEMPLATENAME \
--zone=...
Forth, recreate the instace(s):
gcloud compute instance-groups managed recreate-instances \
gke-YOUCLUSTER-YOURPOOL-grp \
--zone=... \
--instances=...
The instances will loose all data and come up with THP disabled. All new instances will have THP disabled as well (in this node pool).
I learned Promela and Spin, but when I try verifying the model, these lines
are returned to me.
What do they mean?
Thanks
That means that you ran a Spin verification and your verification identified an error. Your next step is to determine how the error occurred. You do that by generating and examining the 'trail file'.
If you performed your verification as:
$ spin -a model.pml
$ gcc -o pan pan.c
$ ./pan
then examine the trail using the model.pml file with:
$ spin -p -t model.pml
Probably, you have a deadlock or other error in your model.
If you would post your complete console output, I could probably update this answer to give you more information!
When I SSH into my Vagrant box, I would like it to run the following two commands;
cd /vagrant
git status
So naturally I would modify my ~/.bash_login to do this
cat << EOF | sudo tee -a ~/.bash_login
cd /vagrant
git status
EOF
If I then exit, and ssh back into my box - it works!
So then I added those exact commands to my bootstap.sh provisioning file, so that each time my box is provisioned, it would add it automatically to my bash_login script.
Except it doesnt work. The output during provisioning shows it including the two commands, but when I then SSH into the box nothing happens. If I view my bash_login file - the changes are not there?
Any ideas why not? I'm wondering if perhaps when I SSH into the box, I am a different user than when the box is being provisioned, so when I edit the bash_login script I am editting another user's file?
Ok - I worked it out. In case anyone comes across this same issue - I was editting the wrong bash file. This works;
cat << EOF | sudo tee -a /home/vagrant/.bashrc
cd /vagrant
git status
EOF
I'm on a Debian OS.
I'm trying to use screen under a SSH session. But when I'm trying to run the command
screen
the shell answer me :
Must be connected to a Terminal.
If I enter
tty
it answer me :
Not a tty
I don't know why and I try
ssh -t login#server
it doesn't work..
Please help me I really need this !
Thanks
EDIT :
I read this topic but it still doesn't work
I had the same problem. If you get this error while in a chroot, here is what helped me:
(run these commands from outside the chroot)
$ sudo mount -o bind /dev /home/chroot/dev
$ sudo mount -t proc proc /home/chroot/proc
$ sudo mount -t devpts devpts /home/chroot/dev/pts
/home/chroot being the path to your chroot, obviously. Update above commands accordingly.
source: http://www.howtoforge.com/forums/showthread.php?t=23583#post128768
(see also http://forums.gentoo.org/viewtopic-t-433006-start-0.html)
Try the following:
getty tty
...and then relaunch:
screen
If you don't have getty, you could try installing it:
apt-get install getty
I want to make a shellscript to install Wine on a Mac
and i want the user to enter his/her password so the script can use it later on to make the installation unattended by automatically entering the password on "sudo" commands. This is what i got for now:
clear
echo Wine Installer v1.0
echo -------------------
echo by Sydcul
sleep 4
clear
echo "Please enter your OS X user password."
echo "It is needed in some parts of the installation."
read PASSWORD
echo "Wine installation starting."
echo "Please do not shut down your system."
mkdir winetmp
cd winetmp
curl -O https://distfiles.macports.org/MacPorts/MacPorts-2.0.3.tar.bz2
tar xjvf MacPorts-2.0.3.tar.bz2
cd MacPorts-2.0.3
echo $PASSWORD | ./configure && make && sudo make install
echo $PASSWORD | sudo port -v selfupdate
echo $PASSWORD | sudo port -v install xorg
echo $PASSWORD | sudo port -v install wine
rm -rf ~/winetmp
clear
echo "Wine is successfully installed and ready for use!"
But at a certain point is still asks for the password.
How can i fix this?
Honestly, I would drop all that $PASSWORD stuff and remove the sudo from all your commands. You are writing an installation script, which should be run with elevated privileges. Have your users execute your script with sudo ./installwine.sh, and then run the commands in the script without sudo. All your port -v stuff will inherit the elevated privileges.
If you'd like to offer your user a nice error message if they forget to run the script with sudo (rather than just having your first call to port fail cryptically), you could check to see if the effective user ID ($EUID) is 0, and print the error message and exit otherwise. See https://askubuntu.com/questions/30148/how-can-i-determine-whether-a-shellscript-runs-as-root-or-not.
You can prompt the user for the password for the first time and then save it in a file (and don't forget to encrypt it).
The next time when you need it you can easily read it from the same file and store it in a variable and then use this command
echo $variablename | sudo -S command
Actually I think sudo doesn't accept password from stdin (you need to specify -S parameter to enable this).
As workaround you can execute sudo su to gain root privileges for all commands.
UPD: I'm not recommend to save password to file cause it is very bad solution from security point.
UPD2: You forget about Xcode, if it is not installed this script fails on compile stage :)
Why don't you just use the custom prompt option for sudo, and let it ask for the password if it needs it?
You start by checking if they're already root or not like this:
SUDO=""
if [[ 0 == $(id -u) ]]
then
SUDO="sudo "
fi
$SUDO command 1
$SUDO command arg arg arg
and then optionally combine that with the ability to customize the sudo prompt using the -p option.
then
SUDO="sudo -p \"I need elevated access for this part. Please enter %u's password:\" "
fi
You still get control over the interface, but don't prompt for a password unless you need it. Some people may have sudo set up for nopassword operation, for example. Others might run your installer as root. Or maybe their pasword is already cached with sudo. Etc. It's best to let sudo manage prompting, possibly using an askpass program (see the -A option) if necessary.