“error”:”unlink(/vagrant/craft/storage/runtime/mutex/*.lock): Text file busy”

Problem: You’re getting a dev environment setup for craft on your system and every update or plug-in install fails with an error message:

Status: Internal Server Error
Response: {"error":"unlink(/vagrant/craft/storage/runtime/mutex/xxxx.lock): Text file busy"}

Solution: You’re on windows. Yii has a different mutex mechanism on windows and by virtue of sharing a folder from a windows host; you’ve inherited some of the idiosyncrasies of the windows file system.

CraftCMS creator discusses this issue in a github issue: https://github.com/craftcms/cms/issues/4355

You’ll need to add this to your craft/config/app.php file.

return [
    'components' => [
        'mutex' => function() {
            $config = craft\helpers\App::mutexConfig();
            $config['isWindows'] = true;
            return Craft::createObject($config);

This was actually an issue in Yii which Craft reported to the Yii framework.

syntax error: unexpected end of file

Problem: You’re trying to run a bash script embedded in a git repository to provision a vagrant machine and are getting an error that no one else is.

Solution: You’re using a windows host. The default on windows is for git to checkout files using Windows friendly line endings and then save them to the repository using unix line endings. Bash on linux is expecting unix line endings and errors if that expectation is not met.

You’ll need to set your settings for this project and re-checkout the files.
Open a command / “git bash” prompt in your project directory and run:

git config core.autocrlf

This should show you your current settings for this feature of git.

The options are true,input or false.

  • true: checkout as windows; check in as unix.
  • input: checkout as whatever is in git and check-in as unix.
  • false: checkout as whatever and check-in as same.

for this repository I changed my settings to

git config core.autocrlf true


git reset --hard

This is does fix the problem but it’s not the best solution for your project.
You should probably have a “.gitattributes” file in your root directory to set this settings explicitly instead of depending on your team to set these up on checkout every time.

*               text=auto
*.sh            text eol=lf
*.conf          text eol=lf
*.bat           text eol=crlf

This will inform git to have different defaults for these specific types in this project. Git is good at detecting binary vs text so you don’t have to go crazy listing every type in your project.

See more about .gitattributes in the book of git.

Follow your curiosity

I was listening to Guy Roz give his farewell address on the TED Radio Hour he mentioned this as one of his most impactful guests and I would have to agree. This is great advice.

… one of the things I’ve been saying a lot to people is that we keep telling people to follow their passion. And I feel like that can be an intimidating and almost cruel thing to say to people at times because first of all, if somebody has one central, powerful, burning passion, they’re probably already following it because that’s sort of the definition of passion – is that you don’t have a choice. If you don’t – which is a lot of people, have one central, burning, passion and somebody tells you to follow your passion, I think you have the right to give them the finger (laughter) because it just makes you feel worse.

And so I always say to people, forget it. Like, if you don’t have an obvious passion, forget about it. Follow your curiosity because passion is sort of a tower of flame that is not always accessible. And curiosity is something that anybody can access any day. Your curiosity may lead you to your passion or may it not. It may have been for, air quotes, nothing, in which case all you’ve done your entire life is spend your existence in pursuit of the things that made you feel curious and inspired and that should be good enough. Like, if you get to do that, that’s a wonderful way to spend your time here.

Warning: RH-Sharpe’s Rootkit

Problem: You ran rkhunter -c on your CentOS powered web server and it found something called “RH-Sharpe’s Rootkit”.

I was cleaning up a minor infection on a WordPress site that wordfence identified. (The irony is not lost on me.) Once I’d verified all the files in wordpress and checked logs to see if the files had been accessed, I also ran clamav and rkhunter just to make sure. rkhunter alerted me to something called “RH-Sharpe’s Rootkit”. 💩 💩 💩

keep calm and check the logs
Always good advice.

rkhunter logs are usually found at “/var/log/rkhunter/rkhunter.log”.
It offers more detail on why a specific alert was generated.

 [08:15:25] Checking for RH-Sharpe's Rootkit…
 [08:15:25]   Checking for file '/bin/lps'                    [ Not found ]
 [08:15:25]   Checking for file '/usr/bin/lpstree'            [ Not found ]
 [08:15:25]   Checking for file '/usr/bin/ltop'               [ Not found ]
 [08:15:25]   Checking for file '/usr/bin/lkillall'           [ Not found ]
 [08:15:25]   Checking for file '/usr/bin/ldu'                [ Not found ]
 [08:15:25]   Checking for file '/usr/bin/lnetstat'           [ Not found ]
 [08:15:25]   Checking for file '/usr/bin/wp'                 [ Found ]
 [08:15:26]   Checking for file '/usr/bin/shad'               [ Not found ]
 [08:15:26]   Checking for file '/usr/bin/vadim'              [ Not found ]
 [08:15:26]   Checking for file '/usr/bin/slice'              [ Not found ]
 [08:15:26]   Checking for file '/usr/bin/cleaner'            [ Not found ]
 [08:15:26]   Checking for file '/usr/include/rpcsvc/du'      [ Not found ]
 [08:15:26] Warning: RH-Sharpe's Rootkit                      [ Warning ]
 [08:15:26]          File '/usr/bin/wp' found

So in this case; it alerted because it found an executable called “wp”. If your a wordpress user; stand down. This is the wordpress command line tool.
It’s a text file. Have a look at it and make sure, but it’s like not something to freak out about.

When I googled for this error; almost nothing came up except for this. Appears “/usr/bin/slice” is also an often found trigger for this warning.

Hopefully this will be useful to the next person who googles for this term mid-panic as I did earlier today.

Please stop the FUD about WordPress.

I came across this posting from a web services company with a brief comparison of different cms options.

Craft — Very secure

WordPress — Can be difficult to secure properly (frequent vulnerabilities due to popularity)

Drupal — Very secure

Clients and co-workers come in with this “wordpress is insecure” opinion largely because of misinformed opinions from “experts”.

Better summaries for their security would be;
Craft – So far; secure with regular updates and careful plug-in selection.
WordPress- Secure with regular updates and careful plug-in selection.
Drupal – Secure with regular updates and careful plug-in selection.

Lets look into that a little bit; shall we.

Craft CMS
They do list all the security best practices they engage in which is great.
The Common Vulnerabilities and Exposures database has 11 reported issues with “Craft CMS” since 2017 with 3 in 2019. It doesn’t look like they engage in any kind of project level security review of this code. While I’d say given that low number of issues it probably deserves being called “secure”; more expert eyes looking in a regular way would be better.
They do benefit from the efforts of the Yii2 project its built on and aren’t likely to experience issues with any of their components. It’s smaller ecosystem than say Symfony but still relevant.

A quick search of the CVE shows that plug-ins and themes are 99% of all the WordPress related vulnerabilities. WordPress core had 11 reported vulnerabilities in 2019. The WordPress core has security team which reviews its code base. It’s active user community reported most of those; not its security team. The push button nature of WordPress updates is its greatest feature. I’d have no trouble trusting a client to apply updates to their site which to me means its likely more secure than other options.

I’d argue that Drupal is less secure than WordPress.
11 vulnerabilities were reported in Drupal in 2019. Plug-ins are also the majority of their issues. Drupal also has a security team which is constantly reviewing its code base and its most popular plug-ins. With version 8; they’ve chosen to use standard components provided from the Symfony project which should eliminate a lot of their potential security issues with core components. Updates are still a pain point; although its much better in version 8. Updates are often more complicated than pushing the “update button” I’d wager that your average client isn’t going to do that very often.

And while we’re on the topic.
The section on “License” is misleading.

Craft is offered under the “Craft” license. It is proprietary open-source software.
You can’t run it without a license and should pixel and tonic go out of business; you won’t be able to run craft.
(Granted; that will likely never happen but it could.)

WordPress and Drupal are licensed under the GPLv2 license. This is free (as in freedom) open-source software which can be used for derivative works.

I likely put more though into this posting than the original author. I understand the demands of making materials accessible to a client but I’m also tired of folks bagging on WordPress. I love php and for better or worse; WordPress is really why we’re still talking about php in 2020.

Stepping down from the soapbox now.