On Mon, 22 Jul 1996 14:40:42 -0700 Rusty Wright said:
>(I sent this on 10 July but never saw it on the mailing list, so I'm
>sending it again. Note that I've also discovered that this bug in
>dsmc causes it to die whenever anyone logs on at the console.)
>I'm running Digital Unix V4.0; I'm pretty sure I was also having this
>problem with V3.2c. The version number that dsmc spits out is
> Command Line Backup Client Interface - Version 2, Release 1, Level 0.3
>I'm running the dsmc program in schedule mode; the line from the rc
>file is
> ${ADSM_PROG} schedule -quiet &
>(Where ADSM_PROG is previously defined to point to the dsmc
>executable.)
>The rc file that is starting it was named S95adsm.
>The problem was that every time the system rebooted the dsmc process
>wasn't started, although according to the "echo" lines in the rc file
>it was. Also, nothing was being recorded in either the sched.log or
>dsmerror.log files.
>I finally tracked it down. When the system boots and runs all of the
>various rc files, one of the files it runs is S90ws. It contains
> #
> # Notify the configuration manager that multiuser has been reached.
> # Currently the graphics ws driver has a callback registered for
> # this point.
> #
> /sbin/sysconfig -r generic user_cfg_pt=45000 > /dev/null
>For some reason this is what was preventing dsmc from running. When I
>renamed my rc file for adsm from S95adsm to S85adsm then I got the
>usual lines in the sched.log file, but the ps command didn't show any
>dsmc process running, so something (S90ws as I had suspected) had
>caused dsmc to die. (By renaming it to S85adsm that caused it to be
>run before S90ws.) When the rc scripts are run, they run with
>standard input, standard output, and standard error attached to the
>console; here's the line from /etc/inittab:
> s3:3:wait:/sbin/rc3 < /dev/console > /dev/console 2>&1
>Since this is on a workstation and my console is a video display (not
>a terminal) I had this hunch that this S90ws was doing something to
>the console which was causing dsmc problems (ws = workstation).
>Renaming the adsm startup script to S85adsm confirmed my hunch.
>I finally resorted to removing the S90ws script and now dsmc finally
>stays running after the system is booted. This is not a good fix
>since what it does is disable the X window system; for me it's ok
>because the system is used as a server. Note also that when anyone
>logs in on the console this also causes dsmc to die.
>So my plea to the IBM engineers who maintain the Digital Unix
>(formerly DEC OSF/1) adsm client is to add some way to close standard
>input, standard output, and standard error when the client is running
>as a unix daemon. For example, add a -detach command-line option.
>Here's the usual detaching code you see in unix daemon programs on BSD
>systems:
>
> ndescriptors = getdtablesize();
> if (fork())
> exit(0);
> for (s = 0; s < ndescriptors; s++)
> (void) close(s);
> (void) open("/", O_RDONLY);
> (void) dup2(0, 1);
> (void) dup2(0, 2);
> tt = open("/dev/tty", O_RDWR);
> if (tt > 0) {
> ioctl(tt, TIOCNOTTY, (char *)0);
> (void) close(tt);
> }
>On Digital Unix it looks like there's a routine in the libutil.a
>library called "daemon" you can use that does the same thing.
>If whoever supports the Digital Unix client doesn't read this list,
>could someone from IBM please pass this on to them? Thanks.
Yes, you probably were having the same problem in 3.2 as you are in 4.0.
I have a simple shell script that seems to work fine for me. I don't
use inittab personally and I have the script as S96adsm (S95 is xlogin
on my workstation). The rest of the script is standard junk but, here
is the line that's important:
nohup ${ADSM}/dsmc SCHEDule >>${ADSM}/schedule.log 2>&1 &
---
Keith A. Crabb Keith AT UH DOT EDU
Keith A. Crabb Keith AT UH DOT EDU
University of Houston Operating Systems Specialist +1-713-743-1530
|
