space shuttle troubles…

Space Shuttle Strut Repair
Yesterday, some info leaked that the shuttle … well, leaked ;) To be serious, there were reports that there is an unacceptable leak at a shuttle strut – hydraulics fluid seems to have been leaking. But yesterday the decision was made that a repair is actually needed.

Of course, it didn’t take long for all sorts of rumors to appear. Some sources even said that the October mission would be canceled and moved to January – which is as far from being true as it only can be. In fact, the NASA source quoted above does not outrule there is a change in the launch date, but it is expected to be not a major hit. As far as I understand it, things may be moved a few days at most. There seem to be buffers all along the process, so I do not yet begin to panic ;)

… but I have to admit that this triggers bad memories. As I said, I flew in into Orlando last year to see the STS-115 launch (which I finally didn’t make due to its long delay). With STS-115, all the trouble also started with launch delays, that time caused by a lightning strike. That, too, was quite some time before launch, at least if I correctly remember. It was not that early as the current problem, which leaves me with the firm hope that there is enough buffer time available even to launch on the target date of October, 23rd. Let’s see…

Photo: In the Orbiter Processing Facility at NASA’s Kennedy Space Center, workers secure the tool storage assembly unit into Discovery’s payload bay. Photo credit: NASA/Amanda Diller

paid services for rsyslog

As with a lot of open source projects, rsyslog funding is problematic. Of course, rsyslog currently is funded by my interest in it. And I am glad that Adiscon, my company, permits me to work on. The actual funding for all that action, kind of funny, mostly stems from closed source projects in the Windows world.

However, I’d like to see that over the years rsyslog can fund itself. In my point of view, funding should be provided by those that benefit most from it. So obviously, I do not expect any funding from private folks, people like you and me. Of course, everyone is invented to contribute and new code, doc and bug hunting is definitely a pro. On the other hand, companies (and other organizations, namely the government) take financial advantage of using it. Some of them also contribute in terms of time and code. This is great and much appreciated :)

For the others, I have begun to offer donations. Not surprisingly, this is not a real source of funding ;) But now I have taken an offer from sourceforge.net, which I think is interesting. They begin to offer a marketplace for open source services. So those folks that actually need help can be brought in contact with those that have experience. Sounds like a good idea to me and a fair way to fund projects.

I have created two test service offerings for rsyslog. One is to write a nice custom-created rsyslog configuration file. Well, with rsyslog’s relative ease of use, I do not expect that many folks use that. But you never know and I am always curios.

The other one is especially targeted towards organizations who must prove they have “official” support for all software they use (I guess this includes at least a number of government agencies). For them, I have created a email support option for rsyslog. It guarantees responses to support questions and this is often needed for auditing and other purposes. Of course, we still answer all support emails and do not plan to stop that.

I have added one real goody, though: and that is that we will provide patches for past releases of rsyslog. As you may know, developers hate to fumble with old releases. And so there is very little motivation to look at an older release when there is a new one out. With the paid support option, however, there is some motivation to do that. So, again, I think this is fair: we are just offering a service that would otherwise never appear. It doesn’t hurt any of the other users.

I am very interested to see how this works out. I would also be interested in feedback from the field. How do you like this idea? Do you have any other/additional suggestions?

space shuttle troubles…

Space Shuttle Strut Repair
Yesterday, some info leaked that the shuttle … well, leaked ;) To be serious, there were reports that there is an unacceptable leak at a shuttle strut – hydraulics fluid seems to have been leaking. But yesterday the decision was made that a repair is actually needed.

Of course, it didn’t take long for all sorts of rumors to appear. Some sources even said that the October mission would be canceled and moved to January – which is as far from being true as it only can be. In fact, the NASA source quoted above does not outrule there is a change in the launch date, but it is expected to be not a major hit. As far as I understand it, things may be moved a few days at most. There seem to be buffers all along the process, so I do not yet begin to panic ;)

… but I have to admit that this triggers bad memories. As I said, I flew in into Orlando last year to see the STS-115 launch (which I finally didn’t make due to its long delay). With STS-115, all the trouble also started with launch delays, that time caused by a lightning strike. That, too, was quite some time before launch, at least if I correctly remember. It was not that early as the current problem, which leaves me with the firm hope that there is enough buffer time available even to launch on the target date of October, 23rd. Let’s see…

Photo: In the Orbiter Processing Facility at NASA’s Kennedy Space Center, workers secure the tool storage assembly unit into Discovery’s payload bay. Photo credit: NASA/Amanda Diller

viewing a space shuttle launch…

Space Shuttle Launch
As some of you know, I am addicted to astronomy and space travel. Since long, I’d wanted to experience a space shuttle launch. Last summer, I got tickets for the STS-115 mission. I went down to Florida, went through a hurricane and … had to leave without the shuttle being launched. Well, actually I could view it rocketing into space from far away (Fort Myers) when I had to leave home. That was really bad luck.

Unfortunately, I either could not go for the next missions or I didn’t manage to get tickets (they sell out soooooo quickly that it is a real problem even if you type fast ;)).

