Movable type not working

apps

#1

My [previously] stable Movable Type weblog suddenly stopped working. When trying to post or rebuild, I get this message:

Can’t locate object method “splitpath” via package “File::Spec” at lib/MT.pm line 347.

I can only think that Dreamhost did something to cause this, as nothing in my MT install has changed in the last two days. Are they changing the Perl modules? Dealing with a server crash?

Emails to support have been unanswered so far, even though this problem is hours old by now. Very frustrating.


#2

While it’s not the best solution File::Spec is one of the library files you can install in exlib… that should at least get you running again.


#3

Thanks. I think you’re right, and the information on the MT forum that I’ve just read concurs.

But I guess the larger question is: Why doesn’t Dreamhost bother to let its customers know before they make changes to the Perl modules? Isn’t that what the announcements section of the Dreamhost panel is supposed to be for? It’s extremely frustrating to suddenly find that my weblog isn’t working, and that I’m on my own to diagnose & resolve the problem.


#4

I guess you got it working?

As for why it stopped, I’m afraid I don’t know! We wouldn’t change anything with our perl situation without announcing it, and all we ever do is add MORE modules and upgrade versions, never take any away. It looks like your server hasn’t been upgraded to woody yet so that wouldn’t have been it either. Again, I’m really sorry about that, and I’m a bit puzzled why it happened in the first place. Our apologies!

josh!


#5

Well, I did get it working, following the instructions in the Movable Type forums. In fact, if you go over to the forum (this thread: http://www.movabletype.org/cgi-bin/ikonboard/ikonboard.cgi?s=3dfbaf5c4535ffff;act=ST;f=10;t=11670;hl=dreamhost), you’ll see that a whole bunch of people (only MT/DH users!) were affected.

With all due respect, it HAD to be something that Dreamhost changed, as none of us have made any changes in our MT installations, and all of our MT systems stopped working at the same day and time. And Dreamhost tech support has certainly known about this problem since yesterday; you can verify this by reading through the MT forum thread.


#6

We are having the same problem on all of the instances of Movable Type we have running and I guess I will follow the instructions from the MT board as well but it really does seem odd that that module would just stop working for a bunch of people out of the blue.

It would be cool if DH could do a quick check into this. While it clearly isn’t in DH’s mandate to support MT or other 3rd party stuff, the reliability of Perl modules and the like is.

{FLUFFCO.COM}


#7

Hi Bucky, everyone -

It sounds like the problem is that at some point a recent version of that module was installed on some servers at the request of some Movable Type users.

The standardized Debian packages we install actually include a somewhat older version, and when we did some upgrades that version overwrote the newer version, causing MT to fail on those servers. Apparently some of our techs have been telling people to install File::Spec locally under their accounts, but not all of them know about this. When the file was overwritten, this is why some peoples’ installations worked and others broke.

Unfortunately, we’re somewhat at the mercy of the packages we can install, for manageability purposes. We never did ‘officially’ support the newer module version, only installed it in some cases when specifically requested. In hindsight we probably shouldn’t have done that, instead waiting for a newer ‘official’ package or created our own.

Even if it’s working now, all MT users should install a local copy of File::Spec so that they won’t have this problem in the future (at some point, I’m sure we’ll ‘officially’ support the newer one as well). I believe there are instructions for this on the official MT web site. We’ve also written a little KBase article on this:

https://panel.dreamhost.com/kbase/index.cgi?area=2770

Sorry for the breakage, everyone!

  • Jeff @ DreamHost
  • DH Discussion Forum Admin

#8

Jeff,

Is this still the case as of 1/8/03? I can grab that file and make the mt.cfg changes, but I didn’t want to do it if I didn’t have to. :slight_smile:

Marc


#9

Got a new problem today: Saving object failed: Opening linked file ‘/home/.delmanblender/cwodtke/eleganthack/gridex_template.html’ failed: No such file or directory

having changed nothing in any of my installs or folders. I’m really getting sick of things magically breaking. isn’t there some way to be on a server that doesnt’ get upgraded and breaks everything? or at least get some warning??? My sister has the berekley database version, I’ve got MySQL. he’s broke three days ago (no errors) my broke yesterday with errors-- and she’s got errors now too.


#10

Try changing the path so it doesn’t include the /.clustername part ie:

/home/username/domain.com/

rather than:

/home/.something/username/domain.com/


#11

if crys is correct, they why were we not informed of the changes? I know that Movable Type isn’t the only script that depends on this information.


#12

changed all my paths to relative paths and it fixed the problem with my error. My sister still can’t post-- somethign wrong with berekley db???.

i would like to know when dreahost changes something, to watch for these problems…


#13

Actually:

https://panel.dreamhost.com/kbase/index.cgi?area=153

tells you to use /home/username/ as the root directory of your account unless that doesn’t work – which I haven’t run into, even in php as it mentions.


#14

You should always use /home/username - /home/.foo/username is subject to change. Unfortunately, bash seems to default to /bin/pwd instead of the builtin pwd (which doesn’t follow the symlinks, and will return ‘/home/username’).

You can try putting:
enable pwd

in your .bash_profile and .bashrc (if you’re using bash), and see if that changes the output of pwd. However, software you install may still get the full path. If there were an easy workaround to this, we’d certainly be all over it.


#15

No, we weren’t informed of this change, and you know why? Because Dreamhost set the level of importance of the announcement at 1 – their “fun” category. When I responded to their support email (which, by the way, took over 36 HOURS to wait for…and even then failed to identify the problem correctly!), I told THEM what the problem was and suggested that this kind of announcement should really warrant a higher ranking of importance.

Their reply to me? That I should set my announcement levels lower. Apparently, they still consider this type of change to be “fun”, on the the level of DHSOTM – in other words, the functionability of our web sites is not of great importance.

I hate to be this angry after having been with DH for over three years, but this kind of thing is getting ridiculous. :frowning:


#16

The issue is that if we put too many announcements at a higher priority level (granted I probably would have put this at ‘3’), a lot of people simply won’t pay attention to the announcements at all. The number of people using any particular third party application is pretty small compared to our overall customer base.

I am hoping we can setup a couple of other “specialty” announcement groups that people can subscribe to (like “console apps”, “UNIX stuff”, “CGI and PHP scripts”, etc.) so that we can keep customers better informed without bombarding people with announcements.


#17

I appreciate your reply, Will, and I’m sorry for sounding so crabby earlier. What can I say, I was feeling crabby.

Level 3 I could understand. Sure. But Level 1? Considering the number of users that must have been affected by this, that seems absurd.

What really irks me, though, is that apparently the person who replied to my support request (36 hours later…but that’s another issue) was apparently not even aware of that announcement (or the configuration change) having been made! They told me my board was working fine (well yes, that’s because I had figured out the problem myself 12 hours earlier) and that it was probably a temporary server problem.

In other words, apparently Level 1 is not enought to even warrant DH’s own employees reading an announcement. :confused:

Anyway, enough. I went for over three years with DH as a very happy customer, so I’m hoping that the last few months will soon pale in comparison to the good service I’ve gotten in the past.


#18

We all get all of the announcements (twice)… so if anyone didn’t read it, they weren’t paying attention.


#19

I’m one of those who didn’t read the notice until after my scripts stopepd working. After going through my mail I saw an email that stated specifically that this might create problems with MT. That’s how I knew to fix mine.