Originally discussed in the SNAP addon thread with a solution mentioned later for Samba.

 

I think the best place for this to be handled in within unRAID itself. Addons should call a "soft reload" tool within unRAID rather than directly messing about with daemon restarts. This way enhancements and additions covering other services would be handled in one place rather than adhoc within addons.

 

For example changing the typical Samba restart from

 

restart_samba="/etc/rc.d/rc.samba restart"

 

to:

 

restart_samba="kill -1 `cat /var/run/smbd.pid`"

 

Allows samba to restart without losing any connections (which is actually very useful in a LAN with more than one user). I am hoping this can be applied to other file sharing daemons like ftp etc

Originally discussed in the SNAP addon thread with a solution mentioned later for Samba.

 

I think the best place for this to be handled in within unRAID itself. Addons should call a "soft reload" tool within unRAID rather than directly messing about with daemon restarts. This way enhancements and additions covering other services would be handled in one place rather than adhoc within addons.

 

For example changing the typical Samba restart from

 

restart_samba="/etc/rc.d/rc.samba restart"

 

to:

 

restart_samba="kill -1 `cat /var/run/smbd.pid`"

 

Allows samba to restart without losing any connections (which is actually very useful in a LAN with more than one user). I am hoping this can be applied to other file sharing daemons like ftp etc

 

'emhttp' already does this.

Interesting. Will addons be able to call this via the API in the 5 series. If so this Roadmap request would be complete

My interpretation of what limetech said was that emhttp already does a kill -1 instead of a restart;  I don't think he said that it provided a call to do that.  As much as I appreciate the suggestion that unRAID provide some sort of api to add-on apps, I think it's got some downside risks.

For one thing, limetech should be free to make changes without being completely bound by backward compatibility concerns.  How is he to know when some app is dependent on the api?  What about changes forced by new slackware distros?  And from the app developers side, I'd rather not be subject to having my app break if a particular build of unRAID has a broken or changed api.  

The communication and cooperation between the different parties are too disconnected.  

Conversely addons or scripts should not be messing about with unRAID core daemons directly. Things like hard or soft restarting of samba should be done via emHTTP so that if there are implications to the distro as a whole which by definition a single addon cannot know about then emHTTP can deal with it

 

To my eye its far more important to make sure the API is used: pros vs. cons

Conversely addons or scripts should not be messing about with unRAID core daemons directly. Things like hard or soft restarting of samba should be done via emHTTP so that if there are implications to the distro as a whole which by definition a single addon cannot know about then emHTTP can deal with it

 

To my eye its far more important to make sure the API is used: pros vs. cons

 

Success will depend entirely on limetech.  Response time will be a big deal.  Testing will be a big deal.  Getting an updated unRAID build based on add-on app developers needs will be highly unlikely in my estimation.  And lock-stepping unRAID and app distribution cycles will create needless churn for the users.

I'm not opposed to using an api to restart samba or any other feature.  But they need to be published methods, not having to crawl the forum to discover what they are.  I'm not criticizing limetech at all here, he has his own priorities and timelines to meet and I'd rather he stay focused on the stuff on improving unRAID like he is.  

 

But while on the subject, my request is a way to restart udev.  I have a need for this right now and it's a blocking issue for my development.  So here is the first test to show interest in providing an api.

 

But while on the subject, my request is a way to restart udev.  I have a need for this right now and it's a blocking issue for my development.  So here is the first test to show interest in providing an api.

/etc/rc.d/rc.udev restart

 

Don't hold your breath waiting for lime-tech to provide an API for it to control all of Linux through emhttp for your custom add-ons.  It won't happen. 

 

Joe L.

 

But while on the subject, my request is a way to restart udev.  I have a need for this right now and it's a blocking issue for my development.  So here is the first test to show interest in providing an api.

/etc/rc.d/rc.udev restart

 

Don't hold your breath waiting for lime-tech to provide an API for it to control all of Linux through emhttp for your custom add-ons.  It won't happen.  

 

Joe L.

 

I'm not holding my breath at all Joe.  It's not a good use of his time.  I'm pretty sure I've tried restarting udev that way without any success.  

 

But while on the subject, my request is a way to restart udev.  I have a need for this right now and it's a blocking issue for my development.  So here is the first test to show interest in providing an api.

/etc/rc.d/rc.udev restart

 

Don't hold your breath waiting for lime-tech to provide an API for it to control all of Linux through emhttp for your custom add-ons.  It won't happen.  

 

Joe L.

 

I'm not holding my breath at all Joe.  It's not a good use of his time.  I'm pretty sure I've tried restarting udev that way without any success.  

What did not work?

 

Did you first notify the linux kernel of the change using?

sfdisk -R /dev/sdX

and then use the rc.udev restart?  It is necessary, otherwise the kernel does not know anything changed on a device.

 

-R

    Only execute the BLKRRPART ioctl (to make the kernel re-read the partition table). This can be useful for checking in advance that the final BLKRRPART will be successful, and also when you changed the partition table 'by hand' (e.g., using dd from a backup). 

 

In my opinion, these are unix/linux questions, not unRAID issues.

 

Joe L.

Interesting. Will addons be able to call this via the API in the 5 series. If so this Roadmap request would be complete

 

Add-ons can tie into the event notification system.