On RHEL 8, I have a problem when restarting Gitlab instance on Podman.
Everything works fine but running command: sudo podman restart gitlab-server makes an error:
ERRO[0011] Failed to start transient timer unit: Unit 28e595d7d0812cd0e5e772db55d02d137c4179fcd4aa0527162d28b22d169ee3.service already exists.
When I list all services, I can see above service with "load failed" status.
Error is not making any problems with functionality but it is quite strange what is happening.
Thank You for any advice.
Related
I am trying to add a startup script in my GCP VM Instance to fetch data from a website (web crawler). I wanted to automate the crawling task following this answer. So, I added a startup script in my VM instance. The script looks like below:
#! /bin/bash
python3 /home/sadmanks/site-spider/src/main.py
Then, I wanted to schedule this instance. But when executing this startup script, it doesn't start the program that I want to execute. The log message that I get is following:
"Error restarting service: Failed to try-restart nscd.service: Unit nscd.service not found
I tried to do this in the browser ssh connection: sudo service nscd start outputs:
Failed to start nscd.service: Unit nscd.service not found.
Does anyone have any idea, how to resolve this issue?
Note: The program runs perfectly when I try to connect the instance with an SSH to my local machine.
The error "Error restarting service: Failed to try-restart nscd.service: Unit crond.service not found." is just harmless log spam. These error messages show up on every VM on start-up and are expected since systemd services like crond.service and nscd.service do not exist on COS. So, try updating the version of google-guest-agent service. But as suggested by #John Hanley that service is not related to python, web scraping/crawling, etc. So, make sure you know what the program is doing before running it on public servers.
I have a cluster with RBAC in AKS, and it works just fine, but sometimes (it seems after my laptop goes to sleep) I just get this error and have to create context again:
kubectl error: You must be logged in to the server (Unauthorized)
It does not seem to happen all the time. Sometimes many sleep cycles (few days) passes, sometimes just few hours. It seem totally random.
Would appreciate any help on figuring out why this is happening.
My set up is like that (I don't know if it is important though):
I usually work on Windows Subsystem for Linux 2, but I have the same version of kubectl on windows itself and the config files are the same between the two (I linked kubectl config from linux).
I am pretty sure though I did not use windows kubectl last time it happened, only linux version
I had the same issue with WSL2 and the reason is lack of time sync after laptop sleeping (see https://github.com/microsoft/WSL/issues/4245)
After running sudo hwclock -s I have no more error message and can run kubectl comand.
I use Gitlab for doing Continuous Integration and Development and all of a sudden I get this error message "There has been a runner system failure, please try again"
There's no real error message or error code.
I've tried restarting the gitlab runner, using gitlab-runner restart, I've done a reboot of the server its running on but I keep getting this error message on Gitlab whenever I push a code change.
After a couple of hours, I realized the issue is that the server that Gitlab Runner is running on has no space left.
I logged into the server in question. Looked at the Gitlab log file using the following command:
journalctl -u gitlab-runner
And it showed me the following logs:
May 21 08:20:41 gitlab-runner[18936]: Checking for jobs... received job=178911 repo_url=https://.......git runner=f540b942
May 21 08:20:41 gitlab-runner-01 gitlab-runner[18936]: WARNING: Failed to process runner builds=0 error=open /tmp/trace543210445: no space left on device executor=docker runner=f540b942
To fix this issue I ran docker conatiner prune which clears out stopped containers.
Alternatively you could use docker system prune which would remove all unused objects.
See https://linuxize.com/post/how-to-remove-docker-images-containers-volumes-and-networks/ for more information about those docker commands.
Afterwards, I no longer got the error on Gitlab when pushing changes.
I tried installing docker on a server of mine using this tutorial.
I want to run docker images remotely and use the portainer web-interface to administrate everything.
However, when I get to the point where I need to test my installation and I enter the command $ sudo docker run hello-world, I only get the following error:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:344: starting container process caused "process_linux.go:424: container init caused \"join session keyring: create session key: disk quota exceeded\"": unknown. ERRO[0000] error waiting for container: context canceled
I tried the following methods:
"Install Docker CE / Install using the convenience script"
"Install Docker CE / Install using the repository"
This also happens when I try to run other images (eg. portainer).
I hope this is enough information.
I am new to docker, so I don't know how I should debug it efficiently.
Try to increase maxkeys kernel parameter:
echo 50000 > /proc/sys/kernel/keys/maxkeys
see: https://discuss.linuxcontainers.org/t/error-with-docker-inside-lxc-container/922/2
So, as it turns out, I connected to the wrong vServer.
The one I was connected to is using LXD (as you might have seen in my previous comment), which doesn't support Docker (at least not the way this guide advises).
When I ran the same setup on a vServer using a bare-metal(type 1) hypervisor, it worked without a problem.
I think this has to do with automatic storage allocation under LXD, but this is just a guess.
I'm having a problem with PostgreSQL 9.5+173 on Ubuntu 16.04 and I happened to stumble across the following threads in my research that somewhat describes the behavior I'm seeing:
https://www.postgresql.org/message-id/CAFyxdeT%2B%3Dx-d0oNbFPoe%2B4xnt0Qdfi%2BzAEn%2BrQmEK0AZbJFRtg%40mail.gmail.com
https://www.postgresql.org/message-id/562E4453.5090803%40aklaver.com
Long story short I have a fresh install of Ubuntu 16 with nothing on it and PostgreSQL running. I've stopped PostgreSQL changed the data directory and port and a couple other settings and it starts back up fine.
I can start and stop PostgreSQL manually via systemctl without any problems. I can also connect to the database and can verify that it is running via a ps ax | grep postgres.
However, after I reboot PostgreSQL will not start up. Any attempt to start it up via systemctl start postgresql.service doesn't do anything and does not fail. The only way I am able to get it started is if I call systemctl start postgresql#9.5-main.service.
I did some investigation and looked at both the postgresql.service and postgresql#9.5-main.service scripts and realized that the postgresql.service script does nothing as stated in the thread above and that the postgresql#9.5-main.service has the PartOf directive which means it should be getting triggered from the postgresql.service as the sytemd docs state, but it isn't for some reason. Basically I'm at a loss as to why everything works before I reboot and then doesn't work after I reboot. Is there something I'm missing? I'm starting to go CRAZY over something so simple.
Update: I added an ExecStartPre=/bin/touch /tmp/postgresq.log to the postgresql#9.5-main.service to see if it's actually getting called on boot and it is not. Manually calling systemctl start postgresql#9.5-main.service creates the file in the /tmp directory.
Update: I have also found that calling systemd daemon-reload after reboot will allow me to start postgres via the systemctl start postgresql command.
Did you try doing systemctl enable postgresql? This will tell systemd to start this service after boot. Try rebooting after that.
Turns out that the problem was the fact that I symlinked /etc/postgresql/9.5/main/ across partitions to a custom partition that wasn't available right away, so when PostgreSQL tried to start on boot it couldn't because it's configuration files were not available. This describes what was happening since I could start PostgreSQL manually after I logged in.