I am new to puppet, it was working just fine till some days ago. I got back to start the server today, running
sudo /etc/init.d/puppetserver start
I then got
Starting puppetserver (via systemctl): puppetserver.serviceJob for puppetserver.service failed. See 'systemctl status puppetserver.service' and 'journalctl -xn' for details.
and journalctl -xn throws
No journal files were found.
failed!
When I check the logs in /var/log/puppetlabs/puppetserver, I get no specific informations. I also noticed that the puppet command that was located in /opt/puppetlabs/puppet/bin but I can't find the bin folder anymore.
Does anyone has an idea ?
EDIT :
Here's the output of systemctl status puppetserver.service
puppetserver.service - LSB: puppetserver
Loaded: loaded (/etc/init.d/puppetserver)
Active: failed (Result: exit-code) since Fri 2017-11-10 10:20:13 UTC; 3h 54min ago
Process: 5490 ExecStart=/etc/init.d/puppetserver start (code=exited, status=2)
and
Related
So i m trying to install a jenkins server on the free instance provided by aws, so I can test things out, problem is that I can connect via ssh using putty to the public ip and my key, but when I try to access the jenkins portal using the public DNS address and the port a timeout is returned
Also if i try to ping the machine from my laptop it returns "Request time out" every time.
Also jenkins server seems to be running and active:
[ec2-user#ip-1235 ~]$ sudo systemctl status jenkins
● jenkins.service - LSB: Jenkins Automation Server
Loaded: loaded (/etc/rc.d/init.d/jenkins; bad; vendor preset: disabled)
Active: active (running) since Mon 2021-11-22 16:14:42 UTC; 7min ago
Docs: man:systemd-sysv-generator(8)
Process: 3693 ExecStart=/etc/rc.d/init.d/jenkins start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/jenkins.service
└─3697 /etc/alternatives/java -Djava.awt.headless=true -DJENKINS_H...
Nov 22 16:14:42 ip-1234.us-east-2.compute.internal systemd[1]: Start...
Nov 22 16:14:42 ip-1234.us-east-2.compute.internal jenkins[3693]: St...
Nov 22 16:14:42 ip-1234.us-east-2.compute.internal systemd[1]: Start...
Hint: Some lines were ellipsized, use -l to show in full.
Wondering whether this is an issue;
I had an engine where i created a backup and stored elsewhere. This engine was reinstalled
and the backup file (called file_name) used to restore below. However i get 2 different
errors based on whether engine is on....
[root#dub-mgrfarm113 ~]# service ovirt-engine status
Redirecting to /bin/systemctl status ovirt-engine.service
● ovirt-engine.service - oVirt Engine
Loaded: loaded (/usr/lib/systemd/system/ovirt-engine.service; disabled; vendor preset:
disabled)
Active: active (running) since Thu 2020-01-16 16:13:41 GMT; 2h 5min ago
Main PID: 5621 (ovirt-engine.py)
CGroup: /system.slice/ovirt-engine.service
├─5621 /usr/bin/python
/usr/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py --redirect-output
--systemd=notify st...
└─5661 ovirt-engine -server -XX:+TieredCompilation -Xms1991M -Xmx1991M -Xss1M
-Djava.awt.headless=true -Dsun.rmi.dgc.clien...
Jan 16 16:13:40 dub-mgrfarm113.ie.oracle.com systemd[1]: Starting oVirt Engine...
Jan 16 16:13:40 dub-mgrfarm113.ie.oracle.com ovirt-engine.py[5621]: 2020-01-16
16:13:40,816+0000 ovirt-engine: INFO _detectJBossV...l=36
Jan 16 16:13:41 dub-mgrfarm113.ie.oracle.com ovirt-engine.py[5621]: 2020-01-16
16:13:41,795+0000 ovirt-engine: INFO _detectJBossV...'[]'
Jan 16 16:13:41 dub-mgrfarm113.ie.oracle.com systemd[1]: Started oVirt Engine.
Hint: Some lines were ellipsized, use -l to show in full.
[root#dub-mgrfarm113 ~]# engine-backup --mode=restore --file=file_name
--restore-permissions
Start of engine-backup with mode 'restore'
scope: all
archive file: file_name
log file: /var/log/ovirt-engine-backup/ovirt-engine-restore-20200116181932.log
Preparing to restore:
FATAL: Engine service is active - can not restore backup
or off.......
[root#dub-mgrfarm113 ~]# service ovirt-engine stop
Redirecting to /bin/systemctl stop ovirt-engine.service
[root#dub-mgrfarm113 ~]# engine-backup --mode=restore --file=file_name
--restore-permissions
Start of engine-backup with mode 'restore'
scope: all
archive file: file_name
log file: /var/log/ovirt-engine-backup/ovirt-engine-restore-20200116181952.log
Preparing to restore:
- Unpacking file 'file_name'
Restoring:
- Files
FATAL: Can't connect to database 'engine'. Please see
'/usr/bin/engine-backup --help'.
In addition, possibly related, the web page for the server will no longer launch even when
ovirt-engine and httpd services are running while.
Any troubleshooting tips or has anyone seen same before?
I'm running Manjaro 18.1.0 and using the interception-caps2esc 0.1.3-2 plugin via AUR. My /etc/udevmon.yaml and /etc/systemd/system/udevmon.service are setup as described in the answer here. This has been working fine for months, but has now suddenly stopped working. I tried re-booting.
I'm quite stumped as to what's caused the difference. I notice, however, that running systemctl status udevmon.service returns
● udevmon.service - udevmon
Loaded: loaded (/etc/systemd/system/udevmon.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Sun 2019-10-13 16:34:06 CEST; 20min ago
Main PID: 7749 (code=dumped, signal=SEGV)
Oct 13 16:34:06 my-pc systemd[1]: Started udevmon.
Oct 13 16:34:06 my-pc systemd[1]: udevmon.service: Main process exited, code=dumped, status=11/SEGV
Oct 13 16:34:06 my-pc systemd[1]: udevmon.service: Failed with result 'core-dump'.
which I suppose is relevant. systemctl reset-failed does not help, and my understanding of systemd and the workings of caps2esc is too limited to identify relevant next steps for solving this problem or for troubleshooting.
My question: What steps can I take to resolve or further troubleshoot this issue?
I experienced the same issue and was able to resolve it by reinstalling interception-tools and interception-caps2esc (I'm using yay):
yay -S interception-tools
yay -S interception-caps2esc
And then restarting the udevmon service:
sudo systemctl restart udevmon.service
I can't explain why it broke or why this fixes it but it did for me.
I am new to docker and cannot understand these errors. So, Please let me know if any more information is needed.
`$ docker --version`
Docker version 1.12.6, build 88a4867/1.12.6
`$ docker info`
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
`$sudo dockerd`
FATA[0000] unable to configure the Docker daemon with file /etc/docker/daemon.json: EOF
`$sudo systemctl start docker`
Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.
`$sudo systemctl status docker.service -l`
● docker.service - Docker Application Container Engine
Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2017-07-26 14:30:21 EDT; 8min ago
Docs: http://docs.docker.com
Process: 5835 ExecStart=/usr/bin/dockerd-current --add-runtime docker-runc=/usr/libexec/docker/docker-runc-current --default-runtime=docker-runc --authorization-plugin=rhel-push-plugin --exec-opt native.cgroupdriver=systemd --userland-proxy-path=/usr/libexec/docker/docker-proxy-current $OPTIONS $DOCKER_STORAGE_OPTIONS $DOCKER_NETWORK_OPTIONS $ADD_REGISTRY $BLOCK_REGISTRY $INSECURE_REGISTRY (code=exited, status=1/FAILURE)
Main PID: 5835 (code=exited, status=1/FAILURE)
Jul 26 14:30:21: Starting Docker Application Container Engine...
Jul 26 14:30:21 dockerd-current[5835]: time="2017-07-26T14:30:21-04:00" level=fatal msg="unable to configure the Docker daemon with file /etc/docker/daemon.json: EOF\n"
Jul 26 14:30:21 systemd[1]: docker.service: main process exited, code=exited, status=1/FAILURE
Jul 26 14:30:21 systemd[1]: Failed to start Docker Application Container Engine.
Jul 26 14:30:21 systemd[1]: Unit docker.service entered failed state.
Jul 26 14:30:21 systemd[1]: docker.service failed.
Please let me know if I need to check anything else.
The file /etc/docker/daemon.json should not be present or if it is present then it should have a valid JSON object. A blank file would create an error. Either delete the file or if you want to have a blank file then have it with below content
{
}
This will create a blank json object
I have same problem. But I am edited the file /etc/docker/daemon.json and added to it some options. If string with option is not last it have to end with comma character(,).
In root user, type :
$ nano /etc/docker/daemon.json
Ff the file show blank or nothing text, then you just add :
{
}
then save and exit.
Then try to restart docker using
$ service docker restart
In my case just remove that's file using this command
$sudo rm /etc/docker/daemon.json
and then restar the service
$sudo systemctl restart docker.service
$sudo systemctl status docker.service
I dowloaded and installed jenkins with the following commands on redhat
(3.10.0-327.el7.x86_64 #1 SMP Thu Oct 29 17:29:29 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux)
sudo wget https://pkg.jenkins.io/redhat-stable/jenkins-2.32.2-1.1.noarch.rpm
rpm -ivh jenkins-2.32.2-1.1.noarch.rpm
And I started jenkins with the command
sudo service jenkins start
I got the output
Starting jenkins (via systemctl): [ OK ]
But jenkins is not running.
I tried ps ax | grep -i jenkins and no process named jenkins is running.
I tried service --status-all and i can't see jenkins.
I tried to access ip:8080 which is also not showing anything.
But with systemctl status jenkins.service I can see that it started
● jenkins.service - LSB: Jenkins Continuous Integration Server
Loaded: loaded (/etc/rc.d/init.d/jenkins)
Active: active (exited) since Fri 2017-02-10 16:07:42 EST; 2min 7s ago
Docs: man:systemd-sysv-generator(8)
Process: 16649 ExecStop=/etc/rc.d/init.d/jenkins stop (code=exited, status=0/SUCCESS)
Process: 16672 ExecStart=/etc/rc.d/init.d/jenkins start (code=exited, status=0/SUCCESS)
Feb 10 16:07:42 AWSINTDEV11.equinoxfitness.com systemd[1]: Starting LSB: Jenkins Continuous Integration Server...
Feb 10 16:07:42 AWSINTDEV11.equinoxfitness.com runuser[16673]: pam_unix(runuser:session): session opened for user jenkins by (uid=0)
Feb 10 16:07:42 AWSINTDEV11.equinoxfitness.com jenkins[16672]: Starting Jenkins [ OK ]
Feb 10 16:07:42 AWSINTDEV11.equinoxfitness.com systemd[1]: Started LSB: Jenkins Continuous Integration Server.
For future reference and those who doesn't bother to read the comments. Besides checking the system logs you should check the Jenkins log, which on most *nix systems is located in /var/log/jenkins/jenkins.log. In this case it was insufficient permissions to /var/libs/jenkins.
BTW, If you can't find any errors in that log either, then you probably have some sort of ip-table issue where the Jenkins server can't be accessed from the outside.