I have bash script in which via gio mount a webdav share is mounted. The script works perfectly. However, when I call the script via chronjob I get errors. As I have read on the internet, it is because the cronjob not all environment variants are available.
As described on Lorenzo's page, various variables must be set.
https://lbolla.info/gio-in-cronjob.html
It is not clear to me how and where I have to insert the example of Lorenzo. I am using Debian. In the example of Lorenzo is something from Ubuntu, this I must certainly adapt.
Related
So I'm basically wanting to get a script to run on system boot. It's basically an SSH callback. I've tried a few ways that I've gotten to work in the past on other distributions, but having a little bit of difficulty here.
First thing I've tried was adding the /path/to/script.rb to /etc/rc.local. However, this file does not exist on the latest version of Kali Linux. I tried to create it and replicate my old Ubuntu rc.local file, but it didn't run on system startup.
Next thing I tried was creating an executable bash script in /etc/init.d/, following the update-rc.d script.sh defaults and making the file executable. Restarted and nothing. If I run the script manually, it works. I tried to redirect the output to a file in the tmp folder, but it doesn't appear that there are any errors from what I'm understanding.
Are there any other ways to get an auto run script started other than these two methods? Seem to be the most common way to get this working, but it's just not doing it for me.
Add script to
/etc/init.d
Run command:
chmod 755 /etc/init.d/script
Run command:
update-rc.d script enable
So I have a script that is launched on login via rc.local. The script calls a few other scripts to be launched and ran. However the console says that the file and/or directories could not be found. When I run the script manually after the login it works just fine. I have even tried to add a small delay so that I know that the system logged in. Any idea why this is and how to fix it?
Sorry if my answer is a bit vague but from what I understand is that the scripts require to be run via admin privileges. Let me elaborate, when the system starts it runs a set of specific scripts and this differs from distro to distro. Therefore, I'd check ~/.bashrc /etc/profile.dand most importantly ~/.bash_login. See what you can do there. Personally I added it here ~/.config/autostart worked fine. Don't forget to create a .desktop file.
Hope this helps
I am working in a virtual environment, trying to start open vm tools in a chroot environment.
I tested with bash and it seems to work fine.
I used ./configure --options --prefix=/home/chroot_env to install the program, then using ldd on vmtoolsd, i copied the corresponding libraries to the /lib directory.
Now when I start chroot /home/chroot_env /bin/vmtoolsd, nothing happens, the chroot returns directly. Launching the same binary in the normal environment does work.
Does someone have an idea why it isn't working, the correct libraries are there, and it works with bash.
EDIT : strace showed that vmtoolsd is trying to access /dev/console, I added mount --bind /dev/ /home/chroot_env/dev/ but it is still failing.
EDIT2 : another strace showed it was looking for another plugin loaded dynamically, i added it and it worked, conclusion strace is great for debugging such issue!
When you run a program and nothing happens, you can always run it with strace in order to see which syscalls are made. This is an easy way to obtain the list of the files (regular or not) that are opened. In your case, check that your program doesn't try to access a file that is not in the chroot.
I have repackaged a Bash RPM to include automatic logging to syslog. I am trying to work out a way to set this up so that it is used ONLY when a user or service account runs a command as root. The option I'm looking at is installing this version of Bash to an alternate location, and then pointing root to use that version as it's default shell.
Can someone go through the process of installing this RPM to an alternate path and associating the root account to it as the default shell? I have been having difficulty finding a way to do this when searching online.
Since you are repackaging the RPM, it is probably best to change the destination path directly in the RPM.
As for the default shell, run chsh -s /path/to/your/bash root to change it.
Be aware that this solution may not work for all purposes though. For example, running a script that starts with #!/bin/bash will still execute it with /bin/bash instead of your default login shell.
On an OpenSuSE linux machine, I want to run a script when the machine is booted. As the script does not start a service, is /etc/rc.d the correct place for the script?
Thanks.
That's where I've always put them. There are several scripts in rc.d already which don't actually start a process. However, you need to write it in a similar fashion to the other startup scripts - have a look at a few to see how they are set up. Specifically, you should make sure that it's possible to run the script using /etc/rc.d/myscript start.