If you have a Magento site that is consistently erroring out and giving you the report screen with the file name, but the file does not exist in the reports folder then this could be your solution.
The most likely culprit in this scenario is that the filesystem has run out of space. If this happens, Magento will die because it literally can’t create any files and it needs to do this for caching, session etc.
You can easily check this by running this command:
df -h
If you see any filesystems with 100% usage then you have your answer, you have run out of hard drive space and need to free some space up by deleting files.
On occasion though you might run this and see that you still have plenty of space. This can be puzzling at first though you need to bear in mind that Linux filesystems don’t purely use space but also something called inodes.
An inode is like a file pointer, you need one for every file that is in the filesystem. Also there is a limit to the number of inodes in any file system. If something goes crazy and your system creates lots of small files then you might find that you run out of inodes before you run out of hard drive space.
To check if this is your issue run this command:
df -i
If you see any lines with 100% then you have run out of inodes and you need to delete some files. There are numerous possible causes of this and tactics that can be used to clear them out. When dealing with Magento though there are a few usual suspects.
Magento is a real culprit for this behaviour as it uses file system based sessions by default. Session files are very small and can be very numerous.
The quick fix is just to completely remove the sessions directory:
rm -rf /path/to/magento/var/session
Magento will recreate it on the next request.
If you would like to try to clear out just older sessions then you can do something like this:
find /path/to/magento/var/session -name 'sess_*' -type f -mtime +7 -exec rm {} \;
Grass Seed Store – Migration from OSCommerce with Custom Functionality
The Grass Seeds Store wants to migrate away from OSCommerce to Magento in order to improve stock management. They also need to maintain DEFRA compliance and have custom reports generated to do so. The custom reporting was based on the sales of seeds.
The Grass Seed Store
The Grass Seed Store specialises in the sale of a many different types of grass seed, fertiliser and live stock pasture.
This project is a great example of customising Magento to be compliant with an industry governing body and shows that Magento can be used in almost any for the sale of any type of product. The project is currently a work in progress and the Magento implementation is currently only a wire frame demonstrating the functionality that is ultimately required.
If you are looking for a light weight, fast, PHP based yet fully featured issue tracking system, Elastik is a great choice. Here is a quick start guide for it’s usage.
The Problem
When working on any type of development project be it a design, programming even construction problems within the project will almost certainly arise. Keeping track of the problems that people have brought to attention can be hard to do effectively. Issues might be raised by email, IM or in person. Keeping track of the issues that have been raised can be a real problem if you don’t keep on top of it. Even on a single person project, it’s so easy to forget that some one pointed out a small problem. Using email and noting systems to track what issues have been raised can work for a small project but will quickly become difficult to work with one there is more than a single person on the project, such system of working will also fall apart if the number of current issues becomes large. Using a system designed to rectify the issue really is a boon. It not only allows each issue and it’s status to be tracked, but also standardises the method of communication so that every one knows where to look to see what is happening with an issue. Ultimately, the best benefit of using a tracking system is not losing/forgetting about any issues that have be raised.
Elastik’s intended use is for multi-client multi-project purposes. That is to say Elastik can have many clients using it, each client having multiple projects.
Creating Account and Account Permissons
Account creation of elastic is done via email on a invitation only basis. Only System, Project or Client Administrators can invite additional users. Elastik has quite granular user permissions. To start with there are three types of users Administrator, Client users/administrators and Project users/administrators. In terms of access levels Project users/administrator are the ‘lowest’ permission’ed user as they only have access to a single project. Client users/administrators have access to all the projects that a client has and system administrators have global access. On top of these levels of access, Client users can also be administrators of the client and the same applies to project users. Elastik also has granular per-project and per-client permissions settings available. In summary, if you want to tightly control access to the tracking system, you can do it in great detail.
Setting up a client project
Elastik uses the concept that each project belongs to a client. Even if you are making an application for your self, there is still a client involved (you!). So before you can create a project you need to create a client. This is a way of grouping projects together as well as defining a client owner. When creating a client you are required to supply an email address. The person who owns this address will be given client level access and will have client access permissions, and there for access to all project that belong to that client. Client administrators can change settings related to the client and all the projects that belong to that client. If you do not wish to setup any client level access you can enter a existing system administrator’s email address and then add a new user to the client/project later. All this also applies when creating a new project.
Managing Issues
Tickets is what issue tracking is all about. Ultimately working with tickets can be as straight forward as you like or as complex. Using the default ticket categories and schema will be enough for most situations and will even be workable even if they are not. However, Elastik allows you to create much more complex ticket structure which should make it flexible enough for use with any project.
Customising Tickets
The default ticket structure is that a ticket can either be a new feature request or a problem within already existing functionality. You can either expand or shrink this as necessary on a per client or project basis.
The default ticket schema is that a ticket can either be “Open” or “Closed”. You can customise this to have as many different ticket status as you like. Elastik also has the idea that it should be logically impossible to go one ticket status to a particular other one. For example, it would not logically make sense for a ticket to be able to transition from “Closed” to “New Ticket” as the ticket already exists so it is not a new ticket at all. In this example you would probably want to change to “Re-opened ticket”. Elastik allows you to specify that “New Ticket” is the default status of a new ticket and that it impossible for a ticket’s status to be “New Ticket” after is has already been changed, transitions can be defined to be quite complex.
Extensions
Elastik has a modular design and comes pre-packaged with a number of modules all of which are disabled by default, presumably because some people may simply not want them. Below are two that web developers who often spend allot of time communicating with clients may find particularly useful.
E-Mail Summaries
By default Elastik only uses email for setting up accounts and nothing else. The email summaries module will send emails to individuals periodically informing them of changes made on a project or client. This does require a cron/scheduled task be setup on a computer to function however. This is particularly useful to keep clients up to date with changes to issues and also keep you up to date on issues the client is raising.
One minor draw back is that by default it will only email changes to tickets to people who are watching the ticket. However, you can enable it to send every one on a project all updates whether they are watching it or not in the projects configuration.
File Attachments
The file attachments extensions allows files to be uploaded to the hosting server and attached (associated) with a ticket. Files are attached after ticket creation which does reduce the steamlined-iness of the process, but you can attach more than one file to a ticket.
The one thing to watch out for when using this extension is that it defaults to not allowing any uploads and you have to explicitly define what file extension types can be uploaded on a per-client or per-project basis. You will most likely want to enable all image formats so client can upload screen shots of the issue.
Summary
If you are having any amount of trouble communicating and keeping track of issues for any type of project, using Elastik is definitely a good way to solve this.
Elastik is fast, customisable, flexible, functionally complete despite been at version 0.4.1. No major draw backs despite been incomplete. Personally I would like to see it keep the light weight approach so that it doesn’t matter how old/rubbish a clients computer might be and they are using IE6 it will still be fast. It will also mean that if your server is over loaded, it will still run fast. Of course, if it doesn’t do what you want out of the box, it is PHP based and open source, you can either write a new module for it or fork it and start hacking at the code.
After the recent Sage Pay troubles, they offered a technical report which if requested they will send to you.
Not sure why they created this extra step to get to this information so I thought I would post it here for general consumption:
Sage Pay Technical Report — 3 & 4 March 2011
At 01:05 Thursday 3 March 2011 our system monitoring functionality alerted us to a potential issue with the Sage Pay Live gateway.
Our Incident Management team immediately initiated our incident management processes updating the monitor page, activating engineers to further investigate the situation and engaging with senior members of the business.
It was initially unclear as to the extent of the issue — Live transactions were not being processed at this time, but My Sage Pay was available. In total during this time the Live gateway was unavailable for approximately 1 hour 45 minutes.
Remedial work to re-enable our transaction processing was completed at 04:25am. The nature of this work meant that transactions were not archiving to our warehouse and reporting databases.
By 07:30am all transactions were able to be processed (including refunds, repeats etc), however at this point they were not appearing in My Sage Pay.
We remained in this state until 11:45am. In order to try and resolve the issues with My Sage Pay, our warehouse and reporting database processes required restarting; this was performed at 11:45 but had a direct impact on our front-end web servers, resulting in a 50% reduction in transaction processing between 11:45 and 11:50.
Live transaction processing on the gateway continued at a degraded level throughout the afternoon despite our efforts to resolve the issues fully. Between 13:56 – 14:10 the live gateway was unavailable.
At 19:20 normal volumes of transactions through the Live gateway were resumed following the resolution of issues with the warehouse databases. The gateway has since maintained full service with no further service degradation.
My Sage Pay issues continued into Thursday evening and during the day on Friday. We were unable to display real-time transactions, as the reporting databases were not being populated. We took the decision to re-index the reporting database, which began at 23:59 on Thursday in order to ensure improved performance when My Sage Pay was brought back online. Due to the issue on 3 March, this work took three times longer than expected and caused My Sage Pay to remain unavailable until 16:35 on Friday 4 March.
During Saturday 5 March and Sunday 6 March further work took place to populate fraud results, correct settlement discrepancies and complete the migration of the remaining transactions.
All work was complete and My Sage Pay was fully up-to-date by midday on Monday 7 March.