Now, I was lucky enough to secure tickets and also manged to get enough vacancy to do a re-try. I am going to visit the STS-120 mission now. We’ll fly in to Orlando and then move over to the Titusville/Cocoa Beach area. Getting it all together was far from being simple.

After I got the launch tickets, I needed to get flights and then find hotels. This list is sorted in descending order or rareness ;) While I had only a 3-minute shot at obtaining the tickets, the flights were quite complicated too. Hotels were available, but of course not those I hoped to find. Based on experience from fellow travelers, Titusville seems to have only one decent hotel. I can back this, as I found none on my previous trips. The one in question is the Hampton. Everybody seems to know, and I didn’t get a room for the 22nd ;) But everybody also seems to expect the shuttle to take off on first launch attempt – because starting from the 23rd there were vacancies. I secured some of them ;)

I hope to have a really great launch experience. I hope I’ll find time to post more of my experiences on the way to the launch here in the blog. I’ll probably even start a STS-120 section on my site www.gerhards.net – let’s see :)

viewing a space shuttle launch..

Space Shuttle Launch
As some of you know, I am addicted to astronomy and space travel. Since long, I’d wanted to experience a space shuttle launch. Last summer, I got tickets for the STS-115 mission. I went down to Florida, went through a hurricane and … had to leave without the shuttle being launched. Well, actually I could view it rocketing into space from far away (Fort Myers) when I had to leave home. That was really bad luck.

Unfortunately, I either could not go for the next missions or I didn’t manage to get tickets (they sell out soooooo quickly that it is a real problem even if you type fast ;)).

Now, I was lucky enough to secure tickets and also manged to get enough vacancy to do a re-try. I am going to visit the STS-120 mission now. We’ll fly in to Orlando and then move over to the Titusville/Cocoa Beach area. Getting it all together was far from being simple.

After I got the launch tickets, I needed to get flights and then find hotels. This list is sorted in descending order or rareness ;) While I had only a 3-minute shot at obtaining the tickets, the flights were quite complicated too. Hotels were available, but of course not those I hoped to find. Based on experience from fellow travelers, Titusville seems to have only one decent hotel. I can back this, as I found none on my previous trips. The one in question is the Hampton. Everybody seems to know, and I didn’t get a room for the 22nd ;) But everybody also seems to expect the shuttle to take off on first launch attempt – because starting from the 23rd there were vacancies. I secured some of them ;)

I hope to have a really great launch experience. I hope I’ll find time to post more of my experiences on the way to the launch here in the blog. I’ll probably even start a STS-120 section on my site www.gerhards.net – let’s see :)

Space Blog mission Statement ;)

As time progresses, things change. This is also true for blogs. When I started this blog, it was all about my STS-120 launch viewing trip. But then I discovered the beauty of blogging and converted it more and more in a general space related blog.

This is where we are right now: This blog is about space and space flight in general. For obvious reasons, it covers space shuttle launch and operations, but I also keep a keen eye on the Constellation program with the Ares launches and Orion crew exploration vehicle. And, of course, the international space station ISS and its helpers (including the European ATV) are also on-topic.

I try to convey news but with my personal point of view. Feedback is highly appreciated and reader stories are posted when I receive them (of course, assuming that they are on-topic).

I hope you have fun reading this blog. Feedback is always welcome.

For completeness, here are previous mission statements:

Up until mid-November 2007:

This is my blog about viewing Space Shuttle launches. I have tried once in Summer 2006 (with no success) and will retry in October of 2007 for the STS-120 mission. I blog about my travel preparations, things that come to my mind and the overall experience. [read more about what’s in this blog]

This blog is about viewing space shuttle launches. To be even more precise, it is about me trying to view a shuttle launch. I hope it will be interesting to you to hear about my fate when trying to actually see it.

I have already tried once, in summer 2006. That time, it was the STS-115 mission, which were endlessly delayed due to a number of issues. But that’s another topic. If I find time, I’ll try to dig out my past travel logs and convert them to blog posts. Will see ;)

But, hey, why read this blog? First of all, you will probably have a good laugh at what I am trying when it gets problematic [and I bet it will] ;) Other than that, you may possibly want to go yourself one day. In that case, you can probably learn a bit out of my experiences(and, yes, I plan to write about the cool things, too ;)). Some may even claim that they somehow feel closer to the launch experience if the read the notes of someone who does.

And, remember: the last shuttle is set to rocket off Kennedy Space Center in 2010 – so if you want to experience a launch, there is not much time left! Better you be prepared.

So – have fun and keep reading. I will possible save this post as a reference and update it from time to time.

recent rsyslog changes

Again, I am doing small changes, mostly review, at this time. So I have batched up some things. Probably I’ll switch back to a more daily mode, as it allows to keep better in touch. We’ll see (comments appreciated).

Here comes the log:

