Restartd is a daemon for checking your running and not
running processes. It reads the /proc directory in every n
secs and does a POSIX regexp on the process names. You can
execute a script/program if the process is not or it is running.
In general, I don't like automated systems that restart processes. If a
process dies unexpectedly, there is a problem that needs to be addressed by a
human. Automatically restarting processes that randomly die makes it too easy
to ignore the underlying problem.
In the case of clamd, the ClamAV daemon, I have acquiesced because I
cannot figure out why it dies randomly every month or two, and have installed
restartd.
The best thing about restartd is it's simplicity. It reads /proc/*/cmdline
every n seconds and compares each command with the list of processes defined in
it's config file. I have it configured to monitor clamd, spamd, and our
in-house Exim log-to-database utility, exidblog, and to call the
appropriate init script to restart a process if it's not running.
The current version of restartd in Debian Sarge (and Sid),
0.1.a-3, is a bit buggy in that it will fail to restart services if it is
started from an interactive session once the session is closed. Based on
suggestions
and code by Glen Turner, I've patched restartd to redirect
stdin/stdout/stderr to /dev/null, change the working directory to /, and
disassociate from the controlling terminal.
I've made the patched Debian package available for download.
Salesforce applications can sometimes be difficult to debug. The debug
log often has the information you need, but finding it isn't always easy.
For example, in a recent project, I needed to figure out why performing an
action from a Visualforce page was causing more SOQL queries than expected,
generating warning emails as we neared the governor limit. This was a large
application that had been under development for about eight years; many different
developers had been involved in various phases of its development.
As with many Salesforce applications that have been through many phases of
development, it wasn't obvious how multiple triggers, workflow rules, and
Process Builder flows were interrelated.
It was easy enough to figure out which SOQL queries were running multiple times
by grepping the debug log, but it wasn't obvious why the method containing the
query was being called repeatedly.
In researching ways to analyze call paths, I found Brendan Gregg's work on flame graphs, which
visualizes call stacks with stacked bar charts. (You might also be familiar
with Chrome's flame
charts.)
Visualizing the call path through stacked bar charts turned out to be a good
way to make sense of the Salesforce debug log.
So I created Apex Flame
to visualize Salesforce debug logs using flame charts or flame graphs.
You can drill in by clicking on a statement, or click on Search to highlight
statements that match a string.
I'd love to get some feedback from other Salesforce developers. Try out Apex Flame, and
let me know what you think.
As for the debugging issue that initially inspired the creation of Apex Flame, it
turned out to be the combination of a trigger that wasn't checking whether the
old and new values of a field were different, causing it to run code
unnecessarily, combined with a workflow rule that was causing the trigger to be
called multiple times.
Another recent case in which it turned out to be helpful was in troubleshooting
a process builder flow that was failing to update child records as expected.
The flow assumed that if the parent record is new (ISNEW()) that
it didn't have child records. It turns out this isn't necessarily true because
a trigger on the parent object can create child records, and the flow runs
after the after insert trigger. The order
of execution is documented, but visualizing the execution order made it
clear what was causing the unexpected behavior.
There are a growing number of spammers exploiting PHP scripts to send spam.
Such scripts are often simple "Contact Us" forms which use PHP's mail()
function. When using the mail() function, it is important to validate any
input coming from the user before passing it to the mail() function.
For example, consider the following simple script.
<?php
$to = 'info@example.com';
$subject = 'Contact Us Submission';
$sender = $_POST['sender'];
$message = $_POST['message'];
$mailMessage = "The following message was received from $sender.\n\n$message";
mail($to, $subject, $mailMessage, "From: $sender");
?>
Such a script looks fairly innocuous. The problem is that sender variable sent
from the client is not sanitized. By manipulating the value sent in the sender
variable, a malicous spammer could cause this script to send messages to
anyone.
Here's an example of how such an attack might be carried out.
curl -d sender="spammer@example.com%0D%0ABcc: victim@example.com" \
-d message="Get a mortgage!" http://www.example.com/contact.php
Now, in addition to being sent to info@example.com, the message will also be
sent to victim@example.com.
The solution to this problem is to either not set extra headers when using
mail(), or to sanitize all data being sent in these headers. A simple example
would be to strip out all whitespace from the sender's address.
