[IDEA] Use rpi LEDs as status LEDs for moOde itself

[Tim Curtis]

What the issue with NFS? I don't have any experience with it.

It will be better explained here Hard Mount Vs Soft Mount than I will do myself I guess

For a home server or a NAS, soft mount should be sufficient. Hard mounts are for client-server environments where data integrity is a major concern.

If moOde is mounting NFS resources with option 'ro' then the data integrity issue is moot. May as well choose soft mount to avoid the possible zombie state where the system hangs forever waiting for the server. 

Brrr. I get the shivers remembering the bad old days when my lab and others had multiple cross-mounted filesystems on our engineering workstations and we'd end up in deadly embraces trying to bring them back up after a crash. What made it worse was our research facility were a heterogeneous OS shop---countless SunOS/Solaris stations, a few dozen SGI IRIX stations, a handful of IBM  AIX stations, even one or two DEC Ultrix stations. The network administrators didn't last long.

Regards,
Kent

lol, the good ol days.

@romain  I'm still not clear whether any coding changes are necessary in your script to deal with the NFS stuff.

[romain]

What the issue with NFS? I don't have any experience with it.

It will be better explained here Hard Mount Vs Soft Mount than I will do myself I guess

For a home server or a NAS, soft mount should be sufficient. Hard mounts are for client-server environments where data integrity is a major concern.

If moOde is mounting NFS resources with option 'ro' then the data integrity issue is moot. May as well choose soft mount to avoid the possible zombie state where the system hangs forever waiting for the server. 

I agree with Kent, since the share is already mounted with 'ro' option data integrity on the NFS server will be preserved anyway and hard mount becomes unnecessary.

Add this to the freeze it may induce and you have already two reasons not to use NFS hard mounts imho.

In the worst case with soft mounts, the connection will be lost and the client will stop contacting the server. If the server gets back online, the script will remount the share automatically.

[romain]

What the issue with NFS? I don't have any experience with it.

It will be better explained here Hard Mount Vs Soft Mount than I will do myself I guess

For a home server or a NAS, soft mount should be sufficient. Hard mounts are for client-server environments where data integrity is a major concern.

If moOde is mounting NFS resources with option 'ro' then the data integrity issue is moot. May as well choose soft mount to avoid the possible zombie state where the system hangs forever waiting for the server. 

Brrr. I get the shivers remembering the bad old days when my lab and others had multiple cross-mounted filesystems on our engineering workstations and we'd end up in deadly embraces trying to bring them back up after a crash. What made it worse was our research facility were a heterogeneous OS shop---countless SunOS/Solaris stations, a few dozen SGI IRIX stations, a handful of IBM  AIX stations, even one or two DEC Ultrix stations. The network administrators didn't last long.

Regards,
Kent

lol, the good ol days.

@romain  I'm still not clear whether any coding changes are necessary in your script to deal with the NFS stuff.

Tim, there are no changes necessary in my script if you decide to go with NFS soft mount as the default behaviour.

[romain]

I think auto-remount is goodness for all users but I'll have to think about how the LED status feature will co-exist with the existing LED feature. The existing feature is for users that want to turn the LED's off. Maybe on System Config we could do drop downs like below.

Code:

LED0 (Act): [            ] On, Off, Mount Status
LED1 (Pwr): [            ] On, Off, Mount Status

Btw, what Open Source license do you want to attach to your nice script, GPLv3, MIT?

-Tim

Rethinking about how both features would co-exist, I think LED0 and LED1 shouldn't be set independantly when choosing the "Mount Status" because both LEDs are useful for this purpose. Does it make sense ?

Makes sense. Im not sure how to do the UI options cos some users want to control each LED, mainly leaving power ON but turning the activity LED off.

Maybe something like a 'LED Operation' dropdown list with two options: 
- On/Off (default)
- Mount Status

with the LED0/LED1 toggle switches just below

If the user chooses the Mount Status option then the LED0/LED1 toggle switches could become unavailable, hidden or greyed out, and the LEDs would be disabled by worker.php letting the systemd service handle them. Maybe too complicated, I don't know.

[romain]

@Tim Curtis for more clarity maybe you could rename the script and systemd files to 'mountstatus' rather than 'checksources' which doesn't sound very explicit.

[romain]

@Tim Curtisyou'll probably have to change something in worker.php when mount status is enabled ; rc.local by default is started after all the other services and executes worker.php lastly. If LEDs are disabled in favour of mount status, worker.php, as it works actually, switches the LEDs off after mount status is started and you have to wait for about one minute to see the LEDs on again.

For testing, I've delayed the execution of mount status after rc-local.service in the systemd unit file but it didn't change anything.

[Tim Curtis]

It will probably have to run within workers job processing loop similar to clock radio etc.

[romain]

It will probably have to run within workers job processing loop similar to clock radio etc.

OK Tim

[romain]

It will probably have to run within workers job processing loop similar to clock radio etc.

Tim,
just for testing, I've disabled both systemd service and timer units before putting the following commands in worker.php, after line 631:

Code:

sysCmd('systemctl start checksources.service');
sysCmd('systemctl start checksources.timer');

I don't know exactly if this how and where it should be added but now mount status works at startup.

[Tim Curtis]

I was initially thinking of doing the logic in the while loop as a checkSources() function but your approach should work just fine :-)