aboutsummaryrefslogtreecommitdiffstats
path: root/system/doc/embedded/embedded_solaris.xml
blob: 93532da8e6423883d9151007f57e1ae9f43b7caa (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
<?xml version="1.0" encoding="latin1" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">

<chapter>
  <header>
    <copyright>
      <year>1997</year><year>2009</year>
      <holder>Ericsson AB. All Rights Reserved.</holder>
    </copyright>
    <legalnotice>
      The contents of this file are subject to the Erlang Public License,
      Version 1.1, (the "License"); you may not use this file except in
      compliance with the License. You should have received a copy of the
      Erlang Public License along with this software. If not, it can be
      retrieved online at http://www.erlang.org/.
    
      Software distributed under the License is distributed on an "AS IS"
      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
      the License for the specific language governing rights and limitations
      under the License.
    
    </legalnotice>

    <title>Embedded Solaris</title>
    <prepared>Fredrik Tillman</prepared>
    <responsible></responsible>
    <docno>ETX/B/SFP/TILLMAN:96-001</docno>
    <approved></approved>
    <checked></checked>
    <date>2000-10-17</date>
    <rev>B</rev>
    <file>embedded_solaris.xml</file>
  </header>
  <p>This chapter describes the OS specific parts of OTP which relate
    to Solaris.
    </p>

  <section>
    <title>Memory Usage</title>
    <p>Solaris takes about 17 Mbyte of RAM on a system with 64 Mbyte of
      total RAM. This leaves about 47 Mbyte for the applications. If
      the system utilizes swapping, these figures cannot be improved
      because unnecessary daemon processes are swapped out. However,
      if swapping is disabled, or if the swap space is of limited
      resource in the system, it becomes necessary to kill off
      unnecessary daemon processes.
      </p>
  </section>

  <section>
    <title>Disk Space Usage</title>
    <p>The disk space required by Solaris can be minimized by using the
      Core User support installation. It requires about 80 Mbyte of
      disk space. This installs only the minimum software required to
      boot and run Solaris.  The disk space can be further reduced by
      deleting unnecessary individual files. However, unless disk
      space is a critical resource the effort required and the risks
      involved may not be justified.</p>
  </section>

  <section>
    <title>Installation</title>
    <p>This section is about installing an embedded system.
      The following topics are considered,
      </p>
    <list type="bulleted">
      <item>
        <p>Creation of user and installation directory,</p>
      </item>
      <item>
        <p>Installation of embedded system,</p>
      </item>
      <item>
        <p>Configuration for automatic start at reboot,</p>
      </item>
      <item>
        <p>Making a hardware watchdog available,</p>
      </item>
      <item>
        <p>Changing permission for reboot,</p>
      </item>
      <item>
        <p>Patches,</p>
      </item>
      <item>
        <p>Configuration of the OS_Mon application.</p>
      </item>
    </list>
    <p>Several of the procedures described below require expert
      knowledge of the Solaris 2 operating system. For most of them
      super user privilege is needed.
      </p>

    <section>
      <title>Creation of User and Installation Directory</title>
      <p>It is recommended that the Embedded Environment is run by an
        ordinary user, i.e. a user who does not have super user
        privileges.
        </p>
      <p>Throughout this section we assume that the user name is
        <c>otpuser</c>, and that the home directory of that user is,
        </p>
      <pre>
        /export/home/otpuser</pre>
      <p>Furthermore, we assume that in the home directory of
        <c>otpuser</c>, there is a directory named <c>otp</c>, the
        full path of which is,
        </p>
      <pre>
        /export/home/otpuser/otp</pre>
      <p>This directory is the <em>installation directory</em> of the
        Embedded Environment.
        </p>
    </section>

    <section>
      <title>Installation of an Embedded System</title>
      <p>The procedure for installation of an embedded system does
        not differ from that of an ordinary system (see the
        <em>Installation Guide</em>),
        except for the following:
        </p>
      <list type="bulleted">
        <item>
          <p>the (compressed) tape archive file should be
            extracted in the installation directory as defined above,
            and,</p>
        </item>
        <item>
          <p>there is no need to link the start script to a
            standard directory like <c>/usr/local/bin</c>.</p>
        </item>
      </list>
    </section>

    <section>
      <title>Configuration for Automatic Start at Boot</title>
      <p>A true embedded system has to start when the system
        boots. This section accounts for the necessary configurations
        needed to achieve that.
        </p>
      <p>The embedded system and all the applications will start
        automatically if the script file shown below is added to the
        <c>/etc/rc3.d</c> directory.  The file must be owned and
        readable by <c>root</c>, and its name cannot be arbitrarily
        assigned. The following name is recommended,
        </p>
      <pre>
        S75otp.system</pre>
      <p>For further details on initialization (and termination)
        scripts, and naming thereof, see the Solaris documentation.
        </p>
      <pre>
#!/bin/sh
#  
#  File name:  S75otp.system
#  Purpose:    Automatically starts Erlang and applications when the 
#              system starts
#  Author:     [email protected]
#  Resides in: /etc/rc3.d
#

if [ ! -d /usr/bin ]
then                    # /usr not mounted
        exit
fi

killproc() {            # kill the named process(es)
        pid=`/usr/bin/ps -e |
             /usr/bin/grep -w $1 |
             /usr/bin/sed -e 's/^  *//' -e 's/ .*//'`
        [ "$pid" != "" ] &amp;&amp; kill $pid
}

# Start/stop processes required for Erlang

case "$1" in
'start')
        # Start the Erlang emulator
        #
        su - otpuser -c "/export/home/otpuser/otp/bin/start" &amp;
        ;;