2007-09-10
– bumped version number to 1.19.6
– fixed a bug that in –enable-debug mode caused an assertion when the
discard action was used
2007-09-07
– added eCmdHdlrGetWord command handler
– added $ModDir config directive
– modified $ModLoad so that an absolute path may be specified as
module name (e.g. /rsyslog/ommysql.so)
– applied patch by varmojfekoj two fix two potential segfault situations
– cleaned up some signed/unsinged char issues
– released 1.19.5
2007-09-10
– bumped version number to 1.19.6
– fixed a bug that in –enable-debug mode caused an assertion when the
discard action was used
2007-09-11
– applied patch by varmojfekoj to change signal handling to the new
sigaction API set (replacing the depreciated signal() calls and its
friends.
– did a full review of all remaining TODO items in code – nothing of
importance found (but some minor nits like comments fixed)
– cleaned up compiler warnings
– applied patch by varmojfekoj to FIX a bug that could cause
segfaults if empty properties were processed using modifying
options (e.g. space-cc, drop-cc)
– fixed man bug: rsyslogd supports -l option
– checked -s/-l option and found that they work as expected – closed case
– added some comments in relation to -s/-l option
– released 1.19.6
– removed compiler warnings in non-debug mode
– fixed a bug that caused the CStr class to not honor the parameter to
return NULL on empty string – causes a mem leak and can create favourable
environment for other bugs (as it leads to empty hostnames)
– pulled 1.19.6 (no downloads so far), created new 1.19.6 with the bugfix,
re-released that (now tagged v1-19-6b in cvs)

bug hunting…

We have received feedback that the 1.19.x releases of rsyslog contain a bug that leads to a segfault after some time. Of course, this is a very bad thing to happen. After all, the primary goal for the rsyslog project is reliability and it should be able to survive even in the worst conditions (e.g. low system memory). So this bug is clearly unacceptable and has received highest priority.

Unfortunately, it is hiding very well. We are all looking into troubleshooting this beast. Thankfully, there is a lot of community support, especially with testing. What makes this bug so hard to find is, among others, the inability to reproduce it in lab. So the project is totally dependent on user feedback. As current reports have shown, we also currently assume that releases prior to 1.19.0 can also be affected – so it is not as easy as checking the changes.

I receive very valuable help by varmojfekoj. He is already a frequent and great contributor of patches. His skills and experience are extremely valuable and I am very glad to have him work on this project. Please give him a big hand. Thanks, varmojfekoj, the project would not be that far without your help!

While the bug itself is obviously a very bad thing, it has some good side-effects. Most importantly, the code is getting another round of very in-depth review. That review has already brought up some fixes for obscure situations. Situations that I’d expect to happen extremely infrequently (if at all) in reality. But now even those are fixed. And I am sure that the review will bring even more benefit as it continues. Of course, I’d be glad if we find the bug ASAP, but it is good to know that all that work also provides additional benefit (at least that keeps my depression level low ;)).

The bad thing, besides the bug itself, is that the bug hunt obviously defers other work. Most importantly, I refrain from making any changes that may not be related to clean up or bug fixing. I think it is not smart to introduce new code (read: complexity) at this stage of the project. And, of course, all resources should focus on fixing that bug, so there wouldn’t even be time to enhance other parts of the code. So for all of you waiting for new features: please bear with us, the implementation schedule will slip a little bit.

If you experience stability problems, please report. Each reports helps us understand the problem somewhat better.

recent rsyslog changes

Now that I am back working on the rsyslog code, I will continue to provide information about what I am doing. In most cases, however, I will not provide daily logs. The reason is that I currently focus on new design and will leave rsyslog code mature. So changes will be relatively infrequent (at least I plan so ;]).

Here is the work log for the past days:

2007-09-04
– integrated patches from Michel Samia and varmojfekoj
– released 1.19.4
– changed some calls to CStr class to their “safe” counterpart – they could
cause program aborts if the object in question was an empty string
2007-09-05
– added some links to doc
– removed an invalid config sample from sample.conf
– changed part of the CStr interface so that better error tracking
is provided and the calling sequence is more intuitive (there were
invalid calls based on a too-weired interface)
– (hopefully) fixed some remaining bugs rooted in wrong use of
the CStr class. These could lead to program abort.
2007-09-06
– added forwarding information to sysklogd (requires special template)
to config doc

rsyslog config again…

I am writing a lot about rsyslog config file formats these days. Now I think I come closer to a result. The past days, I have thought a lot about potential formats. Now, I have created configuration samples in the rsyslog wiki. Also, some others have posted hints.

I now have two favorites: one is a XML-based format. Its advantage is that it would be easy to use when (if) we implement NETCONF protocol. If I assume NETCONF will actually become *the* configuration standard, this is a big pro argument for that format. However, I consider the format to be exceptionally bulky and pretty less intuitive. In other words, I do not really like it – but that doesn’t mean it is a bad choice.

What I like more is a programming-language like format (and especially the last sample in the wiki article). It looks somewhat more “natural” to me, but this may be because I like programming languages ;) In any case, I think it is easier to grasp and modify, but of course it is not standardized. Plus, there are three different samples, each in a different style and level of verbosity.

The question is now what users consider to be best. I sincerely hope to receive feedback, as I probably have only one “shot” at this for the foreseeable future (well… I have to admit that I thought about dynamically loadable config file parsers, but that adds probably too much complexity).

So if you have anything to say, please speak up now!
If you do not know where to make yourself heard, simply post to the rsyslog forum thread on the config file format.