Re: /usr/local/etc/rc.d/imapproxyd start
On Fri, Sep 17, 2010 at 01:02:03PM +0200, n dhert wrote: There seems to be a problem with starting up the IMAP proxy server imapproxyd: # /usr/local/etc/rc.d/imapproxyd start says Starting imapproxyd. but doesn't return the # prompt ... # ps -jawx | grep imap root 21490 21426 21490 64248 1 S+ 3 0:00.01 /bin/sh /usr/local/etc/rc.d/imapproxyd start root 21496 21490 21490 64218 1 S+ 3 0:00.01 /usr/local/sbin/in.imapproxyd I would expect the /bin/sh line to disappear and the # prompt to come back. And so it should. I have just installed and tested it, and it works fine. The only way I can replicate the behaviour you report is if I misspell the name of the backend IMAP server - so start checking there. If it's not a typo, it is likely some other variety of DNS error. If (from another terminal window) I do # /usr/local/etc/rc.d/imapproxyd stop is says Stopping imapproxyd. # (returns the prompt) If the first window, it says: Terminated /usr/local/etc/rc.d/imapproxyd: WARNING: failed to start imapproxyd ?? 1. what is wrong here and how to correct it ? 2. also, although I do have a user nobody and a group nobody in FreeBSD 8 and the config file /usr/local/etc/imapproxyd.conf specifies (default setting) proc_username nobody proc_groupname nobody I wonder why the processes (ps -jawx) show root as the process owner ? It will need to start as root in order to bind all the resources it needs, before dropping privileges. Remember that only root can bind ports below 1024. It works fine here. Dan -- Daniel Bye _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ pgp4BlcxyfoWN.pgp Description: PGP signature
Re: /usr/local/etc/rc.d/ scripts and non-root user
Matthew Seaman wrote: [EMAIL PROTECTED] wrote: On Wed, 06 Feb 2008, Alex Zbyslaw wrote Setuid/gid bits on shell scripts aren't considered safe, however and may even be disabled. THERE IS NO REASON FOR THIS, JUST USE THE FILE-SYSTEM TO PROTECT THE FILES (MAKE THEM NOT WRITEABLE). There's no particular reason that setuid bits on scripts are dangerous nowadays. However in the dim and distant past (before the millenium) there used to be a race condition on opening files that meant it was trivial to use a setuid script to get a shell running under the target UID. The horror of this situation seems to have branded itself so deeply on the Unix psyche that even now, when that race condition has been eliminated for many years, there is still a lingering reflex response: setuid scripts bad. Thanks for the clarification. Serves me right for not adding a disclaimer since I had the feeling this had been fixed; but with security better to err on the side of caution. Haven't need a setuid shell script in 15 years and I think I'll still keep it that way :-) It wasn't the right answer to the OPs original problem, in any case. How about: setuid programs of any kind are dangerous. It's very easy to accidentally allow far more than you originally intended. Look at the effort sshd had to go to with privilege separation and that was from a project where security is the watchword. They still got it wrong for a while. How many setuid root programs gave you root shells because they used more at some point? Dim and distant past, maybe, but we all know that history has a habit of repeating itself. Weren't there also tricks you could play with IFS if the script didn't set it? And I'm sure that there was some other race condition to do with ^C in the shell, as well as the file-renaming trick which played on the race condition in the kernel, which BSD has fixed by using a file descriptor. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d/ scripts and non-root user
On Wed, 06 Feb 2008, Alex Zbyslaw wrote SNIP Setuid/gid bits on shell scripts aren't considered safe, however and may even be disabled. THERE IS NO REASON FOR THIS, JUST USE THE FILE-SYSTEM TO PROTECT THE FILES (MAKE THEM NOT WRITEABLE). Scripts are no more susceptible to sabotage and misuse than binary files, it is just that scripts can be more easily decoded and understood than binary files, and so management (that usually doesn't know much about a computer system) becomes frightened and issues orders to relieve their stress. _ Click here to find great deals on vending machines. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oCSwt1BYLoh5xXATYqaxKALXWJLFa8J0MSGPzQwGFpMau8i/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d/ scripts and non-root user
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [EMAIL PROTECTED] wrote: On Wed, 06 Feb 2008, Alex Zbyslaw wrote SNIP Setuid/gid bits on shell scripts aren't considered safe, however and may even be disabled. THERE IS NO REASON FOR THIS, JUST USE THE FILE-SYSTEM TO PROTECT THE FILES (MAKE THEM NOT WRITEABLE). Scripts are no more susceptible to sabotage and misuse than binary files, it is just that scripts can be more easily decoded and understood than binary files, and so management (that usually doesn't know much about a computer system) becomes frightened and issues orders to relieve their stress. There's no particular reason that setuid bits on scripts are dangerous nowadays. However in the dim and distant past (before the millenium) there used to be a race condition on opening files that meant it was trivial to use a setuid script to get a shell running under the target UID. The horror of this situation seems to have branded itself so deeply on the Unix psyche that even now, when that race condition has been eliminated for many years, there is still a lingering reflex response: setuid scripts bad. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHrsBR8Mjk52CukIwRCF9HAJ0RV95skb+MVcRjIJVpkLoVxId7BgCfQ14Y VyixVUuRczh96zewYpx24ik= =X1Lc -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d/ scripts and non-root user
On Sunday 10 February 2008 11:13, Matthew Seaman wrote: [EMAIL PROTECTED] wrote: On Wed, 06 Feb 2008, Alex Zbyslaw wrote SNIP Setuid/gid bits on shell scripts aren't considered safe, however and may even be disabled. THERE IS NO REASON FOR THIS, JUST USE THE FILE-SYSTEM TO PROTECT THE FILES (MAKE THEM NOT WRITEABLE). Scripts are no more susceptible to sabotage and misuse than binary files, it is just that scripts can be more easily decoded and understood than binary files, and so management (that usually doesn't know much about a computer system) becomes frightened and issues orders to relieve their stress. There's no particular reason that setuid bits on scripts are dangerous nowadays. However in the dim and distant past (before the millenium) there used to be a race condition on opening files that meant it was trivial to use a setuid script to get a shell running under the target UID. The horror of this situation seems to have branded itself so deeply on the Unix psyche that even now, when that race condition has been eliminated for many years, there is still a lingering reflex response: setuid scripts bad. Specifically, the system would open the script to read the #! line and find out what interpreter to run, close the script and tell the specified interpreter to re-open it. If an attacker could change the file between the close and the re-open, you would end up running the attacker's script. I believe the fix was to hand the required interpreter an open file descriptor rather than a filename. Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d/ scripts and non-root user
Zbigniew Szalbot [EMAIL PROTECTED] writes: I have looked at my /usr/local/etc/rc.d/ and realized that the symlink I put there has the root as owner. It all works but I would rather use a non-root user for to run that script. $ ls -l /usr/local/etc/rc.d/ lrwxr-xr-x 1 root wheel40 May 9 2007 sender.sh - /usr/home/api/sender/start.sh So I tried: $ sudo chown api /usr/local/etc/rc.d/sender.sh No error but no change either. The original start.sh file has user api but the symlink is owned by root. How can I make sure that the file is indeed run as user api? I prefer to use cron(8) for this (it has an @reboot value for the crontab files), but for using startup scripts, I think the best way is to use su(1) in the script to execute particular commands. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d/ scripts and non-root user
Zbigniew Szalbot wrote: Hello, I have looked at my /usr/local/etc/rc.d/ and realized that the symlink I put there has the root as owner. It all works but I would rather use a non-root user for to run that script. $ ls -l /usr/local/etc/rc.d/ lrwxr-xr-x 1 root wheel40 May 9 2007 sender.sh - /usr/home/api/sender/start.sh So I tried: $ sudo chown api /usr/local/etc/rc.d/sender.sh No error but no change either. The original start.sh file has user api but the symlink is owned by root. How can I make sure that the file is indeed run as user api? AFAIK, the owner of a symlink is completely irrelevant. All accesses to the file are checked against the permissions of the file pointed to, not the symlink. (Same if the target of a symlink is a directory). Once upon a time I'm sure all symlinks were owned by root, but could be misremembering. When you ran your chown, it did nothing at all From man chown Symbolic links named by arguments are silently left unchanged unless -h is used. If you really care; say you want a find -user api to find that symlink then chown -h api /usr/local/etc/rc.d/sender.sh should do what you want. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d/ scripts and non-root user
Hello Alex, 2008/2/6, Alex Zbyslaw [EMAIL PROTECTED]: Zbigniew Szalbot wrote: Hello, I have looked at my /usr/local/etc/rc.d/ and realized that the symlink I put there has the root as owner. It all works but I would rather use a non-root user for to run that script. $ ls -l /usr/local/etc/rc.d/ lrwxr-xr-x 1 root wheel40 May 9 2007 sender.sh - /usr/home/api/sender/start.sh So I tried: $ sudo chown api /usr/local/etc/rc.d/sender.sh No error but no change either. The original start.sh file has user api but the symlink is owned by root. How can I make sure that the file is indeed run as user api? AFAIK, the owner of a symlink is completely irrelevant. All accesses to the file are checked against the permissions of the file pointed to, not the symlink. (Same if the target of a symlink is a directory). Once upon a time I'm sure all symlinks were owned by root, but could be misremembering. When you ran your chown, it did nothing at all From man chown Symbolic links named by arguments are silently left unchanged unless -h is used. If you really care; say you want a find -user api to find that symlink then chown -h api /usr/local/etc/rc.d/sender.sh should do what you want. Thank you. I realized this was the case before I wrote previous message. The thing is the real file is owned by user api. However, when the application is started following a reboot, its logs are created by user root, whereas when I start it by hand as user api, its logs are owned by user api. So it once caused me a problem because the existing log file was owned by root and I stopped then started this particular software by hand as user api. Needless to say, it panicked about not being able to log what it was doing. I wonder that indeed a better solution may be to use cron for automatic startups, which Lowell rightly pointed out to me. I just loved the simplicity of symlinking sh scripts against /usr/local/etc/rc.d/ :) Thank you! Zbigniew Szalbot ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d/ scripts and non-root user
Zbigniew Szalbot wrote: I have looked at my /usr/local/etc/rc.d/ and realized that the symlink I put there has the root as owner. It all works but I would rather use a non-root user for to run that script. $ ls -l /usr/local/etc/rc.d/ lrwxr-xr-x 1 root wheel40 May 9 2007 sender.sh - /usr/home/api/sender/start.sh There's one more potential mistake you are making here. Who the script runs as has nothing at all to do with who owns the script unless setuid or setgid bits are set. They would be set on the script itself and not the symlink, so we'd need to see ls -lL /usr/local/etc/rc.d/sender.sh to know what was set or not. Specifically, startup scripts will always run as root and it will be up to the script to do things as another user if appropriate. E.g. by using su, or sudo, or by running a program which was setuid some-other-user, or because it runs as root, simply changing to another user when appropriate (see man 2 setuid). Setuid/gid bits on shell scripts aren't considered safe, however and may even be disabled. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d/ scripts and non-root user
2008/2/6, Alex Zbyslaw [EMAIL PROTECTED]: Zbigniew Szalbot wrote: I have looked at my /usr/local/etc/rc.d/ and realized that the symlink I put there has the root as owner. It all works but I would rather use a non-root user for to run that script. $ ls -l /usr/local/etc/rc.d/ lrwxr-xr-x 1 root wheel40 May 9 2007 sender.sh - /usr/home/api/sender/start.sh There's one more potential mistake you are making here. Who the script runs as has nothing at all to do with who owns the script unless setuid or setgid bits are set. They would be set on the script itself and not the symlink, so we'd need to see ls -lL /usr/local/etc/rc.d/sender.sh to know what was set or not. $ ls -lL /usr/local/etc/rc.d/sender.sh -rwxr-xr-x 1 api wheel 604 May 8 2007 /usr/local/etc/rc.d/sender.sh I have never really understood the thing about setuids, gid and etc. :) I am not planning a restart so won't try it but I am pretty sure that logs are created by root unless the api is started manually. No big deal really but thanks for all the suggestions! Zbigniew Szalbot ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d/ scripts and non-root user
Zbigniew Szalbot wrote: Thank you. I realized this was the case before I wrote previous message. The thing is the real file is owned by user api. However, when the application is started following a reboot, its logs are created by user root, whereas when I start it by hand as user api, its logs are owned by user api. So it once caused me a problem because the existing log file was owned by root and I stopped then started this particular software by hand as user api. Needless to say, it panicked about not being able to log what it was doing. I wonder that indeed a better solution may be to use cron for automatic startups, which Lowell rightly pointed out to me. I just loved the simplicity of symlinking sh scripts against /usr/local/etc/rc.d/ :) I personally much prefer scripts in rc.d because it's much easier to migrate than crontabs, and if I never use a crontab I always know where to look. It looks to me like you shouldn't be starting the demon as user api - startups scripts should always be started as root. If the demon or whatever is supposed to run as api not root, then perhaps your script should say e.g. su api -c the-path-to-the-demon-or-whatever root can su to whoever without a password, and api can su to api without a password, and everyone else gets prompted. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d/ scripts and non-root user
Zbigniew Szalbot wrote: I have never really understood the thing about setuids, gid and etc. :) I am not planning a restart so won't try it but I am pretty sure that logs are created by root unless the api is started manually. No big deal really but thanks for all the suggestions! It's very simple really. When you run a program it always runs as the user who you are right now. So if you are zbigniew a program you execute runs as you. If you have su'ed or logged in as root, it runs as root. In order to run the program, the user who you are must have the right permissions - i.e. they must have an x bit set. If the program file is owned by the same user as who you are, then you look at the first 3 permissions bits; otherwise if you are in the same group as the program file you look at the next three bits; everyone else looks at the last three bits. (Bits as in pieces, not as in 1/8th of a byte). Some programs need to run as specific users or with a specific group. E.g. shutdown must run as root. You make the file owned by root and set the setuid bit. The permissions might then look like: root wheel r-s-r-x--- shutdown The s replaces the x to show that the file is both executable by root and setuid. Both root and anyone in group wheel can now run shutdown. and the setuid bit says that *whoever* runs the program will run it as if they were root. It's very similar for groups. hth, --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d/ scripts and non-root user
On Wed, 06 Feb 2008 17:09:50 +
Alex Zbyslaw [EMAIL PROTECTED] wrote:
I personally much prefer scripts in rc.d because it's much easier to
migrate than crontabs, and if I never use a crontab I always know
where to look.
It looks to me like you shouldn't be starting the demon as user api -
startups scripts should always be started as root. If the demon or
whatever is supposed to run as api not root, then perhaps your script
should say e.g.
su api -c the-path-to-the-demon-or-whatever
root can su to whoever without a password, and api can su to api
without a password, and everyone else gets prompted.
It's actually built into /etc/rc.subr, the subversion server script is
a simple example of starting a daemon with a different user:
$ grep -v ^# /usr/local/etc/rc.d/svnserve
. /etc/rc.subr
svnserve_enable=${svnserve_enable:-NO}
svnserve_flags=${svnserve_flags:--d --listen-port=3690}
svnserve_data=${svnserve_data:-/usr/local/repositories}
svnserve_user=${svnserve_user:-svn}
svnserve_group=${svnserve_group:-svn}
name=svnserve
rcvar=`set_rcvar`
load_rc_config $name
command=/usr/local/bin/svnserve
command_args=-r ${svnserve_data}
run_rc_command $1
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d startup scripts
Someone is telling me they need to have a .sh suffix to startup correctly, but in past versions of FreeBSD anything you put in there would run as long as it was executable. It need not have an sh extension. The MySQL port, for example, installs /usr/local/etc/rc.d/mysql-server, which works fine. Thanks, Josh ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d startup scripts
In the last episode (Mar 07), Don O'Neil said: Are there any special naming requirements for scripts in /usr/local/etc/rc.d for 6.1? Someone is telling me they need to have a .sh suffix to startup correctly, but in past versions of FreeBSD anything you put in there would run as long as it was executable. Scripts in /usr/local/etc/rc.d are processed using a two-pass method. New rc.subr-style scripts are detected by the presence of a # PROVIDE: line, and are ordered based on dependencies listed in REQUIRE and BEFORE lines. Old-style scripts have to end in *.sh, and are run in alphabetical order after new scripts. Files not ending in .sh without a PROVIDE: line are ignored. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d startup scripts
On Wed, Mar 07, 2007 at 10:58:22AM -0800, Don O'Neil wrote: Are there any special naming requirements for scripts in /usr/local/etc/rc.d for 6.1? Someone is telling me they need to have a .sh suffix to startup correctly, but in past versions of FreeBSD anything you put in there would run as long as it was executable. You can do both, see rc(8). If you use the .sh extension, the script will be executed by the current shell, while those without will be run in a subshell (which is probably what you want). Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpvNQFvzxCcK.pgp Description: PGP signature
Re: /usr/local/etc/rc.d startup scripts
On Wed, 7 Mar 2007 13:40:09 -0600 Dan Nelson [EMAIL PROTECTED] wrote: In the last episode (Mar 07), Don O'Neil said: Are there any special naming requirements for scripts in /usr/local/etc/rc.d for 6.1? Someone is telling me they need to have a .sh suffix to startup correctly, but in past versions of FreeBSD anything you put in there would run as long as it was executable. Scripts in /usr/local/etc/rc.d are processed using a two-pass method. New rc.subr-style scripts are detected by the presence of a # PROVIDE: line, and are ordered based on dependencies listed in REQUIRE and BEFORE lines. Old-style scripts have to end in *.sh, and are run in alphabetical order after new scripts. Files not ending in .sh without a PROVIDE: line are ignored. An RcNG script that ends in .sh is sourced into the current shell rather than executed in a new one. This allows you to bring down the entire boot process. Assuming this behaviour applies to local RcNG scripts too, it's best to avoid the .sh suffix. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: '/usr/local/etc/rc.d/squid stop' problem
In the last episode (Jan 16), [EMAIL PROTECTED] said: It seems something strange with squid-2.6.6 on my FreeBSD 6.2-PRERELEASE box. After running 'usr/local/etc/rc.d/squid stop' (and therefore during system shutdown on 'Ctrl+Alt+Delete' or ACPI power button pushing) I see the following: Stopping squid. Waiting for PIDS: 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564. In case of shutdown /etc/rc.shutdown initiates watchdog timer. I think it isn't normal. Try shutting squid down manually from a shell prompt, then switch to another window/vty and take a look at /usr/local/squid/logs/cache.log . My guess is it's waiting for an active client connection to exit. The default for shutdown_lifetime in squid.conf is 30 seconds. I set it to 5 on my systems. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: '/usr/local/etc/rc.d/squid stop' problem
[EMAIL PROTECTED] wrote: It seems something strange with squid-2.6.6 on my FreeBSD 6.2-PRERELEASE box. After running 'usr/local/etc/rc.d/squid stop' (and therefore during system shutdown on 'Ctrl+Alt+Delete' or ACPI power button pushing) I see the following: Stopping squid. Waiting for PIDS: 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564, 553 564. In case of shutdown /etc/rc.shutdown initiates watchdog timer. I think it isn't normal. On my system the shutdown time of squid is also very long, but it's done before the watchdog kills it. I suppose squid is doing some kind of cleaning up, maybe try to use a smaller cache and check weather that affects the shutdown period. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: '/usr/local/etc/rc.d/squid stop' problem
On Tue, 16 Jan 2007 21:51:08 +0500, Dan Nelson [EMAIL PROTECTED] wrote: Try shutting squid down manually from a shell prompt, then switch to another window/vty and take a look at /usr/local/squid/logs/cache.log . My guess is it's waiting for an active client connection to exit. The default for shutdown_lifetime in squid.conf is 30 seconds. I set it to 5 on my systems. You was right. There was 'Waiting 30 seconds for active connections to finish' in cache.log. I've made 'shutdown_lifetime 5 seconds' in squid.conf too. Squid is shutting down faster now. Thanks a lot! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d and role accounts
Mike Hunter wrote:
Hi,
I'm hoping to get into the spirit of the new rc.d script specs (REQUIRES,
PROVIDES, command=, etc) on a new server I'm building. The old script I
was using looked like this:
I have several questions about how to replicate this behavior. I'm still
deciding whether I'm willing to split out the 10 or so instances into
separate scripts...if I didn't want to do that, is the best way to handle
it to create a script with all 10 command and then have the rc script run
that script?
How do I replicate the su stuff? I could say command=su and
foo_flags=foo-role -c ... but that doesn't seem very good.
Well, you try to suggest rc scripts patches to implement such a beholder...
For example, implement new rc-script variable ${${name}_effective_user}
or like that... (sh syntax doesn't allow you to make such an expression)
Tried to play with and found that:
You may try to add a parameter to rc.conf:
for example, if cupsd.sh sets 'name=cupsd', then you should set
cupsd_effective_user in rc.conf (so, in sh-syntax it sounds like
${name}_effective_user )
The most terrible thing is than you can't extract a value from a
variable, which you name by some dynamic sting (you can't extract a
variable by name set in other variable partly or the whole)
So, some workaround is to use world's tools (may not work in minimal
installation distribution set):
if ! /bin/test -z $(set | /usr/bin/grep
${name}${variable_common_suffix} | /usr/bin/cut -d = -f 2); then
some_tricks();
fi;
Here I've just checked a nonzero length of such a 'dynamically' named
variable. If you can - try to implement such a beholder into rc.subr and
give us patches. If I have time I'll try to do that myself.
As a bonus, foo would like to make pid files, but /var/run isn't writable to
foo-role. What's the standard way to handle where to put the pid files?
/var/run/${progname}/ - directory for pidfiles of progs (ex. clamav's
clamd).
Directory is chowned by `prog' effective UID, or GID and set the
appropriate permissions to allow that UID/GID make changes in it.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d and role accounts
Andrey V. Semyonov wrote:
The most terrible thing is than you can't extract a value from a
variable, which you name by some dynamic sting (you can't extract a
variable by name set in other variable partly or the whole)
Sorry, I'm too hurry.
if ! /bin/test -z $(eval echo \$${name}${common_var_suffix}); then ...
will work well too
.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d not running for jail
I have a jail, running in FreeBSD 6, which starts sshd and syslogd, but doesn't start any of the programs from /usr/local/etc/rc.d All the appropriate variables are in /etc/rc.conf for the various programs (postfix, spamd, clamsmtp, freshclam). I am able to run the programs manually by going to /usr/local/rc.d and doing ./script start Any clues/suggestions? Put the following into the jail's /etc/rc.conf: early_late_divider=NETWORKING That worked for me. My memory is this isn't a *real* solution, but that it does the trick (going off some posts I found on the issue when this happened to me) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d not running for jail
Philip Hallstrom writes: Put the following into the jail's /etc/rc.conf: early_late_divider=NETWORKING Thanks! That worked. That worked for me. My memory is this isn't a *real* solution, but that it does the trick (going off some posts I found on the issue when this happened to me) It seems there is some transition going on right now (or recently). In particular I found this thread: http://tinyurl.com/nnpwy Or the long URL. http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/8 6d957ae29383cea/5cef8e6ce113963a?lnk=stq=early_late_divider%3D%22NETWORKING %22rnum=1hl=en#5cef8e6ce113963a ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d and rcNG style scripts question
Chad Leigh -- Shire.Net LLC [EMAIL PROTECTED] writes: I read the handbook and the man page for rc and one question remains. For scripts in /usr/local/etc/rc.d it appears that the assumption is that all scripts are old style and so, no matter if they are rcGN style scripts or not, they will all run in lexographic order, right? That seems to be the case. I had assumed that rcorder would get invoked there too, but it doesn't. Presumably that's because most of the scripts there *are* old-style, but it wouldn't be very hard to filter them into old- and new- style lists if someone wanted to code that up. It doesn't sound very useful, though; not the way doing it for the system startup scripts was. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d scripts: echo on startup
On 2005-03-10 06:45, Fafa Diliha Romanova [EMAIL PROTECTED] wrote: hello. i'm just wondering how to deal with the way the rc.d scripts echo on startup. like, some of the rc.d scripts contain the echo daemon, while some echo daemon, so on startup whereas it should look like: daemon daemon deamon it may look like: daemondaemon daemon 1.2 Loaded successfully!daemon is there a uniform way to identify echos and make them display properly? thanks! I usually edit the offending scripts in /usr/local/etc/rc.d: # cd /usr/local/etc/rc.d # vi * and make them all use a uniform notification: echo -n foo This does require a bit of shell scripting foo, but it shouldn't be that hard. If it proves more difficult than you expected, feel free to post the script here or personally to me and ask for help. - Giorgos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d scripts: echo on startup
On Thursday 10 March 2005 06:45 am, Fafa Diliha Romanova wrote: hello. i'm just wondering how to deal with the way the rc.d scripts echo on startup. like, some of the rc.d scripts contain the echo daemon, while some echo daemon, so on startup whereas it should look like: daemon daemon deamon it may look like: daemondaemon daemon 1.2 Loaded successfully!daemon is there a uniform way to identify echos and make them display properly? thanks! all the best, fafa You could edit rc.d remove the spaces and replace them with . so it would make it look like: daemon.daemon.daemon.daemon. You could also edit the echo strings so that the spaces are at the beginning/end for all of them... Either way, the output would essentially be the same: daemon deamon daemon daemon deamon daemon man echo? Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d vs /etc/rc.conf question
Toomas Aas wrote: Andy Firman wrote: On my 4.10 box, there is a mysql-server script in /usr/local/etc/rc.d and nothing in /etc/rc.conf, yet mysql-server starts up a boot time. Why? Your mysql-server port was probably installed before 31.10.2004. It was modified to use rc.conf variables at that date (see /usr/ports/UPDATING). AFAIK 4.x will run any script in /usr/local/etc/rc.d which ends in .sh and is executable. The script may use variables stored in /etc/rc.conf but in old installations the scripts has not been updated. If you want not to start mysql-server on startup, rename the script or change permissions. Cheers, Erik -- Ph: +34.666334818 web: http://www.locolomo.org S/MIME Certificate: http://www.locolomo.org/crt/2004071206.crt Subject ID: A9:76:7A:ED:06:95:2B:8D:48:97:CE:F2:3F:42:C8:F2:22:DE:4C:B9 Fingerprint: 4A:E8:63:38:46:F6:9A:5D:B4:DC:29:41:3F:62:D3:0A:73:25:67:C2 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d vs /etc/rc.conf question
On my 4.10 box, there is a mysql-server script in /usr/local/etc/rc.d and nothing in /etc/rc.conf, yet mysql-server starts up a boot time. Why? (the following is true for 4.x) Check the /etc/defaults/rc.conf file You'll see in there that the default setting for local_startup is /usr/local/etc/rc.d /usr/X11R6/etc/rc.d So (as someone else pointed out) if you don't want MySQL to start up, and its script is in one of those default directories, then you'll need to disable that script somehow. Either rename it to not have a .sh extension, or chmod it so it's not executable. __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d vs /etc/rc.conf question
Andy Firman wrote: On my 4.10 box, there is a mysql-server script in /usr/local/etc/rc.d and nothing in /etc/rc.conf, yet mysql-server starts up a boot time. Why? Your mysql-server port was probably installed before 31.10.2004. It was modified to use rc.conf variables at that date (see /usr/ports/UPDATING). -- Toomas Aas |arvutivõrgu peaspetsialist | head specialist on computer networks| |Tartu Linnakantselei | Tartu City Office | - +372 736 1274 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d vs /etc/rc.conf question
On Thu, Dec 02, 2004 at 09:00:19PM +, Dick Davies wrote: * Paul Schmehl [EMAIL PROTECTED] [1210 17:10]: --On Thursday, December 02, 2004 07:39:00 AM -0900 Andy Firman [EMAIL PROTECTED] wrote: I just took over a FreeBSD box and there is a proftpd.sh script in the /usr/local/etc/rc.d directory. There is also this entry in /etc/rc.conf: proftpd_enable=YES There is no need for entries in /etc/rc.conf if the script exists in /usr/local/etc/rc.d right? If you remove the /etc/rc.conf entry, you can still start the daemon manually (/usr/local/etc/rc.d/proftpd.sh start), but it will not start on boot. No, that still won't work (which makes sense if you think about it, how would the script know whether the system is booting or not?). If you read the link below, you should see that you need to 'scriptname forcestart' etc if there is no service=YES in rc.conf. Similarly 'forcestop' to shut it down. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-rcng.html That is Using rc under FreeBSD 5.X but what about 4.10? On my 4.10 box, there is a mysql-server script in /usr/local/etc/rc.d and nothing in /etc/rc.conf, yet mysql-server starts up a boot time. Why? There is nothing wrong, I just want to know why. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d vs /etc/rc.conf question
Andy err no. the entry in /usr/local/etc/rc.d will read the rc.conf to get variables. Normally done thisway when program is installed from ports rather than hand compiled... -- Martin Hepworth Snr Systems Administrator Solid State Logic Tel: +44 (0)1865 842300 Andy Firman wrote: I just took over a FreeBSD box and there is a proftpd.sh script in the /usr/local/etc/rc.d directory. There is also this entry in /etc/rc.conf: proftpd_enable=YES There is no need for entries in /etc/rc.conf if the script exists in /usr/local/etc/rc.d right? Andy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote confirms that this email message has been swept for the presence of computer viruses and is believed to be clean. ** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d vs /etc/rc.conf question
--On Thursday, December 02, 2004 07:39:00 AM -0900 Andy Firman [EMAIL PROTECTED] wrote: I just took over a FreeBSD box and there is a proftpd.sh script in the /usr/local/etc/rc.d directory. There is also this entry in /etc/rc.conf: proftpd_enable=YES There is no need for entries in /etc/rc.conf if the script exists in /usr/local/etc/rc.d right? If you remove the /etc/rc.conf entry, you can still start the daemon manually (/usr/local/etc/rc.d/proftpd.sh start), but it will not start on boot. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-rcng.html Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d vs /etc/rc.conf question
* Paul Schmehl [EMAIL PROTECTED] [1210 17:10]: --On Thursday, December 02, 2004 07:39:00 AM -0900 Andy Firman [EMAIL PROTECTED] wrote: I just took over a FreeBSD box and there is a proftpd.sh script in the /usr/local/etc/rc.d directory. There is also this entry in /etc/rc.conf: proftpd_enable=YES There is no need for entries in /etc/rc.conf if the script exists in /usr/local/etc/rc.d right? If you remove the /etc/rc.conf entry, you can still start the daemon manually (/usr/local/etc/rc.d/proftpd.sh start), but it will not start on boot. No, that still won't work (which makes sense if you think about it, how would the script know whether the system is booting or not?). If you read the link below, you should see that you need to 'scriptname forcestart' etc if there is no service=YES in rc.conf. Similarly 'forcestop' to shut it down. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-rcng.html -- Tempers are wearing thin. Let's hope some robot doesn't kill everybody. - Bender Rasputin :: Jack of All Trades - Master of Nuns ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d broke after 4.7 - 4.9 upgrade
Dan Rue wrote: Hiya, I just upgraded a server from 4.7 to 4.9 stable. Everything's fine, except that for some reason my startup scripts in /usr/local/etc/rc.d are not being executed at boot time anymore. I must have hosed something during mergemaster. I checked rc.conf and defaults/rc.conf - they correctly point to the correct startup directory. Also, if I manually start them they start fine. Has anyone seen this before? Things to check? man rc.subr ? # Add the following lines to /etc/rc.conf to enable daemon: # #daemon_enable=YES Just my 2 öre's worth... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d
Lu [EMAIL PROTECTED] writes: 1. (*) text/plain ( ) text/html Are the /usr/local/etc/rc.d listed on startup script dirs at /etc/defaults/rc.conf?? i.e.: local_startup=/usr/local/etc/rc.d # startup script dirs. I don't know. I'm not the one who asked the question. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d
Rick Duvall [EMAIL PROTECTED] writes: I am kind of curious as to if this issue has been resolved and what the final resolution was. I just started having the same exact issue as of today on my little FreeBSD box at home. I end up having to run the scripts in /usr/local/etc/rc.d manually after bootup. I am half tempted to just call the scripts in /etc/rc.local to get around it. But, it would be nice if it would just work like normal like it is supposed to. Hard to say, since most of us aren't seeing this. If you actually *identified* the issue, it would be a lot easier to determine if it had been solved. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d
I thought I had pasted an earlier post. Maybe I forgot to do that. here it is... On 5/7/03 10:56 AM, Weldon Godfrey weldon at excelsus.com wrote: I have a box running a version of FreeBSD 4.7-STABLE (on or before Fri Jan 31 11:32:06 ). For some reason, all of the scripts in /usr/local/etc/rc.d don't run. * No errors are being seen during boot-up * All the scripts end in .sh * All are owned by root and mode 755 * All are Borne shell scripts, all run from root's command line (when run in the numeric-alpha order they appear in the directory) * None except one does anything with start/stop, the one that takes start/stop is a typical postgresql startup script. * No over-ride for local_startup in /etc/rc.conf. /etc/defaults/rc.conf has not been messed with * /etc rc has not been messed with. I even stubbed the code from rc to see if it would run scripts with the names listed in the directory, and it will * 1st script is A00_mysql.sh, it looks like this (would the ldconfig cause a problem? I have never seen that done before): #!/bin/sh /sbin/ldconfig -m /usr/local/mysql/lib/mysql/ sleep 2 /usr/local/mysql/bin/safe_mysqld --user=mysql Thanks in advance for any advice or what to check into next. Weldon Try adding this to your /etc/rc.conf file: local_startup=/usr/local/etc/rc.d Mike -- Michael K. Smith NoaNet 206.219.7116 (work) 206.579.8360 (cell) mksmith at noanet.nethttp://www.noanet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] - Original Message - From: Lowell Gilbert [EMAIL PROTECTED] To: Rick Duvall [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 5:50 AM Subject: Re: /usr/local/etc/rc.d Rick Duvall [EMAIL PROTECTED] writes: I am kind of curious as to if this issue has been resolved and what the final resolution was. I just started having the same exact issue as of today on my little FreeBSD box at home. I end up having to run the scripts in /usr/local/etc/rc.d manually after bootup. I am half tempted to just call the scripts in /etc/rc.local to get around it. But, it would be nice if it would just work like normal like it is supposed to. Hard to say, since most of us aren't seeing this. If you actually *identified* the issue, it would be a lot easier to determine if it had been solved. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d
Rick Duvall writes: Try adding this to your /etc/rc.conf file: local_startup=/usr/local/etc/rc.d More importantly: I have this: local_startup=/usr/local/etc/rc.d /usr/X11R6/etc/rc.d in /etc/defaults/rc.conf. Is it in yours? (Not Rick's - Weldon Godrfrey's.) And if not, why not? (May not have the X11 part if you haven't installed X.) Robert Huff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d
I have the local_startup=/usr/local/etc/rc.d /usr/X11R6/etc/rc.d in my /etc/defaults/rc.conf, but not in my /etc/rc.conf.. Sincerely, Rick Duvall - Original Message - From: Robert Huff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 05, 2003 3:07 PM Subject: Re: /usr/local/etc/rc.d Rick Duvall writes: Try adding this to your /etc/rc.conf file: local_startup=/usr/local/etc/rc.d More importantly: I have this: local_startup=/usr/local/etc/rc.d /usr/X11R6/etc/rc.d in /etc/defaults/rc.conf. Is it in yours? (Not Rick's - Weldon Godrfrey's.) And if not, why not? (May not have the X11 part if you haven't installed X.) Robert Huff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d/*sh and slow build world in FreeBSD 5.1
On Fri, Oct 10, 2003 at 11:58:33AM +0100, [EMAIL PROTECTED] wrote: Hi I've recently installed a FreeBSD 5.1 box, which is working okay aside from a couple of points: 1) I can't get /usr/local/etc/rc.d/*sh to work. I don't have my rc.conf to hand but I've tried many different config options. Is there something I need to do to run these scripts on a vanilla FBSD 5.1 box? The script is definitely *.sh and executable. 2) Building kernels/worlds is MUCH slower than under 4.X. A kernel used to take around an hour; it's taking about 4 under 5.1 (Cyrix 166mhz/64Mb RAM). Is there still a lot of debugging code in 5.1 which could slow things down? 5.1-WHAT? -RELEASE? -CURRENT? Kris pgp0.pgp Description: PGP signature
Re: /usr/local/etc/rc.d/*sh and slow build world in FreeBSD 5.1
Kris Kennaway ([EMAIL PROTECTED]) wrote: On Fri, Oct 10, 2003 at 11:58:33AM +0100, [EMAIL PROTECTED] wrote: I've recently installed a FreeBSD 5.1 box, which is working okay aside from a couple of points: 1) I can't get /usr/local/etc/rc.d/*sh to work. I don't have my rc.conf to hand but I've tried many different config options. Is there something I need to do to run these scripts on a vanilla FBSD 5.1 box? The script is definitely *.sh and executable. 2) Building kernels/worlds is MUCH slower than under 4.X. A kernel used to take around an hour; it's taking about 4 under 5.1 (Cyrix 166mhz/64Mb RAM). Is there still a lot of debugging code in 5.1 which could slow things down? 5.1-WHAT? -RELEASE? -CURRENT? Whoops. 5.1-RELEASE (-p8 I believe). -- Mark Drayton [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d/*sh and slow build world in FreeBSD 5.1
At 11:58 AM +0100 10/10/03, [EMAIL PROTECTED] wrote: 1) I can't get /usr/local/etc/rc.d/*sh to work. I don't have any ideas to offer on this. 2) Building kernels/worlds is MUCH slower than under 4.X. A kernel used to take around an hour; it's taking about 4 under 5.1 (Cyrix 166mhz/64Mb RAM). Is there still a lot of debugging code in 5.1 which could slow things down? a) I assume you've read /usr/src/UPDATING in your 5.x system, which explains some settings that you can look at if you are wondering about performance. b) the 5.x-series uses gcc 3.3.x for its compiler, while freebsd-4.x has stayed with gcc 2.94. gcc 3.3.x is definitely much slower at *compiling* code. If your only performance measurement is buildworld and buildkernel, then this difference in compile times is the reason for most of the slowdown that you're seeing. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: /usr/local/etc/rc.d files not running on reboot
My machine crashed last night and upon reboot not all the services that are executable in the /usr/local/etc/rc.d ran. Any clues how I can find out why this happened? snip This happened to me on 4.8 recently too. What it ended up being was the sendmail-client startup thing. I'd replaced sendmail w/ postfix, but for some reason, this sendmail-client thing still tried to run, and since I wasn't running sendmail, it just sat there forever. If I ctrl-c'd on the console, it would proceed to run all the startup scripts. I haven't used sendmail in years, but I think this was meant to clear the queue out. I'm not sure if there is a rc.conf entry to stop it (didn't look close enough, but sendmail_enable=NO didn't do it). I just commented the sendmail-client stuff out. Its been a while so I don't remember exactly where this stuff was, but you can probably find it. Once I did that, everything ran again. Cheers, Brent ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: /usr/local/etc/rc.d files not running on reboot
From: Brent Wiese [EMAIL PROTECTED] Date: Wed, 13 Aug 2003 09:41:59 -0700 [snip description about some /usr/local/etc/rc.d scripts not running at boot] This happened to me on 4.8 recently too. What it ended up being was the sendmail-client startup thing. I'd replaced sendmail w/ postfix, but for some reason, this sendmail-client thing still tried to run, and since I wasn't running sendmail, it just sat there forever. If I ctrl-c'd on the console, it would proceed to run all the startup scripts. I'm not sure if there is a rc.conf entry to stop it (didn't look close enough, but sendmail_enable=NO didn't do it). I just commented the sendmail-client stuff out. FWIW this is from my mail server running Postfix: # grep sendmail /etc/rc.conf sendmail_enable=YES sendmail_flags=-bd sendmail_outbound_enable=NO sendmail_submit_enable=NO sendmail_msp_queue_enable=NO I don't think this is the problem the OP had, though, since he didn't mention that boot process hung. Just some services did not start. -- Toomas Aas | [EMAIL PROTECTED] | http://www.raad.tartu.ee/~toomas/ * I take my wife everywhere, but she keeps finding her way back. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d files not running on reboot
what else could be happening here? What happens when you run: /usr/local/etc/rc.d/cucipop.sh start Hi Jez, well there is no output but: shell# /usr/local/etc/rc.d/cucipop.sh start shell# cucipop is starting up fine even after a reboot. I am wondering if the cucipop startup script had an issue because the machine crashed and maybe a pid file remained or something. any thoughts here? - Noah ? -- Jez http://www.munk.nu/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d files not running on reboot
On Sun, Aug 10, 2003 at 07:59:55AM -0800, admin wrote: FreeBSD 4.8-STABLE My machine crashed last night and upon reboot not all the services that are executable in the /usr/local/etc/rc.d ran. Any clues how I can find out why this happened? A number of the files listed are not executable, and therefore won't get run. When this happens, the rc system usually prints a message skipping foo.sh, not executable. Ceri Here is what I have there: total 66 -rwxr-x--- 1 root wheel 181 Jul 8 11:54 000.mysql-client.sh -r-xr-xr-x 1 root wheel 248 Apr 7 17:36 000.pkgtools.sh -r-xr-xr-- 1 root pgsql 1046 Jul 7 08:24 010.pgsql.sh -r-xr-xr-x 1 root wheel 310 Jan 10 2003 apache.sh -r-xr-xr-x 1 root wheel 359 May 30 17:13 cucipop.sh -rwxr-x--x 1 root wheel 3613 Jan 13 2003 cupsd.sh.sample -r-xr-xr-x 1 root wheel 266 Jan 10 2003 emacs.sh -rw--- 1 root wheel 316 Jan 11 2003 idled.sh -rw--- 1 root wheel 289 Feb 10 00:35 innd.sh snip -- User: DO YOU ACCEPT JESUS CHRIST AS YOUR PERSONAL LORD AND SAVIOR? Iniaes: Sure, I can accept all forms of payment. -- www.chatterboxchallenge.com pgp0.pgp Description: PGP signature
Re: /usr/local/etc/rc.d files not running on reboot
On Sun, 10 Aug 2003 17:36:14 +0100, Ceri Davies wrote On Sun, Aug 10, 2003 at 07:59:55AM -0800, admin wrote: FreeBSD 4.8-STABLE My machine crashed last night and upon reboot not all the services that are executable in the /usr/local/etc/rc.d ran. Any clues how I can find out why this happened? A number of the files listed are not executable, and therefore won't get run. When this happens, the rc system usually prints a message skipping foo.sh, not executable. Hi, okay cool - I understand that. but cucipop, for example never started but is executable. there is no message claiming the skipping of cucipop: shell% grep skipping /var/log/messages shell% what else could be happening here? - Noah Ceri Here is what I have there: total 66 -rwxr-x--- 1 root wheel 181 Jul 8 11:54 000.mysql-client.sh -r-xr-xr-x 1 root wheel 248 Apr 7 17:36 000.pkgtools.sh -r-xr-xr-- 1 root pgsql 1046 Jul 7 08:24 010.pgsql.sh -r-xr-xr-x 1 root wheel 310 Jan 10 2003 apache.sh -r-xr-xr-x 1 root wheel 359 May 30 17:13 cucipop.sh -rwxr-x--x 1 root wheel 3613 Jan 13 2003 cupsd.sh.sample -r-xr-xr-x 1 root wheel 266 Jan 10 2003 emacs.sh -rw--- 1 root wheel 316 Jan 11 2003 idled.sh -rw--- 1 root wheel 289 Feb 10 00:35 innd.sh snip -- User: DO YOU ACCEPT JESUS CHRIST AS YOUR PERSONAL LORD AND SAVIOR? Iniaes: Sure, I can accept all forms of payment. -- www.chatterboxchallenge.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /usr/local/etc/rc.d files not running on reboot
On Sun, Aug 10, 2003 at 08:45:21AM -0800, admin wrote: On Sun, 10 Aug 2003 17:36:14 +0100, Ceri Davies wrote On Sun, Aug 10, 2003 at 07:59:55AM -0800, admin wrote: FreeBSD 4.8-STABLE My machine crashed last night and upon reboot not all the services that are executable in the /usr/local/etc/rc.d ran. Any clues how I can find out why this happened? A number of the files listed are not executable, and therefore won't get run. When this happens, the rc system usually prints a message skipping foo.sh, not executable. Hi, okay cool - I understand that. but cucipop, for example never started but is executable. there is no message claiming the skipping of cucipop: shell% grep skipping /var/log/messages shell% I don't think you'll see the error messages from rc in the messages log - you'd have to watch the server console ttyv0 to view those error messages. what else could be happening here? What happens when you run: /usr/local/etc/rc.d/cucipop.sh start ? -- Jez http://www.munk.nu/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