'stop')
        killproc beam
        ;;
*)
        echo "Usage: $0 { start | stop }"
        ;;
esac</pre>
      <p>The file <c>/export/home/otpuser/otp/bin/start</c> referred to
        in the above script, is precisely the script <c>start</c>
        described in the section <em>Starting Erlang</em> below. The
        script variable <c>OTP_ROOT</c> in that <c>start</c> script
        corresponds to the example path
        </p>
      <pre>
        /export/home/otpuser/otp</pre>
      <p>used in this section. The <c>start</c> script should be edited
        accordingly.
        </p>
      <p>Use of the <c>killproc</c> procedure in the above script could
        be combined with a call to <c>erl_call</c>, e.g.
        </p>
      <pre>
        $SOME_PATH/erl_call -n Node init stop</pre>
      <p>In order to take Erlang down gracefully see the
        <c>erl_call(1)</c> reference manual page for further details
        on the use of <c>erl_call</c>.  That however requires that
        Erlang runs as a distributed node which is not always the
        case.
        </p>
      <p>The <c>killproc</c> procedure should not be removed: the
        purpose is here to move from run level 3 (multi-user mode with
        networking resources) to run level 2 (multi-user mode without
        such resources), in which Erlang should not run.
        </p>
    </section>

    <section>
      <title>Hardware Watchdog</title>
      <p>For Solaris running on VME boards from Force Computers,
        there is a possibility to activate the onboard hardware
        watchdog, provided a VME bus driver is added to the operating
        system (see also <em>Installation Problems</em> below).
        </p>
      <p>See also the <c>heart(3)</c> reference manual page in
        <em>Kernel</em>.
        </p>
    </section>

    <section>
      <title>Changing Permissions for Reboot</title>
      <p>If the <c>HEART_COMMAND</c> environment variable is to be set
        in the <c>start</c> script in the section, <em>Starting Erlang</em>, and if the value shall be set to the
        path of the Solaris <c>reboot</c> command, i.e.
        </p>
      <pre>
        HEART_COMMAND=/usr/sbin/reboot</pre>
      <p>the ownership and file permissions for <c>/usr/sbin/reboot</c>
        must be changed as follows,
        </p>
      <pre>
        chown 0 /usr/sbin/reboot
        chmod 4755 /usr/sbin/reboot</pre>
      <p>See also the <c>heart(3)</c> reference manual page in
        <em>Kernel</em>.
        </p>
    </section>

    <section>
      <title>The TERM Environment Variable</title>
      <p>When the Erlang runtime system is automatically started from the
        <c>S75otp.system</c> script the <c>TERM</c> environment
        variable has to be set. The following is a minimal setting,
        </p>
      <pre>
        TERM=sun</pre>
      <p>which should be added to the <c>start</c> script described in
        the section.
        </p>
    </section>

    <section>
      <title>Patches</title>
      <p>For proper functioning of flushing file system data to disk on
        Solaris 2.5.1, the version specific patch with number
        103640-02 must be added to the operating system. There may be
        other patches needed, see the release README file
        <c><![CDATA[<ERL_INSTALL_DIR>/README]]></c>.
        </p>
    </section>

    <section>
      <title>Installation of Module os_sup in Application OS_Mon</title>
      <p>The following four installation procedures require super user
        privilege.
        </p>

      <section>
        <title>Installation</title>
        <list type="ordered">
          <item>
            <p><em>Make a copy the Solaris standard configuration file for syslogd.</em></p>
            <list type="bulleted">
              <item>
                <p>Make a copy the Solaris standard configuration
                  file for syslogd.  This file is usually named
                  <c>syslog.conf</c> and found in the <c>/etc</c>
                  directory.</p>
              </item>
              <item>
                <p>The file name of the copy must be
                  <c>syslog.conf.ORIG</c> but the directory location
                  is optional. Usually it is <c>/etc</c>.
                  </p>
                <p>A simple way to do this is to issue the command</p>
                <code type="none">
