Error in starting postgresql service in linux through command line - linux

I was starting the postgresql service by
systemctl start postgresql.service
It was raising an error as below
Job for postgresql.service failed. See "systemctl status postgresql.service" and "journalctl -xn" for details.
Please help how to start the service through command line in linux?
Output for journalctl -xn
osboxes:/home/osboxes # journalctl -xn
-- Logs begin at Wed 2015-04-08 10:08:38 BST, end at Tue 2016-03-22 14:15:07 GMT. --
Mar 22 14:09:03 osboxes wickedd[824]: eno16777760: Notified neighbours about IP address 192.168
Mar 22 14:09:03 osboxes wickedd[824]: route ipv4 0.0.0.0/0 via 192.168.182.2 dev eno16777760 ty
Mar 22 14:09:04 osboxes wickedd[824]: Skipping hostname update, none available
Mar 22 14:15:01 osboxes cron[9120]: pam_unix(crond:session): session opened for user root by (u
Mar 22 14:15:01 osboxes systemd[9121]: pam_unix(systemd-user:session): session opened for user
Mar 22 14:15:01 osboxes CRON[9120]: pam_unix(crond:session): session closed for user root
Mar 22 14:15:01 osboxes systemd[9122]: pam_unix(systemd-user:session): session closed for user
Mar 22 14:15:07 osboxes postgresql[9160]: Initializing PostgreSQL 9.3.11 at location ~postgres/
Mar 22 14:15:07 osboxes postgresql[9160]: ..failed
Mar 22 14:15:07 osboxes postgresql[9160]: You can find a log of the initialisation in ~postgres

Related

Job for httpd.service failed because the control process exited with error code See "systemctl status httpd.service" and "journalctl -xe" for details

I am unable to restart my apache server to successfully install the SSL certificates.
I get the following error
Job for httpd.service failed because the control process exited with error code. See "systemctl status httpd.service" and "journalctl -xe" for details.
I have tried several articles and the root cause seems to be the following
Mar 29 13:05:09 localhost.localdomain httpd\[1234546\]: (98)Address already in use: AH00072: make_sock: could not bind to address \[::\]:80
Mar 29 13:05:09 localhost.localdomain httpd\[1234546\]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
I am able to diagnose the issue and get the following output and is also attached. I am unable to proceed further. Can you please help ?
Server - AlmaLinux 8
Host - IONOS
Server version: Apache/2.4.37 (AlmaLinux)
-- Unit session-62994.scope has finished starting up.
-
-- Unit session-62994.scope has finished starting up.
-
-- The unit session-62994.scope has successfully entered the 'dead' state.
Mar 31 06:07:10 localhost.localdomain dhclient\[1326\]: XMT: Solicit on ens192, interval 110600ms.
Mar 31 06:07:10 localhost.localdomain dhclient\[1326\]: RCV: Advertise message on ens192 from fe80::250:56ff:fe8c:84c6.
Mar 31 06:07:10 localhost.localdomain dhclient\[1326\]: RCV: Advertise message on ens192 from fe80::250:56ff:fe9a:f13a.
Mar 31 06:07:30 localhost.localdomain sshd\[1297516\]: Invalid user sui from 167.99.68.65 port 48488
Mar 31 06:07:30 localhost.localdomain sshd\[1297516\]: pam_unix(sshd:auth): check pass; user unknown
Mar 31 06:07:30 localhost.localdomain sshd\[1297516\]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=167.99.68.65
Mar 31 06:07:32 localhost.localdomain sshd\[1297516\]: Failed password for invalid user sui from 167.99.68.65 port 48488 ssh2
Mar 31 06:07:34 localhost.localdomain sshd\[1297516\]: Received disconnect from 167.99.68.65 port 48488:11: Bye Bye \[preauth\]
Mar 31 06:07:34 localhost.localdomain sshd\[1297516\]: Disconnected from invalid user sui 167.99.68.65 port 48488 \[preauth\]
Mar 31 06:07:44 localhost.localdomain unix_chkpwd\[1297520\]: password check failed for user (root)
Mar 31 06:07:44 localhost.localdomain sshd\[1297518\]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.177.173.27 user=root
Mar 31 06:07:46 localhost.localdomain sshd\[1297518\]: Failed password for root from 61.177.173.27 port 58626 ssh2
Mar 31 06:07:46 localhost.localdomain unix_chkpwd\[1297521\]: password check failed for user (root)
\[root#localhost \~\]# ss --listening --tcp --numeric --processes
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:80 0.0.0.0:\* users:(("nginx",pid=1087,fd=10),("nginx",pid=1086,fd=10),("nginx",pid=1084,fd=10))
LISTEN 0 128 0.0.0.0:22 0.0.0.0:\* users:(("sshd",pid=1335,fd=5))
LISTEN 0 128 0.0.0.0:443 0.0.0.0:\* users:(("nginx",pid=1087,fd=11),("nginx",pid=1086,fd=11),("nginx",pid=1084,fd=11))
LISTEN 0 128 \[::\]:22 \[::\]:\* users:(("sshd",pid=1335,fd=7))
LISTEN 0 80 \*:3306 *:* users:(("mysqld",pid=1098,fd=19))
Tried -
apachectl configtest - Result: syntax ok
setenforce 0

isc-dhcp-server status failed: Failed with result 'exit code'

I setup a simple dhcp-server with isc-dhcp-server, but when I start the service, the status is in failed with the message "failed with result 'exit code' ".
And yes, I did configure the files /etc/dhcp/dhcp.conf and /etc/default/dhcpd.conf
I checked more information with the command journalctl -ex the show the next input. But I dont know what the input said, because I configured the interface and dhcp server.
I dont know what doing to solve this issue. Somebody know what doing in this case.
This gave me the solution:
$ sudo su
$ systemctl restart isc-dhcp-server.service
$ systemctl status isc-dhcp-server.service
It it still fails like here
root#wd-Latitude-E6530:/home/wd# systemctl status isc-dhcp-server.service
● isc-dhcp-server.service - ISC DHCP IPv4 server
Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2021-06-17 11:29:47 CEST; 56s ago
Docs: man:dhcpd(8)
Process: 2167 ExecStart=/bin/sh -ec CONFIG_FILE=/etc/dhcp/dhcpd.conf; if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf; fi; [ ->
Main PID: 2167 (code=exited, status=1/FAILURE)
jun 17 11:29:47 wd-Latitude-E6530 dhcpd[2167]:
jun 17 11:29:47 wd-Latitude-E6530 dhcpd[2167]: If you think you have received this message due to a bug rather
jun 17 11:29:47 wd-Latitude-E6530 dhcpd[2167]: than a configuration issue please read the section on submitting
jun 17 11:29:47 wd-Latitude-E6530 dhcpd[2167]: bugs on either our web page at www.isc.org or in the README file
jun 17 11:29:47 wd-Latitude-E6530 dhcpd[2167]: before submitting a bug. These pages explain the proper
jun 17 11:29:47 wd-Latitude-E6530 dhcpd[2167]: process and the information we find helpful for debugging.
jun 17 11:29:47 wd-Latitude-E6530 dhcpd[2167]:
jun 17 11:29:47 wd-Latitude-E6530 dhcpd[2167]: exiting.
jun 17 11:29:47 wd-Latitude-E6530 systemd[1]: isc-dhcp-server.service: Main process exited, code=exited, status=1/FAILURE
jun 17 11:29:47 wd-Latitude-E6530 systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
Check the process ID; like 2167 and command:
$ journalctl _PID=2167 {your PID should be different}
For me it gave back:
jun 17 11:30:52 wd-Latitude-E6530 sh[2193]: /etc/dhcp/dhcpd.conf line 57: subnet 10.10.10.1 netmask 255.255.255.0: bad subnet number/mask combination.
jun 17 11:30:52 wd-Latitude-E6530 sh[2193]: subnet 10.10.10.1 netmask 255.255.255.0
In /etc/dhcp/dhcpd.conf I needed to change
subnet 10.10.10.1 netmask 255.255.255.0
into
subnet 10.10.10.0 netmask 255.255.255.0
So 10.10.10.1 into 10.10.10.0
$ systemctl restart isc-dhcp-server.service
$ systemctl status isc-dhcp-server.service
And now I get it working:
Active: active (running) since Thu 2021-06-17 11:50:51 CEST; 2s ago
Your issue might be different, but journalctl _PID=#### will give you some feedback and from there you can troubleshoot.
It looks like you're missing a subnet. I am using this
[...]
subnet 10.10.10.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option broadcast-address 10.10.10.255;
option routers 10.10.10.1;
option domain-name-servers 10.10.10.1;
range 10.10.10.3 10.10.10.250;
if exists user-class and option user-class = "iPXE" {
filename "boot.ipxe";
} else {
filename "undionly.kpxe";
This is part of my iPXE server.
I was following some tech blog for setting up isc-dhcp-server, and I just ended up using the same configuration file (with the same ips, ranges etc).
After 2 days long googling changing machines, and everything, I got nothing, and I figured out that I need to configure the dhcpd.conf file based on my own network interface's (i.e. 'eth0' in my case) ip. And it worked!

Remote port forwarding disconnected when run from cron

I have installed FreeBSD and need to run regularly reverse shell to establish and keep alive SSH connection to the client (no public IP). When running the ssh -R script from the terminal, it works as expected, but when I run it as a cron command, the connection is established and disconnected right after that.
Here is auth.log from the server:
Jan 26 08:50:00 sshd[9696]: Accepted publickey for XXXX from XXX.XXX.XXX.XXX port XXXXX ssh2: RSA SHA256: xxxxxxxxx
Jan 26 08:50:00 sshd[9696]: pam_unix(sshd:session): session opened for user XXXX by (uid=0)
Jan 26 08:50:00 systemd: pam_unix(systemd-user:session): session opened for user XXXX by (uid=0)
Jan 26 08:50:01 systemd-logind[458]: New session 107 of user XXXX.
Jan 26 08:50:01 sshd[9794]: Received disconnect from XXX.XXX.XXX.XXX port XXXXX:11: disconnected by user
Jan 26 08:50:01 sshd[9794]: Disconnected from user XXXX XXX.XXX.XXX.XXX port XXXXX
Jan 26 08:50:01 sshd[9696]: pam_unix(sshd:session): session closed for user XXXX
Jan 26 08:50:01 systemd-logind[458]: Session 107 logged out. Waiting for processes to exit.
Jan 26 08:50:01 systemd-logind[458]: Removed session 107.
Do you have an idea, what causes this behavior and how to fix it?
Solved - see posts above. Thanks

Tor not starting cleanly on boot

I'm running Debian 10 with bitcoind configured as a systemd service that accesses the tor service via localhost. Every reboot the bitcoind error log is filled with the following, and tor services seem to be stuck in a non-working state.
2020-11-18T03:38:30Z connect() to 127.0.0.1:9050 failed after select(): Connection refused (111)
2020-11-18T03:38:30Z connect() to 127.0.0.1:9050 failed after select(): Connection refused (111)
2020-11-18T03:38:31Z connect() to 127.0.0.1:9050 failed after select(): Connection refused (111)
2020-11-18T03:38:31Z connect() to 127.0.0.1:9050 failed after select(): Connection refused (111)
Upon startup systemctl status tor returns the following, indicating tor started successfully
tor.service - Anonymizing overlay network for TCP (multi-instance-master)
Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor preset: enabled)
Active: active (exited) since Tue 2020-11-17 19:54:04 PST; 4min 19s ago
Process: 413 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 413 (code=exited, status=0/SUCCESS)
Nov 17 19:54:04 cryptoDaemon systemd[1]: Starting Anonymizing overlay network for TCP (multi-instance-master)...
Nov 17 19:54:04 cryptoDaemon systemd[1]: Started Anonymizing overlay network for TCP (multi-instance-master).
However tail -f /var/log/tor/notices.log indicates tor hasn't started. There are no entries after the reboot.
If I restart tor.service with sudo systemctl restart tor the error immediately disappears and bitcoind starts to function over tor correctly. This indicates to me that the tor service itself is not starting properly after reboot.
After restarting the service /var/log/notices.log gets new entries:
Nov 17 20:02:22.000 [notice] Tor 0.3.5.10 opening log file.
Nov 17 20:02:22.875 [notice] We compiled with OpenSSL 1010104f: OpenSSL 1.1.1d 10 Sep 2019 and we are running with OpenSSL 1010107f: OpenSSL 1.1.1g 21 Apr 2020. These two versions should be binary compatible.
Nov 17 20:02:22.877 [notice] Tor 0.3.5.10 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1g, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Nov 17 20:02:22.877 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Nov 17 20:02:22.877 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Nov 17 20:02:22.877 [notice] Read configuration file "/etc/tor/torrc".
Nov 17 20:02:22.881 [notice] You configured a non-loopback address '10.1.10.20:9050' for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Nov 17 20:02:22.881 [notice] Opening Socks listener on 127.0.0.1:9050
Nov 17 20:02:22.881 [notice] Opened Socks listener on 127.0.0.1:9050
Nov 17 20:02:22.881 [notice] Opening Control listener on 127.0.0.1:9051
Nov 17 20:02:22.881 [notice] Opened Control listener on 127.0.0.1:9051
Nov 17 20:02:22.881 [warn] Unable to make /var/lib/tor group-readable: Permission denied
Nov 17 20:02:22.881 [warn] Unable to make /var/lib/tor group-readable: Permission denied
Nov 17 20:02:22.000 [notice] Not disabling debugger attaching for unprivileged users.
Nov 17 20:02:22.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Nov 17 20:02:23.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Nov 17 20:02:23.000 [notice] Bootstrapped 0%: Starting
Nov 17 20:02:23.000 [notice] Starting with guard context "default"
Nov 17 20:02:23.000 [notice] Signaled readiness to systemd
Nov 17 20:02:24.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Nov 17 20:02:24.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Nov 17 20:02:24.000 [notice] Opening Control listener on /run/tor/control
Nov 17 20:02:24.000 [notice] Opened Control listener on /run/tor/control
Nov 17 20:02:24.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Nov 17 20:02:25.000 [notice] Bootstrapped 100%: Done
Further investigation reveals that tor is not starting at boot. /var/log/tor/debug.log is empty after reboot. I can even run systemctl start tor and it starts. systemctl start tor won't mess with a service that is already started, so for some reason systemd isn't starting tor, despite it being enabled. Just for fun I disabled with systemctl disable tor and re-enabled, but to no avail.
Any ideas why tor doesn't start?
I also use this server as a Tor SOCKS proxy on the LAN using SOCKSPORT IP.OF.SERVER:9050 in torrc. disabling this and the associated SOCKSPolicy accept IP.OF.SERVER/24 fixed the issue. If anybody has any insight as to why tor behaves this way and doesn't log why, it'd be appreciated.
I fixed it by overriding the systemd configuration for the tor service since i Need the tor Proxy to listen to an actual network interface.
/etc/systemd/system/tor#default.service.d/override.conf
[Unit]
After=network.target nss-lookup.target network-online.target
Wants=network-online.target
Easy way to create the file is systemctl edit tor#default.service

Bug: Varnish 4 install on CentOS 7 (systemctl)

Installed Varnish from yum; but immediate error when initiating via systemctl.
Jul 28 14:11:54 localhost.localdomain varnishd[6546]: .init_func = VGC_function_vcl_init,
Jul 28 14:11:54 localhost.localdomain varnishd[6546]: .fini_func = VGC_function_vcl_fini,
Jul 28 14:11:54 localhost.localdomain varnishd[6546]: };
Jul 28 14:11:54 localhost.localdomain varnishd[6557]: Assert error in main(), mgt/mgt_main.c line 686:
Jul 28 14:11:54 localhost.localdomain varnishd[6557]: Condition((daemon(1,0)) == 0) not true.
Jul 28 14:11:54 localhost.localdomain varnishd[6557]: errno = 19 (No such device)
Jul 28 14:11:54 localhost.localdomain systemd[1]: Failed to read PID from file /var/run/varnish.pid: Invalid argument
Jul 28 14:11:54 localhost.localdomain systemd[1]: varnish.service never wrote its PID file. Failing.
Jul 28 14:11:54 localhost.localdomain systemd[1]: Failed to start Varnish a high-perfomance HTTP accelerator.
Jul 28 14:11:54 localhost.localdomain systemd[1]: Unit varnish.service entered failed state.
SELinux is disabled; package was installed via root. This is a fresh install.
Looks like you need to reboot. ;)
The message:
Failed to read PID from file /var/run/varnish.pid Invalid argument
is non-critical. It is just systemd trying to read the pidfile too early. You can poll status with:
systemctl status varnish
If its "Main PID" entry is matching the contents of /var/run/varnish.pid(and if varnishd is started via systemd, it always does), you can ignore that message. This is fixed in later versions of systemd.

Resources