Used to work - now broken (new os)

johanafm

I completely fail at google. When I even know what to google for. But after a change of OS (Redhat Enterprise -> ubuntu), there are php scripts that no longer work. PHP version has remained the same (5.5.3). Precious few lines differed in parsed ini files between the old and new systems and can be ruled out.

I ssh to the server and get bash, but when I
```
sudo su - USER
```
I get dash. I've no idea what differs (except for the annoying missing features I notice). Thus I have no idea what differences could potentially break stuff. So how can make su - use bash? Or enable bash for USER or whatever you call it. I'm guessing that relinking /bin/sh changes the default shell for everyone and is inappropriate? Also note that I can't ssh -l USER if this has any affect on things.
I ssh as other-user and use su -.
Considering that dash has now replaced bash, what happens to cron jobs? Are they automatically executed in dash? At least I'm guessing that no-login executions still run in some kind of shell context. Is this correct? Could I explicitly specify bash for cron? My first goal is to get things executing. My second goal is to never have them break again.
If cron executes a script as USER, would "giving USER bash as default shell" automatically affect when cron executes stuff as USER?
I somehwere found this comment "adding -l to the shebang will force login". I'm guessing they meant
```
#! /bin/sh -l
```
But I don't know where to turn for documentation or even what documentation item I'd be looking for. #! seems like a pretty bad search term too. What I am looking for is forcing the same environment effects as a "real" login. I don't really know what those would be, but I'm guessing it would involve execution of .profile, rc.local etc. And would this -l option work without providing username and password? Other than the username being provided to cron.
How do I enable core dumps for cron? On OSX I only ever managed to get the core dumps for manually executed scripts, but not for those executed by cron. Possibly because I've no idea what differs between "actually logging in to run stuff" and "just running stuff" - except for the presence / lack of a terminal attached to stdout and stderr.
And I don't really get anything regarding the stuff I have found and read. For example, setting either hard or soft limit for * as per
```
*  soft  core  10000
*  hard  core  10000
```
But even so, after such a change, switching to USER doesn't change the value of ulimit -c. Moreover, setting the limit as USER only lasts as long as the current session.
```
ulimit -c 10000
```
Given this, I don't really get the difference between soft and hard limits either. I've read that hard limits can't be altered by non-root users, but then how can the hard limit be specified and non-zero while the reported login for a non-root user is still 0?

dalecosp

I probably fail at giving good advice, but as far as #1 goes, after you login, try running chsh(1), changing your shell to /path/to/bash, logout, and back in, and see if that fixes that. If you have sudo privileges, as it appears, you can also run sudo chsh username and change that user's shell as well.

As for #4, I think bash has a command for sourcing a config file, and man bash seems to indicate that it's "--rcfile filename", if that helps.

Wish I could give you all the answers, as you've often done for me. 🙂

NogDog

If it helps, you can specify some environment settings within the crontab itself, including the SHELL setting, something like:

SHELL=/path/to/desired/shell
* * * * * some shell command . . .

johanafm

Thanks to both of you! I'll look into those things today 🙂

johanafm

dalecosp;11036803 wrote:
sudo chsh username

Awesome!

dalecosp;11036803 wrote:
As for #4, I think bash has a command for sourcing a config file, and man bash seems to indicate that it's "--rcfile filename", if that helps.

Excellent! I didn't even know where to start looking.

Some followup question though, when I google "man bash" I get bash(1) - Linux man page. How does Linux distributions relate to each other? Are they built on separate and similar Linux kernels? Are two distros built on the same linux version identical except for icing on the cake? The reason I'm asking is that if I read "Linux man pages", can I be certain I get correct info? Or do I have to read man pages in the shell (hell I don't even know where the back button is!).

Also, what does the (1) in bash(1) indicate. I'm rather certain I've seen other numbers too… Bash version?

dalecosp;11036803 wrote:
Wish I could give you all the answers, as you've often done for me. 🙂

I'm happy with what I got so far! A good starting point is the only thing that is essential! And with unix it seems that learning to solve one problem often gives skills or starting points to solve seemingly unrelated problems… And understanding this shell business seems kind of vital.

johanafm

