Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#1698 closed Bug (fixed) compatible with Freebsd (using /bin/sh instead of /bin/bash)

Reported by: tgrondin Owned by:
Priority: critical Milestone: Piwik 1.1
Component: Core Keywords: freebsd
Cc: Sensitive: no


The script is either broken or simply incompatible with Freebsd servers.

Attempting to run it as the root user as 'sh' leads to:

Starting Piwik reports archiving...

Reports archiving finished.
Starting Scheduled tasks...

Error: You can't access this resource as it requires a 'superuser' access.Finished Scheduled tasks.

Running it via cron according to the directions listed at the setup-auto-archiving/ page leads to the following.

/usr/local/www/piwik/misc/cron/ not found

That happens because bash is not installed by default on Freebsd servers. Further more the script references a non standard location of bash if it is installed. It should reference /usr/local/bin/bash. Installing and fixing the bash path and running it via cron leads to the following error:

shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied

I figured I'd try here first in the hope that I'm making a mistake or missing something before I start tearing it apart in a attempt to make it work.

There is also a forum reference to the issue. I'll link to it once the forum's are back on line. They appear to be down right now.

Change History (9)

comment:1 Changed 4 years ago by vipsoft (robocoder)

  • Milestone set to 1.1 - Piwik 1.1
  • Resolution set to invalid
  • Status changed from new to closed

Using #!/bin/bash in the script is a best guess. Loading up the shell depends on the scripting environment -- it happens before script execution, so there's nothing we can do. You can use:

/usr/local/bin/bash /path/to/script

The shell-init error means the cron job is running as a user who doesn't have read access to the shell script.

comment:2 Changed 3 years ago by hansfn

Hi, sorry for re-opening this issue, but since the fix is so easy I hope that you can reconsider and make use /bin/sh in stead of /bin/bash.

The point is that doesn't use any bash specific features, and requiring people to install bash when sh will do is kind of, well, unnecessary.

Thx for listening. Now I'll go and update the Norwegian Bokmål translation ;-)

comment:3 Changed 3 years ago by hansfn

PS! I wasn't allowed to reopen it (no permission to change fields), so I had to leave it closed. Hopefully you'll notice it anyway.

comment:4 Changed 3 years ago by matt (mattab)

  • Resolution invalid deleted
  • Status changed from closed to reopened

if we change to bin/sh maybe it will break for some existing users?

comment:5 Changed 3 years ago by hansfn

No, it won't break. /bin/sh is actually a standard (POSIX) for all Unix/Linux OS-es - quote from

"POSIX requires that /bin/sh is a shell capable of a syntax similar to the Bourne shell."

I would have pointed to the actual POSIX standard itself, but it's behind a pay wall.

comment:6 Changed 3 years ago by matt (mattab)

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [3639]) Fixes #1698 - I assume the -e parameter is still valid?

comment:7 Changed 3 years ago by hansfn

Yes, the -e parameter means the same for sh and bash. (And to be sure I have tested ;-)


comment:8 Changed 3 years ago by matt (mattab)

  • Summary changed from broken to compatible with Freebsd (using /bin/sh instead of /bin/bash)

comment:9 Changed 3 years ago by tthuermer

note on this:
the issue is not only in referencing sh or bash, but more importantly to avoid using special bash features that will not work in sh

Note: See TracTickets for help on using tickets.