cp /etc/syslog.conf /etc/syslog.conf.ORIG</code>
              </item>
            </list>
          </item>
          <item>
            <p><em>Make an Erlang specific configuration file for syslogd.</em></p>
            <list type="bulleted">
              <item>
                <p>Make an edited copy of the back-up copy previously
                  made.</p>
              </item>
              <item>
                <p>The file name must be <c>syslog.conf.OTP</c> and the
                  path must be the same as the back-up copy.</p>
              </item>
              <item>
                <p>The format of the configuration file is found in the
                  man page for <c>syslog.conf(5)</c>, by issuing the
                  command <c>man syslog.conf</c>.</p>
              </item>
              <item>
                <p>Usually a line is added which should state:</p>
                <list type="bulleted">
                  <item>
                    <p>which types of information that will be
                      supervised by Erlang,</p>
                  </item>
                  <item>
                    <p>the name of the file (actually a named pipe)
                      that should receive the information.</p>
                  </item>
                </list>
              </item>
              <item>
                <p>If e.g. only information originating from the
                  unix-kernel should be supervised, the line should
                  begin with <c>kern.LEVEL</c> (for the possible
                  values of <c>LEVEL</c> see <c>syslog.conf(5)</c>).</p>
              </item>
              <item>
                <p>After at least one tab-character, the line added
                  should contain the full name of the named pipe where
                  syslogd writes its information. The path must be the
                  same as for the <c>syslog.conf.ORIG</c> and
                  <c>syslog.conf.OTP</c> files. The file name must be
                  <c>syslog.otp</c>.</p>
              </item>
              <item>
                <p>If the directory for the <c>syslog.conf.ORIG</c> and
                  <c>syslog.conf.OTP</c> files is <c>/etc</c> the line
                  in <c>syslog.conf.OTP</c> will look like:</p>
                <code type="none">
kern.LEVEL                /etc/syslog.otp</code>
              </item>
            </list>
          </item>
          <item>
            <p><em>Check the file privileges of the configuration files.</em></p>
            <list type="bulleted">
              <item>
                <p>The configuration files should have <c>rw-r--r--</c>
                  file privileges and be owned by root.</p>
              </item>
              <item>
                <p>A simple way to do this is to issue the commands</p>
                <code type="none">
