services tool

[bigpcman]

On to more testing.

I like the services tool it is a nice addition. I'm trying to figure how it works. It does not seem to track the actual status of the service. For instance I use a modified samba script to start, stop and get status. It's  located in /usr/local/etc/init.d and named samba. It works fine when accessed through the console. However, the panel services tool does not track the actual status of samba and does not seem to start samba. Stop appears to work. I have cycled through opening and closing the tool but the status remains the same. Anyway, perhaps an explanation of how the tool works would be helpful. Exactly what commands does it issue and how does it determine status?

See attached pic.

[althalus]

On to more testing.

I like the services tool it is a nice addition. I'm trying to figure how it works. It does not seem to track the actual status of the service. For instance I use a modified samba script to start, stop and get status. It's  located in /usr/local/etc/init.d and named samba. It works fine when accessed through the console. However, the panel services tool does not track the actual status of samba and does not seem to start samba. Stop appears to work. I have cycled through opening and closing the tool but the status remains the same. Anyway, perhaps an explanation of how the tool works would be helpful. Exactly what commands does it issue and how does it determine status?

See attached pic.

WRT services: A quick look at the code and some command line experimentation turns up the following:
Your init script needs to be in /usr/local/etc/init.d/services (or /etc/init.d/services)
/usr/local/etc/init.d/services/samba status should return the PID when the daemon is running
/usr/local/etc/init.d/services/samba status should return NOTHING when the daemon is not running

It would appear that if you corrected your script as above, it should work as expected.

[bigpcman]

On to more testing.

I like the services tool it is a nice addition. I'm trying to figure how it works. It does not seem to track the actual status of the service. For instance I use a modified samba script to start, stop and get status. It's  located in /usr/local/etc/init.d and named samba. It works fine when accessed through the console. However, the panel services tool does not track the actual status of samba and does not seem to start samba. Stop appears to work. I have cycled through opening and closing the tool but the status remains the same. Anyway, perhaps an explanation of how the tool works would be helpful. Exactly what commands does it issue and how does it determine status?

See attached pic.

WRT services: A quick look at the code and some command line experimentation turns up the following:
Your init script needs to be in /usr/local/etc/init.d/services (or /etc/init.d/services)
/usr/local/etc/init.d/services/samba status should return the PID when the daemon is running
/usr/local/etc/init.d/services/samba status should return NOTHING when the daemon is not running

It would appear that if you corrected your script as above, it should work as expected.

If I create a services directory in /usr/local/etc/init.d and put the service scripts there the service tool panel displays services as a service. I believe the services scripts belong in  /usr/local/etc/init.d which is where I had them. Then they show up in the tool panel correctly. Can you see in the code the exact commands that are being used for start, stop and status. What does pressing the button do and what turns on the green light?

[althalus]

If I create a services directory in /usr/local/etc/init.d and put the service scripts there the service tool panel displays services as a service. I believe the services scripts belong in  /usr/local/etc/init.d which is where I had them. Then they show up in the tool panel correctly. Can you see in the code the exact commands that are being used for start, stop and status. What does pressing the button do and what turns on the green light?

The source code for TC3 alpha 4 doesn't seem available, I only had the code from TC2.11 to base my earlier comments on. Presumably the services tool has received an update then. Assuming the code is similar enough between 2.11 and 3.0a4 for the services tool, the button is just a toggle button. The logic is similarly just a toggle.
Application starts - get contents of services folder (keep in mind I'm working with the 2.11 code, hence continuing to reference the services folder)
Application queries each file found in services folder using status as described earlier
Application sets toggle button on or off, and tracks service status
User clicks button:
If light off, turn light on, start service (/usr/local/etc/init.d/services/samba start), update internal status for that service.
If light on, turn light off, stop service, (/usr/local/etc/init.d/services/samba stop), update internal status for that service.



It would be nice if the source code for the FLTK apps in the alphas was included (Or at least the oens that have changed) for those of us curious enough to try and work out how the new things / changed things work...

[Juanito]

User clicks button:
If light off, turn light on, start service (/usr/local/etc/init.d/services/samba start), update internal status for that service.
If light on, turn light off, stop service, (/usr/local/etc/init.d/services/samba stop), update internal status for that service.

Some of my init.d scripts still need modifying to pass the correct exit codes for this to work properly - I'll try to look at this in the next day or two.

[^thehatsrule^]

It's still the same tool.

[curaga]

Correction on the exit codes, return 0 when daemon running, 1 when not. I'll go add this to the sample init.d script thread.

On the paths, they are /etc/init.d/services (to avoid having boot scripts) and /usr/local/etc/init.d.

[Juanito]

The services tool doesn't seem to work with samba3 - perhaps because the samba init.d script starts 2 daemons (nmbd, smbd)?

[bmarkus]

Why don't we adapt prooven scripts used by other distros, like Red Hat?

[Juanito]

Uploaded acpid, avahi, bluez, cpufreqd, cups extensions with adjusted init.d scripts

[curaga]

Why don't we adapt prooven scripts used by other distros, like Red Hat?

They don't have a clean mechanism for this, and text parsing would be just ugly. Adding two exit lines to upstream init.d scripts is a pretty easy way to gain this functionality.

[Juanito]

If I use the services tool to start bluez (which in turn starts dbus if it is not started), the services tool shows bluez as started, but not dbus.

Maybe after starting/stopping a daemon, the services tool should scan the status of the other daemons too?

[bigpcman]

I'm finding the init.d scripts as loaded by OnDemand extensions generally have missing functionality or pre-configured options.

For instance dropbear (ssh) starts up with an "option" set that I want to change.

Samba needs the personalized conf fille and passwd files restored in directories that the samba script creates.

For me it seems there is a conflict between the init.d script the OnDemand extension installs and the actions I want the script to perform. I suppose if the OnDemand install checked to see if an init.d script was already present as a result of a backup/restore and then did not overwrite it the system may work better. Just a thought.

Then there are the service extensions that don't have init.d or startup scripts like x0vncserver.

[bigpcman]

I tried out an approach that seems to work for me regarding preserving my init.d scripts.

Since I want to maintain my own scripts and not allow the OnDemand extension installation to overwrite them I am doing the following with commands in bootlocal.sh:

copy the contents of /usr/local/etc/init.d to /mnt/sdb1/mysys/init.d
Replace /usr/local/etc/init.d with a link to /mnt/sdb1/mysys/init.d

make my service start/stop scripts immutable using the chattr command.

Not the best approach I'm sure but it works for now.

I wonder if the service tool could be made to use the "status" option as a rule to control the green light and leave it to the script to determine if the service is running. I noticed dropbear does not have a "status" case option, cron and tftp are probably the same way. Anyway it would be good to tie the green light to the actual state of the service and not assume a "start" command was successful.

Perhaps there are "start, stop, status" script rules that could be published.

[curaga]

Having extensions overwrite files is a bug, really. Possible solution in the works.