Using the answer from Easy way of loading projects with rebar dependencies, dependencies are now automatically resolved, but they are not automatically loaded.
So, how can I load all the modules in my ebin and /deps/*/bin path automatically? That way they are available when using the Erlang shell tab completion, which speeds up my dev process considerably.
My solution based on the great answer of Adam Lindberg: https://gist.github.com/1131312 It will only load the project modules automagically, so almost no delay in erl startup.
This snippet would do the trick:
[code:ensure_loaded(list_to_atom(filename:rootname(filename:basename(F))))
|| P <- code:get_path(), F <- filelib:wildcard(P ++ "/*.beam")].
Put it in your ~/.erlang file as one row (including the dot: .) and it will be executed upon starting any Erlang shell. Be warned though, it's hideously slow!
» time erl -noshell -s init stop
erl -noshell -s init stop 0.11s user 0.02s system 11% cpu 1.143 total # Without
» time erl -noshell -s init stop
erl -noshell -s init stop 7.31s user 1.08s system 88% cpu 9.480 total # With
if you spawn the process, you will get a very fast start.
LP = fun() -> [code:ensure_loaded(list_to_atom(filename:rootname(filename:basename(F)))) || P <- code:get_path(), F <- filelib:wildcard(P ++ "/*.beam")] end.
spawn(LP).
in the ~/.erlang file
Related
I want to use nodemon, but still have the use of my terminal, so I ran
$ nodemon &> site.log &
But as soon as I type a single character at the prompt, nodemon stops with this message.
[1] + 45260 suspended (tty input) nodemon &> site.log
What's going on? How can I make this stop happening?
I'm running zsh on MacOS.
EDIT:
I found this answer which explains it perfectly - apparently nodemon tries to read from stdin, and unix systems will stop processes that try to read from stdin while in the background. So my question now becomes:
How do I get nodemon to stop reading from stdin? And, more generally, is there a way to get an arbitrary process to stop reading from stdin?
I figured it out. I have to redirect /dev/null to the input.
$ nodemon < /dev/null &> site.log &
I am not sure if this is possible without creating my own base image, but I use environment variables in /etc/environment on our servers and typically make them accessible to apache by doing the following:
$ printf "HTTP_VAR1=var1-value\n\
HTTP_VAR2=var2-value"\
>> /etc/environment
$ mkdir /usr/lib/systemd/system/httpd.service.d
$ printf "[Service]\n\
EnvironmentFile=/etc/environment"\
> /usr/lib/systemd/system/httpd.service.d/environment.conf
$ systemctl daemon-reload
$ systemctl restart httpd
$ reboot
The variables are then available in any PHP calls to getenv('HTTP_VAR1'); and etc. However, in running this from a docker file I get dbus errors on the systemctl commands. Without the systemctl commands it seems the variables are not available to apache as it seems the new EnvironmentFile directive doesn't take effect. My docker file snippet:
FROM centos/httpd:latest
RUN printf "HTTP_VAR1=var1-value\n\
HTTP_VAR2=var2-value"\
>> /etc/environment
RUN mkdir /usr/lib/systemd/system/httpd.service.d &&\
printf "[Service]\n\
EnvironmentFile=/etc/environment"\
> /usr/lib/systemd/system/httpd.service.d/environment.conf
RUN systemctl daemon-reload &&\
systemctl restart httpd
COPY entrypoint.sh /entrypoint.sh
So I happened upon the answer to the issue today. It seems that systemd drops backslashes inside single quotes, but it may effect double-quotes too from what I saw in testing. I found the systemd development mailing list thread from April 2014 where patching the issue was being discussed. It seems as though the fix never made it in. So we have to work around it.
In attempting to work around it I noticed some issues with actually reading the variables at all. It seemed as though either Apache or php-cli would get the correct variables, and sometimes not at all, it took a bit of sleuthing to figure out what was going on. Then I started reading into the systemd's EnvironmentFile directive to see if there was more to gain from the docs. It turns out it does not evaluate bash so export won't work. It expects a text file with variable assignments and herein lies one of the main issues that might keep this from being resolved.
I then devised a workable solution. Utilizing systemd's ExecStartPre directive I am able to run a script on startup of the httpd service. I then read in the environment file and write a new plain text one that will then be used by httpd's systemd unit. Here is the code:
Firstly, I moved my variables to /etc/profile.d/ directory rather than /etc/environment file.
file: /etc/profile.d/environment.sh
This is where we store all our environment variables, this gets easily sourced on all interactive shell logins. In the rarer cases where we need to have these variables available non-interactively we can either provide --login flag to /bin/bash or source it manually.
export HTTP_VAR1=var1-value-with-a-back\slash
export HTTP_VAR2=var2-value
file: /usr/lib/systemd/system/httpd.service.d/environment.conf
Our drop-in unit file to extend how the httpd service works. I add in a script that runs before httpd starts up. This gets ran on all httpd restarts and starts. The script that runs generates a plain text file at /etc/profile.d/environment.env which we subsequently tell systemd to load as an EnvironmentFile.
[Service]
ExecStartPre=/usr/bin/bash -c "/usr/local/bin/generate-plain-environment-file"
EnvironmentFile=/etc/profile.d/environment.env
file: /usr/local/bin/generate-plain-environment-file
Here is the script I am using, I whipped this together really fast, I really don't think it is that robust and it could be better. It just removes the export from the beginning of the lines and then escapes any backslashes since systemd drops single backslashes. A more proper solution might be to use bash to evaluate each line and obtain the variable value in case of usage of variables or other bash in the actual bash variables, then output them as plain text name=value assignments, however this is not part of my use-case so I didn't bother.
#!/bin/bash
cd /etc/profile.d/
rm -rf "./environment.env"
while IFS='' read -r line || [[ -n "$line" ]]; do
echo $(echo "${line}" | sed 's/^export //' | sed 's/\\/\\\\/g') >> "./environment.env";
done < "./environment.sh"
file: /etc/profile.d/environment.env
This is the resulting file generated by the described script.
HTTP_VAR1=var1-value-with-a-back\\slash
HTTP_VAR2=var2-value
Conclusion is that the I now have two files with the same thing in them but I only need to maintain the one, the other is generated each time we restart httpd. Also, we fix the backslash issue in the process. Hurray!
I use CocoaPods in my project but every time I change something it takes a long time to generate support files, I know it is not something I can control, but just wonder is it something that it generates for sub-libraries, if so, can I save the existing 'support files' and only let it generate the one for newly added libs?
I run 'pod install' every time when I change the Podfile, is it a problem and I should run 'pod setup' instead?
Thanks!
We are working on it:
# AWSiOSSDK is a good test because it has a lot of files
$ find Pods/AWSiOSSDK | wc -l
3001
# and generates a plist with almost 80k lines
$ wc -l Pods/Pods.xcodeproj/project.pbxproj
79766 Pods/Pods.xcodeproj/project.pbxproj
# CocoaPods 0.15.1
$ time pod install --no-integrate --silent
pod install --no-integrate --silent 216,50s user 1,45s system 83% cpu 4:19,68 total
# Modified CocoaPods
$ time dpod install --no-integrate --silent
COCOA_PODS_ENV=development ~/Documents/GitHub/CP/CocoaPods/bin/pod install 8,03s user 0,67s system 55% cpu 15,802 total
More than 4 minutes vs 16s means that the generate support phase should become pretty fast in CocoaPods 0.16.
From Xcodeproj/pull/34
So I can only suggest to wait :-)
I need to build a C program which requires a particular Linux package. I set a variable, PACKAGENOTIFICATION, to a shell command which is supposed to check if the package is installed for Ubuntu and print a notification if not:
PACKAGENOTIFICATION := if cat /etc/issue | grep Ubuntu -c >>/dev/null; then if ! dpkg -l | grep libx11-dev -c >>/dev/null; then echo "<insert notification here>"; fi; fi
[...]
maintarget: dependencies
$(PACKAGENOTIFICATION)
other_commands
Unfortunately, while making the dependencies, it runs into the files which need the package, and errors out before executing my PACKAGENOTIFICATION. An alternative formulation is to make a separate target whose only purpose is to run the notification:
maintarget: notify other_dependencies
commands
notify:
$(PACKAGENOTIFICATION)
However, since this phantom dependency always needs to be executed, make never reports that the program is up to date.
What's the best way to have make always report as up to date, but also execute my notification before it dies?
Thanks!
If your version of Make supports "order-only" prerequisites, this will do it:
# Note the pipe
maintarget: other_dependencies | notify
commands
# This should be an order-only preq of any target that needs the package
notify:
$(PACKAGENOTIFICATION)
If not, there are other approaches.
I'm trying to make a push notification work on my debian vps (apace2, mysql).
I use a php script from this tutorial (http://www.raywenderlich.com/3525/apple-push-notification-services-tutorial-part-2).
Basically, the script is put in an infintive loop, that check a mysql table for new records every couple of seconds. The tutorial says it should be run as a background process.
// This script should be run as a background process on the server. It checks
// every few seconds for new messages in the database table push_queue and
// sends them to the Apple Push Notification Service.
//
// Usage: php push.php development &
So I have four questions.
How do I start the script from the terminal? What should I type? The script location on the server is:
/var/www/development_folder/scripts/push2/push.php
How can I kill it if I need to (without having to restart apace)?
Since the push notification is essential, I need a way to check if the script is running.
The code (from the tutorial) calls a function is something goes wrong:
function fatalError($message)
{
writeToLog('Exiting with fatal error: ' . $message);
exit;
}
Maybe I can put something in there to restart the script? But It would also be nice to have a cron job or something that check every 5 minute or so if the script is running, and start it if it doens't.
4 - Can I make the script automatically start after a apace or mysql restart? If the server crash or something else happens that need a apace restart?
Thanks a lot in advance
You could run the script with the following command:
nohup php /var/www/development_folder/scripts/push2/push.php > /dev/null &
The nohup means that that the command should not quit (it ignores hangup signal) when you e.g. close your terminal window. If you don't care about this you could just start the process with "php /var/www/development_folder/scripts/push2/push.php &" instead. PS! nohup logs the script output to a file called nohup.out as default, if you do not want this, just add > /dev/null as I've done here. The & at the end means that the proccess will run in the background.
I would only recommend starting the push script like this while you test your code. The script should be run as a daemon at system-startup instead (see 4.) if it's important that it runs all the time.
Just type
ps ax | grep push.php
and you will get the processid (pid). It will look something like this:
4530 pts/3 S 0:00 php /var/www/development_folder/scripts/push2/push.php
The pid is the first number you'll see. You can then run the following command to kill the script:
kill -9 4530
If you run ps ax | grep push.php again the process should now be gone.
I would recommend that you make a cronjob that checks if the php-script is running, and if not, starts it. You could do this with ps ax and grep checks inside your shell script. Something like this should do it:
if ! ps ax | grep -v grep | grep 'push.php' > /dev/null
then
nohup php /var/www/development_folder/scripts/push2/push.php > /dev/null &
else
echo "push-script is already running"
fi
If you want the script to start up after booting up the system you could make a file in /etc/init.d (e.g. /etc.init.d/mypushscript with something like this inside:
php /var/www/development_folder/scripts/push2/push.php
(You should probably have alot more in this file)
You would also need to run the following commands:
chmod +x /etc/init.d/mypushscript
update-rc.d mypushscript defaults
to make the script start at boot-time. I have not tested this so please do more research before making your own init script!