Can upstart be installed along side other init system? Upstart is quite handy in creating a daemon script written in PHP as it can respawn process. Unfortunately, it will be replace with systemd in the next ubuntu release. And how about other Linux distro? Centos, RedHat.
Yes, Upstart can be installed alongside system V init scripts. But, I would recommend using other process monitoring tools like "monit" over upstart because of the following reasons:
a. upstart scripts are too low level.
b. All debian systems(includes ubuntu) will be moving away from upstart back to systemd. Reference here.
Related
I have a Perl script which I tried to use PAR::Packer in order to make it a standalone executable so it runs without having Perl on the target machine (because of security reasons).
I used WSL on Windows to pack the Perl script, but the problem I have when I run it on the target machine is the error: "version `GLIBC_2.29' not found".
I ran the command ldd --version and the version on the target machine is 2.17.
The problem I am facing is I cannot install anything on the target machine so I cannot install Perl + PAR::Packer to compile the script and then distribute it to the other machines that are gonna use the script (it's gonna be used in an image so lots of machines).
I cannot seem to find a solution or alternative for this, would love any help from the community.
Edit:
the ubuntu on my WSL was ubuntu 22, the target machines runs redhat and not debian variant, IDK which version as they are a custom linux made by the company i work in.
why am i stuck?
the main problem is that PAR::Packer isn't working on old ubuntu builds ( before 14) and at ubuntu 14 the glibc is already 2.22 while on version 12 its 2.15 so I need to compile the script on old ubuntu (version 12) but the compiling program (PAR::Packer) only works on ubuntu 14 and above so I am stuck in a loop and would apprentice any help or even alternatives for this problem.
Thanks!
Edit: the ubuntu on my WSL was ubuntu 22, the target machines runs redhat
Your problem is that you are trying to build on newer Linux machine, and run the resulting binary on older Linux. That doesn't work (without additional effort).
The simplest solution is to build on the oldest Linux distribution you need to support, possibly in a docker container.
Some other solutions are listed here.
I'm traing to use buildroot and compile new embedded system for testing.
Everything looks ok I use last kernel 4.9.16 and buildroot is from 02.2017. After compiling I can't install grub2 there's now grub software on new root file system and second there's now bash in /bin and anywhere? There's only ash shell.
It's weird because the same procedure I made on mint 17 couple days ago and it works like a charm. I changed disk in my laptop and now I'm using fresh manjaro. I don't think this could be a problem because when I compile new system I can't chose bash in menu but I chose grub2 as bootloader.
Regarding bash: Buildroot by default only installs Busybox, which provides a more minimalistic shell called ash, which is sufficient for most purposes. If you really need bash, you can also get it by enabling it in the Buildroot menuconfig.
Regarding grub2, please have a look at the help text of the Grub2 option in Buildroot, it explains how to install it.
Background: I have created an Ubuntu VirtualBox from LAPP stack and added the Ubuntu desktop (Unity: sudo apt-get install ubuntu-desktop). Now I am attempting to install the MCR without loosing Unity.
Download MCR zip and extract to MCR_SOURCE
Go to my folder that contains the files: cd /media/sf_shared/MCR_ SOURCE
Change installer_input.txt file:
destinationFolder=/opt/MCR
agreeToLicense=yes
outputFile=/opt/install.log
mode=silent
product.MATLAB
product.MATLAB_Builder_JA
# Note: To find out the required toolboxes >> start Matlab >> run your code and find out which toolboxes were used with: license('inuse')
Install MCR: sudo ./install -inputFile /media/sf_shared/MCR_SOURCE/installer_input.txt >> success
Restart Ubuntu >> test whether Ubuntu’s Unity still exists >> everything is fine
Attention the next step will “ kill ” your Ubuntu desktop configuration!!! (i.e. copy your hardisk, anything you must do to recover quickly) – now configure: sudo gedit /etc/environment
LD_LIBRARY_PATH="/opt/MCR/v84/runtime/glnxa64:/opt/MCR/v84/bin/glnxa64:/opt/MCR/v84/sys/os/glnxa64:${LD_LIBRARY_PATH}"
XAPPLRESDIR="/opt/MCR/v84/X11/app-defaults"
# Note: X11/app-defaults folder has not been created during installation
Restart Ubuntu >> Unity is gone, recovery attempts such as deleting the above lines do not recover Unity; reinstalling the Ubuntu desktop does not help either.
I have tried an alternative route with exporting the variables, which also "kills" Unity. By the way this affects all users.
Any ideas?
It is not necessary to register these environment variables in /etc/environment, which means that the Unity sidebar will not be affected.
Instead register the environment variables temporarily either as local user or via sudo -i:
export LD_LIBRARY_PATH="/opt/MCR/v84/runtime/glnxa64:/opt/MCR/v84/bin/glnxa64:/opt/MCR/v84/sys/os/glnxa64:${LD_LIBRARY_PATH}"
export XAPPLRESDIR="/opt/MCR/v84/X11/app-defaults"
Now it is possible to run Matlab Apps without "killing" Ubuntu's desktop. For instance to run the Java compiled makesqr.m file.
java -classpath "/opt/MCR/v84/toolbox/javabuilder/jar/javabuilder.jar:/media/sf_shared/for_testing/makesqr.jar" makesqr.Class1 5
The Java package makesqr was created using Matlab's JavaBuilder tutorial. This was done on my Windows 7 machine, which runs Matlab R2014b.
Please ensure that the owner and permissions of the /opt/MCR and /media/sf_shared/for_testing folders are set correctly (see here for details).
For Linux installer, we have added a custom launcher for auto start of service (see pic below).
We are using install4j v5.1.6. It creates a link in /etc/init.d/myService.sh which points to the /bin/myService.sh .
It works properly in Ubuntu 13. On system restart, service auto starts properly.
On Ubuntu 14 this doesn't work. Service starts first time after installation. But on system restart, service doesn't auto start.
On further investigation, running these commands on Ubuntu 14 enabled auto start.
after installation
cd /etc/init.d
sudo update-rc.d myService.sh defaults
Under installer, install a service, auto start is set to true.
Is this a limitation of install4j that it doesn't register with update-rc.d ?
Do we know on which Linux systems copying to /etc/init.d/ is sufficient ?
Our script is similar to : www.shayanderson.com/linux/add-startup-script-or-service-with-linux-on-bootup.htm . What we don't have is update-rc.d and chkconfig. And install4j does the task of copying it to /etc/init.d/
Thanks !
http://s27.postimg.org/o5bih55kz/Launcher_Configuration.png
http://s3.postimg.org/icitxy96b/Launcher_Setup.png
As of 5.1.x, install4j does not integrate services into runlevels, it only creates the symlink to the start script in /etc/init.d.
Integrating it into runlevels has to be done manually, such as by calling update-rc.d or whatever other tool the particular distribution provides.
Background
I use Anaconda's IPython on my mac and it's a great tool for data exploration and debugging. However, when I wish to use IPython for my programs that require virtualenv (e.g. a Django web app), I don't want to have to reinstall IPython every time.
Question
Is there a way to use my local IPython while also using the rest of my virtualenv packages? (i.e. just make IPython the exception to virtualenv packages so that the local IPython setup is available no matter what) If so, how would you do this on a mac? My guess is that it would be some nifty .bash_profile changes, but my limited knowledge with it hasn't been fruitful. Thanks.
Example Usage
Right now if I'm debugging a program, I'd use the following:
import pdb
pdb.set_trace() # insert this to pause program and explore at command line
This would bring it to the command line (that I wish was IPython)
If you have a module in your local Python and not in the virtualenv, it will still be available in the virtualenv. Unless you shadow it with another virtualenv version. Did you try to launch your local IPython from a running virtualenv that didn't have an IPython? It should work.
Will, I assume you are using Anaconda's "conda" package manager? (Which combines the features of pip and virtualenv). If so you should be aware that many parts of it does not work completely like the tools it is replacing. E.g. if you are using conda create -n myenv to create your virtual environment, this is different from the "normal" virtualenv in a number of ways. In particular, there is no "global/default" packages: Even the default installation is essentially an environment ("root") like all other environments.
To obtain the usual virtualenv behavior, you can create your environments by cloning the root environment: conda create -n myenv --clone root. However, unlike for regular virtualenv, if you make changes to the default installation (the "root" environment in conda) these changes are not reflected in the environments that were created by cloning the root environment.
An alternative to cloning the root is to keep an updated list of "default packages" that you want to be available in new environments. This is managed by the create_default_packages option in the condarc file.
In summary: Don't treat your conda environments like regular python virtualenvs - even though they appear deceptively similar in many regards. Hopefully at some point the two implementations will converge.