Skip to main content

Not handling signals degrades performance

Signals are asynchronous software interrupts that usually happen due to users or utilities sending signals to processes, hardware exceptions within applications, and conditional statements within applications. Most applications do not handle signals because programmers are told "error checking" means checking return values, e.g. does a function return 0 or -1?

When an application doesn't handle signals, it relies on the kernel to do what it thinks is best for an application and the application's data after an error occurs. Sometimes an error is returned to the user, other times the problem is ignored. That's because kernels react to categorized errors, not to specifc errors caused by every imaginable application.   

Some interesting and hard to find performance issues arise when applications do not handle signals, such as an accumulation of lost i-nodes, race conditions between statements, random data corruption and other unexpected behavior. A lot of performance issues are avoidable by assigning default actions to caught signals.

I think the biggest problem with handling signals is portability. The number and type of signals available vary across operating systems. For example, most Linux operating systems do not have a default value assigned to the NULL signal and have between 1 and 31 signals. Whereas, Unix has a default value of 0 assigned to the NULL signal and can have more than 255 signals.

Do you have a suggestion about how to improve this blog? Let's talk about it. Contact me at David.Brenner.Jr@Gmail.com or 720-584-5229.

Comments

Popular posts from this blog

Network traffic monitoring in Linux with Python

You can investigate suspicious activity in your network traffic by collecting relevant machine data from your endpoint. You can use the machine data to create your own analysis. Before you start your investigation you will need to determine normal activity on your endpoint. Normal activity is the scope of functionality of the software on your endpoint during periods of low activity and high activity. You will need some kind of software that periodically collects specific machine data from your endpoint like my software developed in Python that's available for free download at https://github.com/davidbrennerjr/server-stats-collector Ingest one or more of the following machine data: Application specific logs from /var/log Raw dumps from sniffing at Layers 2-3 Raw dumps from /proc of kernel data structures Raw dumps of kernel routing tables General system-wide error messages from /var/log/syslog Do you

OpenStack+Ceph as Software-Defined Storage

SDS reduces the costs of the management of growing data stores by decoupling storage management from its hardware to allow for centralized management of cheaper, popular commodity hardware. The example SDS ecosystem uses open source software like OpenStack as a front-end interface on top of Ceph as the resource provider of a RADOS cluster of commodity solid-state drives. OpenStack provides user-friendly wrappers for accessing and modifying underlying Ceph storage. OpenStack comes in the form of distributed microservices with RESTful API's: Block (Cinder), File (Manila), Image (Glance), and Object (Swift). Each microservice can scale-out as a cluster of stand-alone services to accommodate the varying demands of high-growth storage. With OpenStack the underlying Ceph storage can address the block storage needs, file storage needs, image storage needs, and object storage needs of datacenters adopting open source as their new norm in an industry trend for high performace and high a

What are attack vectors?

In the generalized sense an attack vector is a path or means by which a hacker can gain unauthorized access to an endpoint in order to deliver a payload or to facilitate a crime. Attack vectors enable hackers to exploit vulnerabilities in the design of a network through the manipulation of applications and protocols. Attack vectors typically manipulate the software installed in the operating system of an endpoint. Examples of attack vectors are email attachments, pop-up windows, instant messages, service configurations, new software, and firewall modifications. Human ignorance or weaknesses could also be used for engineering attack vectors. For example, users could be fooled into weakening network defenses during times of remote collaboration and file sharing. Anti-virus software and firewalls do provide some defense or block attack vectors to some extent. Some of the mitigation measures used to thwart hackers usage of attack vectors include deep packet inspection, IP source trackers