johanafm;11036817 wrote:
(hell I don't even know where the back button is!).

Funny: man man -> "default pager is "less": man less... 'b' go back N lines, default is one page!

johanafm

NogDog;11036807 wrote:
If it helps, you can specify some environment settings within the crontab itself, including the SHELL setting, something like:
SHELL=/path/to/desired/shell
* * * * * some shell command . . .

Seems like a solid option. Especially since it removes the dependency on future shell choice by the script invoking user by being explicit.

Yet another followup question. From man bash

When bash is started non-interactively, to run a shell script, for example

What does "run a shell script" refer to. All crontab initiated scripts? Others? Are manually executed scripts excluded seeing as they already have a shell to run in?
Edit: or is this only in regards to background execution (using &)?

Edit: sorry if I'm spamming questions here… The problem is that I presently only have Ubuntu on production servers. So I'm not really comfortable with my usual trial and break stuff approach. Perhaps step 1 should be to get a test ubuntu running too.

dalecosp

johanafm;11036819 wrote:
Funny: man man -> "default pager is "less": man less... 'b' go back N lines, default is one page!

Heh heh, try "man woman" in the shell sometime. Or, maybe not, if you're easily offended by darker humor ;-)

What does "run a shell script" refer to. All crontab initiated scripts? Others?

Good question. I'm not sure if I can answer it accurately. This could be, for example, also applicable to "(ba)sh /path/to/script.sh" ... maybe.

Keep in mind that you can also do something like '(ba)sh -c "/path/to/script > /something.else"' ... I'm not at all sure if "script" gets a shell from that one.

Regarding the parens around "ba" there, I generally run a BSD and can't count on bash always being there, so I generally write scripts in sh, or Perl/Python/PHP. 😉

Regarding foobar(1), foobaz(8) and so on, those refer to manual sections, as noted here - a decent write-up at first glance.

This was to allow you to specify a particular man page in the event two calls have the same name, since UNIX systems traditionally have a C/C++ system calls section for system programmers to use (e.g. cpuset(1) - configure processor sets, as opposed to cpuset(2) - manage CPU affinity sets). In those cases it's "man 1 cpuset" for the first one and "man 2 cpuset" for the second.

traq

"interactive" is when you're running commands in the terminal: you type something, bash does it, then waits for your next command. "non-interactive" is when you run a pre-written script (yes, a crontab is such a script): there's no user interaction during the execution.

Most websites that have man pages or other bash references will note when a command does/doesn't apply (or does something stupidly different) on a particular linux flavor. With Ubuntu, the flavor you're looking for is "Debian."

johanafm

dalecosp;11036841 wrote:
Heh heh, try "man woman" in the shell sometime

Nice one! 🙂

dalecosp;11036841 wrote:
Good question. I'm not sure if I can answer it accurately. This could be, for example, also applicable to "(ba)sh /path/to/script.sh" ... maybe.

Keep in mind that you can also do something like '(ba)sh -c "/path/to/script > /something.else"' ... I'm not at all sure if "script" gets a shell from that one.

Oh now it makes sense: there is actually always an invocation of a shell for a shell script! Out of habit I only ever considered php scripts when they mentioned scripts even though they explicitly stated shell scripts. Taking your example, I'd say there are either one or two invocations of shells. The first would be (ba)sh which is invoked for path/to/script. A second script may be invoked, assuming that /something.else is an executeable which in turn invokes a new shell. Assuming something.else was something else, such as a non-executable writeable file, there would only be the first shell invocation. Well, these are my guesses anyway. As for "run in the background" such as "php script.php &", that would need to implicitly invoke a new non-interactive shell. Yet another guess, but the picture does seem a little clearer to me.

dalecosp;11036841 wrote:
Regarding the parens around "ba" there, I generally run a BSD and can't count on bash always being there, so I generally write scripts in sh, or Perl/Python/PHP. 😉

The first and minor reason for switching shells is that dash has no history, arrows generate escape sequences ( [-< ) and other similar issues. Granted, this could be because of other adjustable settings or character encoding mismatches but switching to bash solves all of these inconveniences. But the main reason for wanting bash is that there are two scripts that stopped working, both being PHP scripts. I fixed the first a while back, but today I realized that they would not have been broken in bash.

The second script just results in segfault. There might be more issues that I still have not detected though. The same code worked on redhat, although it sometimes resulted in segfault there too. It also works on my laptop running osx. The segfault is traced from a soap call to zend garbage collector I cannot say for certain that it always segfaults but it seems likely. I've "only" tried running that script manually on the Ubuntu server 5 times in a row, all resulting in segfault. On redhat, it may have once segfaulted two days in a row, but probably not. And usually ran without at most one segfault per week over several months on redhat. On my laptop I don't believe it has ever segfaulted. Still, I cannot guarantee that segfault is the only reason it fails on Ubuntu. I actually havn't yet investigated if it even starts executing with cron. All I know for sure is that it results in segfault (every time?) when run manually and that it has not run since the switch to Ubuntu 3 weeks ago.

So I'm just trying to make the new system more similar to the old one. It's the same approach I'd take if you gave me a working blue car and a broken red car and told me to fix the broken car. I'd probably start by painting it blue and see if it started working…
That they even assign the task to me seems silly though. I'm no system administrator, and this ought to be handled by someone who knows what they are doing. But I guess it's good for me. I get to learn new stuff. And paint cars. On the other hand, I would rather spend my time coding.

But I should probably consider an upgrade to php latest-stable before doing anything else since the the segfault appears when reassigning next/prev pointers in zend garbage collector or whatever the function was named.

dalecosp;11036841 wrote:
"man 1 cpuset" for the first one and "man 2 cpuset" for the second.

Thanks