I am running Ubuntu 13.10, and I'm pretty new to Linux. I tried:
$ sudo apt-get install chkconfig
Package chkconfig is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'chkconfig' has no installation candidate
I manually downloaded the package and unzipped it. The resulting folder has a file called:
chkconfig.install
But how do I run this? I tried this, but it didn't work.
$ sudo chkconfig.install
The command chkconfig is no longer available in Ubuntu.The equivalent command to chkconfig is update-rc.d.This command nearly supports all the new versions of ubuntu.
The similar commands are
update-rc.d <service> defaults
update-rc.d <service> start 20 3 4 5
update-rc.d -f <service> remove
In Ubuntu /etc/init.d has been replaced by /usr/lib/systemd. Scripts can still be started and stoped by 'service'. But the primary command is now 'systemctl'.
The chkconfig command was left behind, and now you do this with systemctl.
So instead of:
chkconfig enable apache2
You should look for the service name, and then enable it
systemctl status apache2
systemctl enable apache2.service
Systemd has become more friendly about figuring out if you have a systemd script, or an /etc/init.d script, and doing the right thing.
sysv-rc-conf is an alternate option for Ubuntu.
sudo apt-get install sysv-rc-conf
sysv-rc-conf --list xxxx
alias chkconfig=sysv-rc-conf
chkconfig --list
syntax
sysv-rc-conf command line usage:
sysv-rc-conf --list [service name]
sysv-rc-conf [--level <runlevels>] <service name> <on|off>
Chkconfig is no longer available in Ubuntu.
Chkconfig is a script. You can download it from here.
Install this package in Ubuntu:
apt install sysv-rc-conf
its a substitute for chkconfig cmd.
After install run this cmd:
sysv-rc-conf --list
It'll show all services in all the runlevels. You can also run this:
sysv-rc-conf --level (runlevel number ex:1 2 3 4 5 6 )
Now you can choose which service should be active in boot time.
The following command do the same on Ubuntu:
systemctl list-dependencies
But how do I run this? I tried typing: sudo chkconfig.install which doesn't work.
I'm not sure where you got this package or what it contains; A url of download would be helpful.
Without being able to look at the contents of chkconfig.install; I'm surprised to find a unix tool like chkconfig to be bundled in a zip archive, maybe it is still yet to be uncompressed, a tar.gz? but maybe it is a shell script?
I should suggest editing it and seeing what you are executing.
sh chkconfig.install or ./chkconfig.install ; which might work....but my suggestion would be to learn to use update-rc.d as the other answers have suggested but do not speak directly to the question...which is pretty hard to answer without being able to look at the data yourself.
As mentioned by #jerry you can add services with the below command.
update-rc.d <service> defaults
update-rc.d <service> start 20 3 4 5
update-rc.d -f <service> remove
To validate them check the above commands you can check /etc/rc*.d/ directory where service start with "k" means it will not execute during the boot and service start with "S" will start during the boot.
# for runlevel symlinks:
ls /etc/rc*.d/
In the below screenshot you can see apache2 starting in runlevel2(S02apache2) and stopping in runlevel1(K01apache2)
You can also check the service status with the below command where "+" means service is in running state "-" is in stopped.
service --status-all
OR
install sysv-rc-conf utility.
apt-get install sysv-rc-conf
example
sysv-rc-conf --level 2345 apach22 on
man sysv-rc-conf
Related
I want to remove Kubernetes from a Debian machine (I didn't do the setup)
I followed the instructions from How to completely uninstall kubernetes
kubeadm reset
sudo apt-get purge kubeadm kubectl kubelet kubernetes-cni kube*
sudo apt-get autoremove
sudo rm -rf ~/.kube
But it seems to be still installed:
# which kubeadm
/usr/local/bin/kubeadm
# which kubectl
/usr/local/bin/kubectl
# which kubelet
/usr/local/bin/kubelet
Also, apt list --installed | grep kube* does not return anything, so it make me think it was not installed via apt
Do you know how to clean this machine ? Should I just rm /usr/local/bin/kubectl etc ? I don't really like this idea..
Thanks for help
The method suggested by Rib47 on the answer you indicated is correct to completely remove and clean Kubernetes installed with apt-get.
As mentioned by underscore_d, /usr/local/bin/ isn't the directory where the packages installed by apt-get are placed.
For example, when you install kubectl using apt-get, it's placed on /usr/bin/kubectl and that's what is going to be removed by apt-get purge.
I tested it on my kubeadm cluster lab and I don't have these files at /usr/local/bin/.
You have to revisit all the steps you followed during the install process to know how exactly these files got there.
If you run kubeadm reset, I would say it's safe to remove these files. I suggest you to check if they are being used before removing using the command fuser. This command might not be installed in your linux and you can install it by running sudo apt-get install psmisc. After installing you can run it as in this example:
$ sudo fuser /usr/bin/kubelet
/usr/bin/kubelet: 21167e
It means this file is being used by process number 21167.
Checking this process we can see what's using it:
$ ps -aux | grep 21167
root 21167 4.1 0.5 788164 88696 ? Ssl 08:50 0:07 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=cgroupfs --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.2
If the files related to kubernetes you have under /usr/local/bin/ are not in use, I would remove them with no worries.
I have installed on my Vbox Parrot-Security 32bit
After a day, I got error while booting machine.
/dev/sda1: clean, 450934/1523712 files 3510770/6092032 blocks
I got :
TOMOYO: Default profile doesn't exist.
TOMOYO: Select a profile from the following list.
After this its looks it want input but when i type help, ? , /? , --help, -h its says:
TOMOYO: Select a profile from the following list.
disable
Anyone know what happened and how I can fix this?
I bypassed this by presing 'e' in GNU GRUB and in line which starts with linux i changed (ro initrd=/install/...) with rw init=/bin/bash (run this with ctrl-x)and when shell starts I run exec /sbin/init.
I saw in boot editor in linie linux ... there is:
security=tomoyo i could change that or no?
when you boot parrot you will see error type this:
1- disable
2- sudo apt install parrot-core
3- sudo apt autoremove
4- sudo apt autoclean
5- sudo apt update && sudo apt dist-upgrade
6- sudo reboot
after rebooting you will be a little bit confused because you will notice some changes in terminal fonts and some icons, etc..
Don't worry this an update and we all got it after updating Parrot.
How can I check for a package service name so that I could use it for 'systemctl enable' on RHEL7.
The easiest way is to simply look at the list of unit files installed by the package, e.g.:
$ rpm -ql openssh-server | grep '\.service'
/usr/lib/systemd/system/sshd-keygen.service
/usr/lib/systemd/system/sshd.service
/usr/lib/systemd/system/sshd#.service
I have installed elasticsearh on a server based on Cent OS 6.5. To start it:
# cd /usr/share/elasticsearch/elasticsearch-1.5.2]
# ./bin/elasticsearch &
But when I close the terminal, the process is killed. How can I set it to automatically start as a service?
Try using the "nohup" command with elastic search.
$ nohup ./bin/elasticsearch
Now what the nohup does? In the following example, it starts the program abcd in the background in such a way that the subsequent logout does not stop it.
$ nohup abcd &
$ exit
Hope that helped.
As #DerStoffel said, you have to start elasticsearch as a service (sudo service elasticsearch start). This is highly recommended in production settings. Also add the service to start in case of reboot (sudo /sbin/chkconfig --add elasticsearch)
It depends the distribution of linux you use:
Debian/Ubuntu
sudo update-rc.d elasticsearch defaults 95 10
sudo /etc/init.d/elasticsearch start
https://www.elastic.co/guide/en/elasticsearch/reference/1.6/setup-service.html#_debian_ubuntu
RPM based distributions like Centos
sudo /sbin/chkconfig --add elasticsearch
sudo service elasticsearch start
https://www.elastic.co/guide/en/elasticsearch/reference/1.6/setup-service.html#_rpm_based_distributions
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable elasticsearch.service
sudo /bin/systemctl start elasticsearch.service
go to run jenkins after doing an upgrade, and get the following:
start jenkins
start: Job failed to start
That's it...nothing shows up in jenkin's log...so it is difficult to debug to say the least.
(and it isn't running already, or anything like that).
Is there another log somewhere that I should be looking at that would be helpful?
(I am assuming answer to this problem will be somewhat iterative, so hopefully someone can start me on a path to debug this)
So, knowing it was a pre-start error allowed me to investigate more deeply.
Further digging allowed me to figure out that the exact line in the /etc/init/jenkins.conf file was one pointing to the /usr/share/jenkins/bin/maintain-plugins.sh
Looking at this location, I found it was not present (ie. no bin directory). This means that jenkins-common was no longer installed for some reason...odd indeed...going into apt-get and doing an install of this component again led to the error:
dpkg error processing /var/cache/apt/archives/jenkins-common_1.409.1-0ubuntu4.2_all.deb ...
having seen this error before and refreshing my memory via google gave the following solution:
dpkg -i --force-overwrite /var/cache/apt/archives/jenkins-common_1.409.1-0ubuntu4.2_all.deb
This allowed the installation of common to proceed as normal. After this, all I had to do was replace the /usr/share/jenkins/jenkins.war with my backed up copy (because ubuntu is far behind the latest release version), and I was able to start the server again.
I am not exactly sure what caused the problem to begin with, but it was likely during an apt-get upgrade/clean process...and because of the weirdness with jenkins conflicting with jenkins-common, it did not repopulate the /usr/share/jenkins directory properly.
regardless, am glad it is working again. :)
Instead, you can run the following before the install to properly clean up any conffiles left by the distro version:
sudo apt-get purge jenkins
Then install the correct version.
Ubuntu 18.04 LTS use Java 9 as default java
Jenkins 2.107.2 still use Java 8
[Solution]
Install Java 8 before install Jenkins
sudo add-apt-repository ppa:webupd8team/java
sudo apt install oracle-java8-installer
wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add -
sudo apt-add-repository "deb https://pkg.jenkins.io/debian-stable binary/"
sudo apt install jenkins
See https://stackoverflow.com/a/49937744/900684
I went to see the jenkins logs
tail -f /var/log/jenkins/jenkins.log
In my case it didn't start because I used incompatible java version.
Update and make sure it sees correct java (In my case it should have been opened using JRE 1.7. To check, please use java -version command) and all should work
The following worked for me:
sudo rm /etc/init/jenkins.conf
sudo update-rc.d jenkins defaults
sudo service jenkins start
Then....
root#core:/# service jenkins start
* Starting Jenkins Continuous Integration Server jenkins [ OK ]
Borrowed from: https://groups.google.com/forum/#!msg/jenkinsci-users/eW_yEWLojFc/tFhb8DKoRHUJ
I got from this link: https://serverfault.com/questions/710680/jenkins-not-starting-in-ubuntu
It might be caused by a full disk.
To be really sure, try running it manually. Like this:
/usr/bin/java -Djava.awt.headless=true -jar /usr/share/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080 --ajp13Port=-1