chmod 644 /etc/syslog.conf
chmod 644 /etc/syslog.conf.ORIG
chmod 644 /etc/syslog.conf.OTP</code>
              </item>
              <item>
                <p><em>Note:</em> If the <c>syslog.conf.ORIG</c> and
                  <c>syslog.conf.OTP</c> files are not in the
                  <c>/etc</c> directory, the file path in the second
                  and third command must be modified.</p>
              </item>
            </list>
          </item>
          <item>
            <p><em>Modify file privileges and ownership of the mod_syslog utility.</em></p>
            <list type="bulleted">
              <item>
                <p>The file privileges and ownership of the
                  <c>mod_syslog</c> utility must be modified.</p>
              </item>
              <item>
                <p>The full name of the binary executable file is
                  derived from the position of the <c>os_mon</c>
                  application if the file system by adding
                  <c>/priv/bin/mod_syslog</c>. The generic full name
                  of the binary executable file is thus</p>
                <code type="none"><![CDATA[
<OTP_ROOT>/lib/os_mon-<REV>/priv/bin/mod_syslog]]></code>
                <p><em>Example:</em> If the path to the otp-root is
                  <c>/usr/otp</c>, thus the path to the <c>os_mon</c>
                  application is <c>/usr/otp/lib/os_mon-1.0</c>
                  (assuming revision 1.0) and the full name of the
                  binary executable file is
                  <c>/usr/otp/lib/os_mon-1.0/priv/bin/mod_syslog</c>.</p>
              </item>
              <item>
                <p>The binary executable file must be owned by root,
                  have <c>rwsr-xr-x</c> file privileges, in particular
                  the setuid bit of user must be set.
                  </p>
              </item>
              <item>
                <p>A simple way to do this is to issue the commands</p>
                <code type="none"><![CDATA[
cd <OTP_ROOT>/lib/os_mon-<REV>/priv/bin/mod_syslog
chmod 4755 mod_syslog
chown root mod_syslog]]></code>
              </item>
            </list>
          </item>
        </list>
      </section>

      <section>
        <title>Testing the Application Configuration File</title>
        <p>The following procedure does not require root privilege.
          </p>
        <list type="bulleted">
          <item>
            <p>Ensure that the configuration parameters for the
              <c>os_sup</c> module in the <c>os_mon</c> application
              are correct.</p>
          </item>
          <item>
            <p>Browse the application configuration file (do
              <em>not</em> edit it). The full name of the application
              configuration file is derived from the position of the
              OS_Mon application if the file system by adding
              <c>/ebin/os_mon.app</c>.
              </p>
            <p>The generic full name of the file is thus</p>
            <code type="none"><![CDATA[
<OTP_ROOT>/lib/os_mon-<REV>/ebin/os_mon.app.]]></code>
            <p><em>Example:</em> If the path to the otp-root is
              <c>/usr/otp</c>, thus the path to the <c>os_mon</c>
              application is <c>/usr/otp/lib/os_mon-1.0 </c> (assuming
              revision 1.0) and the full name of the binary executable
              file is <c>/usr/otp/lib/os_mon-1.0/ebin/os_mon.app</c>.</p>
          </item>
          <item>
            <p>Ensure that the following configuration parameters are
              bound to the correct values.</p>
          </item>
        </list>
        <table>
          <row>
            <cell align="left" valign="top"><em>Parameter</em></cell>
            <cell align="left" valign="top"><em>Function</em></cell>
            <cell align="left" valign="top"><em>Standard value</em></cell>
          </row>
          <row>
            <cell align="left" valign="middle">start_os_sup</cell>
            <cell align="left" valign="middle">Specifies if os_sup will be started or not.</cell>
            <cell align="left" valign="middle"><c>true</c>for the first instance on the hardware; <c>false</c>for the other instances.</cell>
          </row>
          <row>
            <cell align="left" valign="middle">os_sup_own</cell>
            <cell align="left" valign="middle">The directory for (1)the back-up copy, (2) the Erlang specific configuration file for syslogd.</cell>
            <cell align="left" valign="middle"><c>"/etc"</c></cell>
          </row>
          <row>
            <cell align="left" valign="middle">os_sup_syslogconf</cell>
            <cell align="left" valign="middle">The full name for the  Solaris standard configuration file for syslogd </cell>
            <cell align="left" valign="middle"><c>"/etc/syslog.conf"</c></cell>
          </row>
          <row>
            <cell align="left" valign="middle">error_tag</cell>
            <cell align="left" valign="middle">The tag for the messages that are sent to the error  logger in the Erlang runtime system.</cell>
            <cell align="left" valign="middle"><c>std_error</c></cell>
          </row>
          <tcaption>Configuration Parameters</tcaption>
        </table>
        <p>If the values listed in the <c>os_mon.app</c> do not suit
          your needs, you should <c>not</c> edit that file. Instead
          you should <em>override</em> values in a <em>system configuration file</em>, the full pathname of which is given
          on the command line to <c>erl</c>.
          </p>
        <p><em>Example:</em> The following is an example of the
          contents of an application configuration file.</p>
        <p></p>
        <pre>
          [{os_mon, [{start_os_sup, true}, {os_sup_own, "/etc"}, 
          {os_sup_syslogconf, "/etc/syslog.conf"}, {os_sup_errortag, std_error}]}].</pre>
      </section>

      <section>
        <title>Related Documents</title>
        <p>See also the <c>os_mon(3)</c>, <c>application(3)</c> and
          <c>erl(1)</c> reference manual pages.</p>
      </section>
    </section>

    <section>
      <title>Installation Problems</title>
      <p>The hardware watchdog timer which is controlled by the
        <c>heart</c> port program requires the <c>FORCEvme</c>
        package, which contains the VME bus driver, to be
        installed. This driver, however, may clash with the Sun
        <c>mcp</c> driver and cause the system to completely refuse to
        boot. To cure this problem, the following lines should be
        added to <c>/etc/system</c>:
        </p>
      <list type="bulleted">
        <item><c>exclude: drv/mcp</c></item>
        <item><c>exclude: drv/mcpzsa</c></item>
        <item><c>exclude: drv/mcpp</c></item>
      </list>
      <warning>
        <p>It is recommended that these lines be added to avoid the
          clash described, which may make it completely impossible to
          boot the system.</p>
      </warning>
    </section>
  </section>

  <section>
    <title>Starting Erlang</title>
    <p>This section describes how an embedded system is started.  There
      are four programs involved, and they all normally reside in the
      directory <c><![CDATA[<ERL_INSTALL_DIR>/bin]]></c>.  The only exception is
      the program <c>start</c>, which may be located anywhere, and
      also is the only program that must be modified by the user.
      </p>
    <p>In an embedded system there usually is no interactive shell.
      However, it is possible for an operator to attach to the Erlang
      system by giving the command <c>to_erl</c>.  He is then
      connected to the Erlang shell, and may give ordinary Erlang
      commands.  All interaction with the system through this shell is
      logged in a special directory.
      </p>
    <p>Basically, the procedure is as follows.  The program
      <c>start</c> is called when the machine is started.  It calls
      <c>run_erl</c>, which sets things up so the operator can attach
      to the system.  It calls <c>start_erl</c> which calls the
      correct version of <c>erlexec</c> (which is located in
      <c><![CDATA[<ERL_INSTALL_DIR>/erts-EVsn/bin]]></c>) with the correct
      <c>boot</c> and <c>config</c> files.
      </p>
  </section>

  <section>
    <title>Programs</title>

    <section>
      <title>start</title>
      <p>This program is called when the machine is started.  It may
        be modified or re-written to suit a special system.  By
        default, it must be called <c>start</c> and reside in
        <c><![CDATA[<ERL_INSTALL_DIR>/bin]]></c>.  Another start program can be
        used, by using the configuration parameter <c>start_prg</c> in
        the application <c>sasl</c>.</p>
      <p>The start program must call <c>run_erl</c> as shown below.
        It must also take an optional parameter which defaults to
        <c><![CDATA[<ERL_INSTALL_DIR>/releases/start_erl.data]]></c>.
        </p>
      <p>This program should set static parameters and environment
        variables such as <c>-sname Name</c> and <c>HEART_COMMAND</c>
        to reboot the machine.
        </p>
      <p>The <c><![CDATA[<RELDIR>]]></c> directory is where new release packets
        are installed, and where the release handler keeps information
        about releases.  See <c>release_handler(3)</c> in the
        application <c>sasl</c> for further information.
        </p>
      <p>The following script illustrates the default behaviour of the
        program.
        </p>
      <code type="none"><![CDATA[
#!/bin/sh
# Usage: start [DataFile]
#
ROOTDIR=/usr/local/otp

if [ -z "$RELDIR" ]
then
   RELDIR=$ROOTDIR/releases
fi

START_ERL_DATA=${1:-$RELDIR/start_erl.data}

$ROOTDIR/bin/run_erl /tmp/ $ROOTDIR/log "exec $ROOTDIR/bin/start_erl \\ 
                     $ROOTDIR $RELDIR $START_ERL_DATA" > /dev/null 2>&1 &]]></code>
      <p>The following script illustrates a modification where the node
        is given the name <c>cp1</c>, and the environment variables
        <c>HEART_COMMAND</c> and <c>TERM</c> have been added to the
        above script.
        </p>
      <code type="none"><![CDATA[
#!/bin/sh
# Usage: start [DataFile]
#
HEART_COMMAND=/usr/sbin/reboot
TERM=sun
export HEART_COMMAND TERM

ROOTDIR=/usr/local/otp

if [ -z "$RELDIR" ]
then
   RELDIR=$ROOTDIR/releases
fi

START_ERL_DATA=${1:-$RELDIR/start_erl.data}

$ROOTDIR/bin/run_erl /tmp/ $ROOTDIR/log "exec $ROOTDIR/bin/start_erl \\ 
      $ROOTDIR $RELDIR $START_ERL_DATA -heart -sname cp1" > /dev/null 2>&1 &]]></code>
      <p>If a diskless and/or read-only client node is about to start the
        <c>start_erl.data</c> file is located in the client directory at
        the master node. Thus, the <c>START_ERL_DATA</c> line should look
        like:
        </p>
      <code type="none">
CLIENTDIR=$ROOTDIR/clients/clientname
START_ERL_DATA=${1:-$CLIENTDIR/bin/start_erl.data}</code>
    </section>

    <section>
      <title>run_erl</title>
      <p>This program is used to start the emulator, but you will not
        be connected to the shell. <c>to_erl</c> is used to connect to
        the Erlang shell.
        </p>
      <code type="none">
Usage: run_erl pipe_dir/ log_dir "exec command [parameters ...]"</code>
      <p>Where <c>pipe_dir/</c> should be <c>/tmp/</c> (<c>to_erl</c>
        uses this name by default) and <c>log_dir</c> is where the log
        files are written.  <c>command [parameters]</c> is executed,
        and everything written to stdin and stdout is logged in the
        <c>log_dir</c>.
        </p>
      <p>In the <c>log_dir</c>, log files are written.  Each logfile
        has a name of the form: <c>erlang.log.N</c> where N is a
        generation number, ranging from 1 to 5. Each logfile holds up
        to 100kB text. As time goes by the following logfiles will be
        found in the logfile directory</p>
      <code type="none">
erlang.log.1
erlang.log.1, erlang.log.2
erlang.log.1, erlang.log.2, erlang.log.3
erlang.log.1, erlang.log.2, erlang.log.3, erlang.log.4
erlang.log.2, erlang.log.3, erlang.log.4, erlang.log.5
erlang.log.3, erlang.log.4, erlang.log.5, erlang.log.1
...</code>
      <p>with the most recent logfile being the right most in each row
        of the above list. That is, the most recent file is the one
        with the highest number, or if there are already four files,
        the one before the skip.
        </p>
      <p>When a logfile is opened (for appending or created) a time
        stamp is written to the file.  If nothing has been written to
        the log files for 15 minutes, a record is inserted that says
        that we're still alive.
        </p>
    </section>

    <section>
      <title>to_erl</title>
      <p>This program is used to attach to a running Erlang runtime
        system, started with <c>run_erl</c>.
        </p>
      <code type="none">
Usage: to_erl [pipe_name | pipe_dir]</code>
      <p>Where <c>pipe_name</c> defaults to <c>/tmp/erlang.pipe.N</c>.
        </p>
      <p>To disconnect from the shell without exiting the Erlang
        system, type <c>Ctrl-D</c>.
        </p>
    </section>

    <section>
      <title>start_erl</title>
      <p>This program starts the Erlang emulator with parameters
        <c>-boot</c> and <c>-config</c> set.  It reads data about
        where these files are located from a file called
        <c>start_erl.data</c> which is located in the <c><![CDATA[<RELDIR>]]></c>.
        Each new release introduces a new data file.  This file is
        automatically generated by the release handler in Erlang.
        </p>
      <p>The following script illustrates the behaviour of the
        program.
        </p>
      <code type="none">
#!/bin/sh
#
# This program is called by run_erl.  It starts
# the Erlang emulator and sets -boot and -config parameters.
# It should only be used at an embedded target system.
#
# Usage: start_erl RootDir RelDir DataFile [ErlFlags ...]
#
ROOTDIR=$1
shift
RELDIR=$1
shift
DataFile=$1
shift

ERTS_VSN=`awk '{print $1}' $DataFile`
VSN=`awk '{print $2}' $DataFile`

BINDIR=$ROOTDIR/erts-$ERTS_VSN/bin
EMU=beam
PROGNAME=`echo $0 | sed 's/.*\\///'`
export EMU
export ROOTDIR
export BINDIR
export PROGNAME
export RELDIR

exec $BINDIR/erlexec -boot $RELDIR/$VSN/start -config $RELDIR/$VSN/sys $*</code>
      <p>If a diskless and/or read-only client node with the
        <c>sasl</c> configuration parameter <c>static_emulator</c> set
        to <c>true</c> is about to start the <c>-boot</c> and
        <c>-config</c> flags must be changed. As such a client cannot
        read a new <c>start_erl.data</c> file (the file is not
        possible to change dynamically) the boot and config files are
        always fetched from the same place (but with new contents if
        a new release has been installed). The <c>release_handler</c>
        copies this files to the <c>bin</c> directory in the client
        directory at the master nodes whenever a new release is made
        permanent.
        </p>
      <p>Assuming the same <c>CLIENTDIR</c> as above the last line
        should look like:
        </p>
      <code type="none">
exec $BINDIR/erlexec -boot $CLIENTDIR/bin/start \\ 
     -config $CLIENTDIR/bin/sys $*</code>
    </section>
  </section>
</chapter>