(In reply to masanari iida from comment #0)
> Description of problem:
> configure systemtap-initscript with script name hello-world.stp.
> But if the script file name contain "-", it failed to start.

Hello Masanari,

Thanks for the report. This occurs because of the following in the systemtap initscript:

   eval reqs=\$${s}_REQ

This is done when trying to determine if any script dependencies are specified in the config file (e.g. the variable for the dependencies of myscript would be myscript_REQ).

However, if $s is not a valid Bash variable name, e.g. hello-world, then the eval above becomes:

   reqs=$hello-world_REQ

which evaluates as

   reqs=-world_REQ

since '$hello' is an empty variable. The script then thinks that the 'hello-world' script requires the '-world_REQ' script. It gets worse and worse from there...

Regardless, had it been allowed, the script would not have compiled properly:

Jun 13 12:11:02: Exec: /usr/bin/stap -m hello-world -p4 -r 2.6.32-431.17.1.el6.i686 -w -- /etc/systemtap/script.d/hello-world.stp
ERROR: Safety pattern mismatch for -m parameter ('hello-world' vs. '^[a-z0-9_]+$') rc=1
Jun 13 12:11:02: Failed to compile script(hello-world).
Jun 13 12:11:02: error

In commit 4715f85, I've added checks which ensure that script names are valid so that we fail more gracefully. You would now see something like this in the logs:

Jun 13 12:11:22: hello-world is not a valid script name (must match [a-zA-Z_][a-zA-Z0-9_]*)

I've also updated the systemtap(8) man page in commit fbcde98 to clarify this issue:

       Scripts must be placed  in  the  ${prefix}/etc/systemtap/script.d
       directory  and must have a .stp extension. When referring to them
       on the command-line however, there in no need to include the .stp
       extension.  Script names can only contain alphanumeric characters
       and must not start with a number. The scripts  directory  may  be
       changed by setting the SCRIPT_PATH parameter in the configuration
       file.


Jonathan

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1449.html