Are you sure you need the -l option to su?  I do the same thing in my
startup scripts on my home machine, which, admittedly, is an old version o
NetBSD, but I don't use the -l option I just say:
su local -c <command follows>
or 
su brook -c <command follows>

I also do this on a SunOS based machine here at work and, again it doesn't
use the -l option.  
-Brian
On Oct 10,  3:01pm, Brook Milligan wrote:
} Subject: segmentation faults and su
} I am trying to use su to execute a command as another user during
} boot-up (it doesn't matter, but in this case I want to start the
} postgreSQL postmaster as user postgres).
} 
} The best solution is to put a command into /etc/rc.local like the
} following:
} 
}     su -l postgres -c 'run_postmaster_command'
} 
} This uniformly yields a segmentation fault.
} 
} I have traced the problem to the su command in the sense that it
} doesn't matter what login I su to or what command is executed by su
} (e.g., running pwd does the same thing), there is always a
} segmentation fault.  This still occurs under a wide variety of
} conditions: 1) if the command is run from /etc/rc.local, or 2) if the
} su command is within a script run via at.  However, running the same
} su command (or a script containing the same one) from a terminal after
} logging in works fine.
} 
} For example, the following script works fine if run from a terminal:
} 
}      #!/bin/sh
} 
}      echo "testing su"
}      pwd
}      su -l postgres -c 'pwd'
}      su -l brook -c 'pwd'
}      pwd
} 
} But it yields the following if run via at:
} 
}      testing su
}      /usr/local/pgsql/bin
}      Segmentation fault
}      Segmentation fault
}      /usr/local/pgsql/bin
} 
} What is going on here?  How can I fix it to allow su from within
} scripts run, say, from /etc/rc.local?
} 
} Cheers,
} Brook
>-- End of excerpt from Brook Milligan