Rc5.d

[Celedonio Miranda]

Thereshould definitely be a way to do what you want from the /etc/rc*. Another alternative you might want to look into is cron. With vixie-cron it's possible to specify tasks to run on reboot with the @reboot keyword in your crontab:

Does opensuse have selinux?If so is it turned on and is the context of your script the same as the other start up scripts?Try getenforce to see if selinux in installed an turned on.Try ls -lZ /etc/init.d/rc5.d/ to see the scripts' contexts

I am trying to install balenaEngine on an AXC F3152 running FW 2023.0.9 LTS. When executing the command "update-rc.d -s balena defaults" from the setup.sh script, I get the error "/usr/sbin/update-rc.d: line 74: /etc/rc5.d/S20balena: Permission denied", even if I am running the script as root. This happened after doing a factory reset with "sudo recover-plcnext 2". Before factory reset, balenaEngine was installed and running successfully.

Before our next attempt to reproduce this behaviour, do you mind me asking where you got FW version 2023.0.9 LTS ? That doesn't seem to be a firmware version that's publicly available (unless I'm missing something).

I have activated SSH login as root user, and tried running the "update-rc.d -s balena defaults" command from root. The file for which permission is denied ("/etc/rc5.d/S20balena") has permission string "lrwxrwxrwx".

I have a script on ubuntu that I put in /etc/init.d. It has 0755 permissions, and I can run it manually both executing it and sourcing it, with good results. I have symlinks in both /etc/rc3.d and /etc/rc5.d, both named S01raid, both pointing to the init.d script. When I reboot the machine however, the script doesn't seem to run. I dont see the array mounted or even running, nor do I see the monitor daemon running on the ps -A output

Look at this answer to a similar question, where I listed down the steps to follow. Also, as mentioned by another user on that question, for testing purposes I'd just place the commands in /etc/rc.local, before the "exit 0".

Thanks jrobalin for a great tutorial. I've been trying to get C application to start on system reboot for the past day or so and this was a real help. However I'm still stuck on a few points which might be useful for other relative newcomers to this:

/etc/init.d/criodaq start (criodaq is the name of the script and cRioTestC is a C binary). I know the program starts because I have programmed LEDs on the chasis but nothing prints in the console. Is there a way in the script to either log print statements from the program running or show in console?

2) I can find my progam in the rc1.d,rc2.d,rc3.d,rc4.d,rc5.d and rc6.d but the program does not start on a system reboot- at least the LED's which are supposed to turn on do not . Any ideas on how I can begin to troubleshoot this?

A more correct, clean way to do this would be to use the syslog() functionality to log to the system logger daemon. Depending on how you open the syslog connection, the messages will likely show up in /var/log/messages, so long as you open the connection with defaults (e.g. don't try to open the connection with the LOG_AUTH facility).

Getting some semblance of logging working will go a long way in helping you troubleshoot, but for the time being let's do a sanity check. Can you check to see if the process is running by checking the output of ps -e grep cRio? How did you install the rc.N links? update-rc.d? What actual command did you use?

So the way I solved this was to set the program to start after everything else. Seems like /usr/sbin/update-rc.d -f Name defaults sets the application loading somewhere in the middle of other daemons? To set the application to load right at the end of everything else I used.

To log files I had to remove --background from my script and add > /home/admin/cRioKE/criodaqlog.log 2>&1 Code below. I realise this is a 1) a bit dirty and 2) I don't fully understand what the consequences of removing --background might be?

Yes, jamie_mac, omitting the actual dependecy-resolution numbers places the links such that your daemon is started and stopped at 20. It is likely that there is some dependent daemon or service that is not yet available when it was starting at the default level. The actual LED facility is provided by the kernel, so it was likely some other resource that was unavailable

The SystemExec VI is a bit of a special case, it basically does things to hijack the standard output. You can probably get around this by adding a layer: have a script that, within the script, will call the binary and redirect stdout to a log file. Not 100% sure this will work, but I know that trying to take stdout from the System Exec.vi is unlikely to do what you want

I'm not sure if anyone still monitors this page, but I am running into a conundrum here and I was wondering if someone had insight. My app requires remote access to the serial ports on my cRIO from the host, so I have configured ser2net (successfully) to forward them over TCP/IP. Using this tutorial as a guide, I was able to get ser2net to start on boot, which is fantastic.

The only issue I am having is trying to configure the serial port settings at boot. This is a slightly different use case from the above, since I don't want to start a daemon, but simply run a few commands. I use stty to set my serial configurations, and have incorporated it into the startup script as shown below.

Now, if I test this after installing the script (by entering "/etc/init.d/ser2net.startup start" in the shell), this works fine. However, if I reboot, the commands seem to do nothing, and the port config stays default.

This sounds like what I need to do in order to satisfy a requirement I have for an upload process where we are loading new RTEXE onto the system not using the project, I need a way to launch the newly uploaded RTEXE and then if it fails to revert to the original RTEXE which will only be replaced once the new RTEXE starts successfully.

While working with another user to follow this tutorial, the user was receiving errors because their Windows formatting of the file wasn't recognized by the Linux system. They were able to resolve this by following the guidance here. Once the text file was converted to a format that was readable by the Linux OS they were able to successfully follow this tutorial.

The login will be to my experimental VM "lyra". Don't be surprised about some possible "oddities", this system is under heavy experimentation. :) Concerning the Upstart issue though I compared it with my production VM (Ubuntu 10.04 too) and it behaves identical. Both Ubuntus are 64-bit btw, in case that matters.

What's odd is that it does work OK on my test systems! But the current code just assumes that the old-style init behavior is still supported, when it seems that isn't always the case. I will update Webmin to switch completely to upstart's way of doing things, when installed..

Problem with the "BIND9" service: In the overview list, it is listed as "No" in the "At boot" column, even though in the details screen the radio button is set to "Start at boot time: Yes" (the latter of which is correct).

When I change it to "No", the softlink in /etc/rc5.d is correctly disappears. When I change it back to "Yes", the link is re-created, but with prefix S99 while before it was S02 (that determines the startup order as far as I remember).

The two problems described for BIND still persist. It is shown as "At boot: No" in the overview despite the rc5.d symlink exists. Turning "on boot" off and on re-creates the link with "S99" instead of "S02".

When I turn "on boot" off and on for an Upstart job, in addition to modifying its /etc/init file, it creates a link in rc*.d. The behavior pertaining to that is a little odd though. When I test this with multiple Upstart jobs, the erroneous symlink for the job I tested just before then disappears, and the link for the new job appears.

How do you determine whether a service is configured to "start at boot" for the overview list? 'cause Mailman also has a startup file /etc/rc5.d/S03mailman present, but is shown as "At boot: no". I tried finding out the commands through Webmin's debug log, but I can't seem to see the commands responsible for that there.

If an action uses old-style init scripts and the script doesn't accept a status parameter, then Webmin will not be able to determine if it is running and will show "Unknown" .. which is kind of un-avoidable.

I'd like to autostart my application on boot. (This seems like something others would have done.) I'm using a board derived from the Sabre board with iMX6. I'm running Linux. Searches online have yielded suggestions based on inittab (does not exist), init.d, rc.d, etc. I've added a script to init.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, rc6.d, and rcS.d. None of these result in running the script.

3a8082e126