I have a shell script which renews a LetsEncrypt SSL certificate. If I run it from a bash prompt it works fine. If I execute from the crontab it gets triggered but none of the commands seem to be executed.
The script is:
sudo systemctl stop nginx
sudo docker stop home-assistant
sudo certbot renew
sudo docker start home-assistant
sudo systemctl start nginx
If I examine the letsencrypt log afterwards (/var/log/letsencrypt/letsencrypt.log) there is no trace of the "certbot renew" command having been executed if it's run from cron. If I run it manually I see entries in this log.
syslog has this for the time the cron job is executed:
Sep 1 19:27:01 HP-MICROSERVER cron[106193]: (myuser) RELOAD (crontabs/myuser)
Sep 1 19:27:01 HP-MICROSERVER CRON[107237]: (myuser) CMD (bash -l /usr/bin/sudo /home/myuser/renew_ssl.sh)
Sep 1 19:27:01 HP-MICROSERVER postfix/pickup[106963]: 6E68F132832: uid=1000 from=<myuser>
Sep 1 19:27:01 HP-MICROSERVER postfix/cleanup[107242]: 6E68F132832: message-id=<20220901182701.6E68F132832#HP-MICROSERVER.localdomain>
Sep 1 19:27:01 HP-MICROSERVER postfix/qmgr[102195]: 6E68F132832: from=<myuser#HP-MICROSERVER.localdomain>, size=717, nrcpt=1 (queue active)
Sep 1 19:27:01 HP-MICROSERVER postfix/local[107244]: warning: dict_nis_init: NIS domain name not set - NIS lookups disabled
Sep 1 19:27:01 HP-MICROSERVER postfix/local[107244]: 6E68F132832: to=<myuser#HP-MICROSERVER.localdomain>, orig_to=<myuser>, relay=local, delay=0.07, delays=0.04/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to mailbox)
Sep 1 19:27:01 HP-MICROSERVER postfix/qmgr[102195]: 6E68F132832: removed
I've added this to /etc/sudoers to enable the script to run as sudo from the cron:
myuser ALL=(root) NOPASSWD: /home/myuser/renew_ssl.sh
Any idea what I need to do to get this to execute properly from the crontab?
The problem was resolved by using sudo crontab -e to run the script as root (it was a permissions issue)
Related
in my MAC with Ventura os I can't run yarn on fish shell:
fish: Unknown command: yarn
I tried to run the following command according to the documentation:
set -U fish_user_paths (yarn global bin) $fish_user_paths
After running it, yarn works fine on fish shell.
However after reboot it stops working again.
I tried also to edit the config.fish file with:
if status is-interactive
# Commands to run in interactive sessions can go here
end
set -U fish_user_paths (yarn global bin) $fish_user_paths
But after reboot nothing changes...
In the variables I see:
fish_user_paths /Users/myusername/.yarn/bin
'/Users/myusername/.yarn/bin' '/usr/local/bin' '/System/Cryptexes/App/usr/bin' '/usr/bin' '/bin' '/usr/sbin' '/sbin'
However in the /Users/myusername/.yarn/bin path I see:
~/.y/bin> ls -la
total 0
drwxr-xr-x 3 myusername group 96 Feb 7 15:29 ./
drwxr-xr-x 3 myusername group 96 Feb 7 15:29 ../
lrwxr-xr-x 1 myusername group 59 Feb 7 15:29 create-next-app# -> ../../.config/yarn/global/node_modules/.bin/create-next-app
Can anyone please help?
I have an installed vertica cluster with 3 hosts. I want to do autostart database when starting the hosts (when all hosts were shutdown and now I turn on them). At every host in /etc/init.d/ I added script myscript.sh:
sudo -u myuser /opt/vertica/bin/admintools -t start_db -d test
When I run this script manually, it works and database is starting. But when the script is launched at OS startup, the database does not start. In the adminTools.log log I don't see startup errors, I see only pexpecting vsql command... and All nodes in db test are in state DOWN
2020-06-08 16:42:08.526 agent/752:0x7f195dffb700 [vsql._just_connect] <INFO> pexpecting vsql command: /opt/vertica/bin/vsql --no-vsqlrc -n -p 5433 -U myuser -h 192.168.0.5 test -P pager -A
2020-06-08 16:42:08.984 agent/752:0x7f195dffb700 [vsql._just_connect] <INFO> pexpecting vsql command: /opt/vertica/bin/vsql --no-vsqlrc -n -p 5433 -U myuser -h 192.168.0.6 test -P pager -A
2020-06-08 16:42:09.459 agent/752:0x7f195dffb700 [vsql._just_connect] <INFO> pexpecting vsql command: /opt/vertica/bin/vsql --no-vsqlrc -n -p 5433 -U myuser -h 192.168.0.7 test -P pager -A
2020-06-08 16:43:05.639 admintools/3701:0x7f456298c740 [adminExec.getCollapsedClusterState] <INFO> All nodes in db test are in state DOWN
Why is that?
Yes, my OS is Centos 7
But service verticad doesn't work
I run systemctl start verticad
Then I run: systemctl status verticad
verticad.service - Vertica server restart oneshot
Loaded: loaded (/etc/systemd/system/verticad.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Thu 2020-06-11 07:19:43 MSK; 38min ago
Process: 650 ExecStart=/opt/vertica/sbin/verticad start (code=exited, status=0/SUCCESS)
Main PID: 650 (code=exited, status=0/SUCCESS)
Jun 11 07:19:09 verticaserv1 systemd[1]: Starting Vertica server restart oneshot...
Jun 11 07:19:13 verticaserv1 su[706]: (to mydba) root on none
Jun 11 07:19:43 verticaserv1 verticad[650]: Vertica: start OK for users: mydba
Jun 11 07:19:43 verticaserv1 verticad[650]: [ OK ]
Jun 11 07:19:43 verticaserv1 systemd[1]: Started Vertica server restart oneshot.
In logs (/opt/vertica/log/verticad.log and /var/log/messages) I see only:
vertica process is not running
Vertica: start not OK
I am trying to write a systemd service script. Its starts with root user creating nonlogin user and gives him privileges. Then the nologin
user starts the application.
I am on rhel-7.5 (Maipo) with Linux-5.0.7-2019.05.28.x86_64. Here is what I tried.
/root/myhome/my_setup.sh:
#!/bin/bash
# Create nologin user with workingdir. Make hime owner for DB files, binary files he runs.
crdb_setup() {
/bin/mkdir -p /var/lib/lsraj /root/crdb || return $?
/usr/bin/getent group lsraj || /usr/sbin/groupadd -g 990 lsraj|| return $?
/usr/bin/getent passwd lsraj || /usr/sbin/useradd -u 990 -g 990 \
-c 'CRDB User' -d /var/lib/lsraj -s /sbin/nologin -M -K UMASK=022 lsraj || return $?
/bin/chown lsraj:lsraj /var/lib/lsraj /root/crdb /root/myhome/cockroach || return $?
}
crdb_setup
[root#lsraj ~]#
total 99896
-rwxr-xr-x 1 root root 102285942 Jun 18 16:54 cockroach
-rwxr-xr-x 1 root root 521 Jun 18 17:07 my_setup.sh
[root#lsraj ~]#
Service script:
[root#lsraj~]# cat /usr/lib/systemd/system/lsraj.service
[Unit]
Description=Cockroach Database Service
After=network.target syslog.target
[Service]
Type=notify
# run the script with root privileges. The script creates user and gives him privileges.
ExecStartPre=+/root/myhome/my_setup.sh
User=lsraj
Group=lsraj
WorkingDirectory=/var/lib/lsraj
ExecStart=/root/myhome/cockroach start --insecure --host=localhost --store=/root/crdb
ExecStop=/root/myhome/cockroach quit --insecure --host=localhost
StandardOutput=journal
Restart=on-failure
RestartSec=60s
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=cockroachdb
[Install]
WantedBy=multi-user.target
[root#lsraj~]#
Jun 18 17:30:51 lsraj systemd: [/usr/lib/systemd/system/lsraj.service:8] Executable path is not absolute, ignoring: +/root/myhome/my_setup.sh
Jun 18 17:30:51 lsraj systemd: Starting Cockroach Database Service...
Jun 18 17:30:51 lsraj systemd: Failed at step USER spawning /root/myhome/cockroach: No such process
Jun 18 17:30:51 lsraj systemd: lsraj.service: main process exited, code=exited, status=217/USER
Jun 18 17:30:51 lsraj systemd: Failed at step USER spawning /root/myhome/cockroach: No such process
Jun 18 17:30:51 lsraj systemd: lsraj.service: control process exited, code=exited status=217
Jun 18 17:30:51 lsraj systemd: Failed to start Cockroach Database Service.
Jun 18 17:30:51 lsraj systemd: Unit lsraj.service entered failed state.
Jun 18 17:30:51 lsraj systemd: lsraj.service failed.
I've moved my comment here to support richer formatting.
I can not advise on your need for the '+', I am only reading the error message for you which says systemd is ignoring the ExecStartPre path because it is not absolute.
Maybe this is a feature that exists in freedesktop.org, but my Redhat 7.6 release (which is what you indicate that you are using) does not include a similar statement (or table) in the systemd.service unit file man page. Plus you are getting a very clear error message about that line in your unit file.
The man page it mentions "-" and "#", but none of the others...
Here is an extract from the man page (and I've provided a link above to the full page).
ExecStartPre=, ExecStartPost=
Additional commands that are executed before or after the command in ExecStart=, respectively. Syntax is the same as for ExecStart=, except that multiple command lines are
allowed and the commands are executed one after the other, serially.
If any of those commands (not prefixed with "-") fail, the rest are not executed and the unit is considered failed.
Note that ExecStartPre= may not be used to start long-running processes. All processes forked off by processes invoked via ExecStartPre= will be killed before the next service
process is run.
I suggest trying to remove the "+" first and see what happens, then progress from there.
I am able to run arbitrary shell commands in a container created from docker/whalesay image.
$ docker run docker/whalesay ls -l
total 56
-rw-r--r-- 1 root root 931 May 25 2015 ChangeLog
-rw-r--r-- 1 root root 385 May 25 2015 INSTALL
-rw-r--r-- 1 root root 1116 May 25 2015 LICENSE
-rw-r--r-- 1 root root 445 May 25 2015 MANIFEST
-rw-r--r-- 1 root root 1610 May 25 2015 README
-rw-r--r-- 1 root root 879 May 25 2015 Wrap.pm.diff
drwxr-xr-x 2 root root 4096 May 25 2015 cows
-rwxr-xr-x 1 root root 4129 May 25 2015 cowsay
-rw-r--r-- 1 root root 4690 May 25 2015 cowsay.1
-rw-r--r-- 1 root root 54 May 25 2015 install.pl
-rwxr-xr-x 1 root root 2046 May 25 2015 install.sh
-rw-r--r-- 1 root root 631 May 25 2015 pgp_public_key.txt
$ docker run docker/whalesay lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.2 LTS
Release: 14.04
Codename: trusty
However, I am unable to run a shell in a container created from this image.
$ docker run docker/whalesay bash
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7ce600cc9904 docker/whalesay "bash" 5 seconds ago Exited (0) 3 seconds ago loving_mayer
Why did it not work? How can I make it work?
If you docker run without attaching a tty, and only call bash, then bash finds nothing to do, and it exits. That's because by default, a container is non-interactive, and a shell that runs in non-interactive mode expects a script to run. Absent that, it will exit.
To run a disposable new container, you can simply attach a tty and standard input:
docker run --rm -it --entrypoint bash <image-name-or-id>
Or to prevent the above container from being disposed, run it without --rm.
Or to enter a running container, use exec instead:
docker exec -it <container-name-or-id> bash
In comments you asked
Do you know what is the difference between this and docker run -it --entrypoint bash docker/whalesay?
In the two commands above, you are specifying bash as the CMD. In this command, you are specifying bash as the ENTRYPOINT.
Every container is run using a combination of ENTRYPOINT and CMD. If you (or the image) does not specify ENTRYPOINT, the default entrypoint is /bin/sh -c.
So in the earlier two commands, if you run bash as the CMD, and the default ENTRYPOINT is used, then the container will be run using
/bin/sh -c bash
If you specify --entrypoint bash, then instead it runs
bash <command>
Where <command> is the CMD specified in the image (if any is specified).
root ~$ shutdown
-sh: shutdown: not found
root ~$ shutdown -h now
-sh: shutdown: not found
None of the commands are working . I think I need to link the command from scratch. Can anybody guide?
uname -a
gives
2.6.35.3 #49 PREEMPT Wed Jun 11 20:03:43 IST 2014 armv5tejl GNU/Linux
Try to call the command with complete path: /sbin/shutdown
moreover on most systems it is a root only command, so you should call it from root user (I am seeing the $ at the end of command prompt, so I am guessing you are not root)
Other commands you can try are presented here;
or you can use the init 0 command always as root user.
Writing the shutdown code is a last costly resort only if all the other alternatives fail.