Closed solbu closed 2 years ago
The channel files are saved at (I believe) five minute increments by default. If you haven't manually saved using the .save command, any changes will be lost. If you restarted the bot properly with either .die/.restart, the changes would then also be saved. So to your point, you are correct, changes are only saved incrementally. We do not recommend killing bots from the command line.
I can't speak to what/how netsave works as we didn't write it nor maintain it. I would maybe suggest doing a .save on the bot you make the changes on first, then a netsave? But again, I have no idea what that command is doing.
Also, one other tip, that channel add command will only be run if the channel isn't already added to the bot. We recommend adding/managing channels via the partyline .+chan command. Some people think those settings are set each time the bot starts, but that is not accurate. That syntax is better suited for use in a Tcl script, not the config file that is run at each load.
I don't know what .netsave does either. That's something 3rd party. When I make changes to channel settings, I always follow up with a .chansave - which you didn't mention. Try that and see if it persists.
Thanks @skralg - I meant .chansave, not .save (.save does the userfile)
The channel files are saved at (I believe) five minute increments by default. If you haven't manually saved using the .save command, any changes will be lost. If you restarted the bot properly with either .die/.restart, the changes would then also be saved. So to your point, you are correct, changes are only saved incrementally. We do not recommend killing bots from the command line.
And you missed my explisit statement which said that I am saving the config before I kill the bot to test what will happen if the server is rebooted – which kills the bot as part of the shutdown process.
I can't speak to what/how netsave works as we don't administer it. I would maybe suggest doing a .save on the bot you make the changes on first, then a netsave? But again, I have no idea what that command is doing.
«.netsave» just performs «.save» and «.chansave» across the entire bot network, saving me from having to manually connect to every eggdrop's partyline in the network just to save the channel and user files after adding or removing users and/or channels.
Also, one other tip, that channel add command will only be run if the channel isn't already added to the bot. We recommend adding/managing channels via the partyline .+chan command.
Which is exactly what I've been doing for the last 21 years. Like I said, I really do know how eggdrop works, and also how it Does Not work. :-)
Some people think those settings are set each time the bot starts, but that is not accurate. That syntax is better suited for use in a Tcl script, not the config file that is run at each load.
The «channel add #mychannel {» is the content of the channel file, not something I type in the partyline or as a !command in a channel or in a query to the bot. Meaning, that is what the eggdrop is saving in that file when you run «.save / .chansave».
I meant .chansave, not .save (.save does the userfile)
«.save» also saves the chan file, not just the user file. I know it did not used to do this in older versions, but I don't know when it also started to save the channel config.
You're using a third party script that we don't control to do a save. What is being suggested to you is to run .chansave on that bot and see if the changes are saved. That way you can determine if it is Eggdrop or netbots not saving
I've been using Eggdrop since version 1.0e, and I don't think .save ever saved the chanfile.
I've been using Eggdrop since version 1.0e, and I don't think .save ever saved the chanfile.
Mine does, I only noticed this while attempting to debug my need-op issue.
I can say definitively .save does not save a channel file, perhaps that's where the confusion is occuring. If you're interested, the relevant function is line 1497 in cmds.c, and the subsequent function on line 566 of userrec.c (more or less, I may not have the same version of code as you in front of me).
So again, I suggest trying .chansave by itself and seeing how that goes, and we can dig down more into an issue from there if it arises.
Fun - so channels.mod hooks that elsewhere and it looks like it writes the chanfile too... I stand corrected!
But now we are starting to discuss something irellevant to my issue. ;-)
Trust me, the channel file is being saved before I restart the bot, I allways checked this before I even opened this bug repport as part of the attempt at debugging it.
My issue is that when the bot starts back up it does not use the «need-op» info from the channel file, or it chooses to ignore it.
I ran v1.8.4 and «.chansave» did remove the entered config for some reason that I could not figure out, so I updated this specific eggdrop to v1.9.2 and now it does save the need-op setting, but restarting the bot still does not «see» the need-op config, but it does see every other channel configuration.
I even deleted the channel and added it again using «+chan», then I added the need-op setting, which worked while the bot was running. Then I saved the chanfile, verified that the saved config does indeed have the need-op configuration, and restarted the bot. When the bot started back up, the need-op is still present in the chan-file but the bot does not see this specific channel setting.
I just tested the same process - add need-op, save with .save, kill the bot from CLI, check the chan file (need-op exists), start the bot, check .chaninfo- and the need-op line exists.
Is netbots perhaps sharing channel settings between bots, and it is downloading and overwriting the settings it had when it started?
It may be more efficient for you to join #eggdrop on Libera and work through some additional troubleshooting steps there
Is netbots perhaps sharing channel settings between bots, and it is downloading and overwriting the settings it had when it started?
netbots only makes manageing channels across an eggdrop network easier as it sets configuration across the botnet, using the existing eggdrop user and chan file processes.
It may be more efficient for you to join #eggdrop on Libera and work through some additional troubleshooting steps there
Ahh, I joined the EFnet channel which is full of people, but no-one seems to be alive. Joining on libera now. :-)
It may be more efficient for you to join #eggdrop on Libera and work through some additional troubleshooting steps there
And that was wery helpful. A few users suspected my usage of the netbots script archive, so i grepped for any script having «need-op» inside and inspected them. netbots turned out to have this in the file «netbots/botnetop.tcl»:
proc bop_clearneeds {} {
foreach chan [channels] {
channel set $chan need-op ""
channel set $chan need-invite ""
channel set $chan need-key ""
channel set $chan need-limit ""
channel set $chan need-unban ""
}
bop_settimer
return
}
Turning Off the «netbots.tcl v4.10» script solved my problem. Since this is a standalone bot which is not going to be a part of any botnet anytime soon, turning off netbots is not a big deal for me.
So thank you for pointing me in the right direction in the IRC channel, as well as some pointers here.
Hi, I have a strange error I can't figure out.
I have been running an eggdrop network since 2001, and two eggdrop networks since 2013, so I know my way around eggdrops. But this is the first time I have had the need to ask chanserv for OP, as my 2 other bot networks run on EFnet which does not have any services of any kind. (chanfix re-op the last few ops when it become opless, but it is itself not a channel service)
Sometime last year a channel on OFTC needed an eggdrop to block the join-spam-quit that made trouble in the channel, so we opted to moderate and I launched an eggdrop with the sole purpose to voice everyone after a 1 minute delay. (The spam bots deliver the spam withing 20 seconds after join, so delaying 1 minute is enough to stop them from spamming)
The eggdrop (v1.9.2) logs in to nickserv using a script («Auto identify» by «Alien»). Activating «AutoOP» in chanserv is Not an option. Chan-owner has deliberately disabled it, and only registered OPs can get OP, so no bot-network. So I configure the bot to ask chanserv for op via the «need-op» setting.
I add the needed command in the partyline using .chanset, which works … until I restart the bot. Then it completly forgets the setting when the bot starts back up. The chanfile is not changed, but the bot does not see the need-op channel config upon startup for some reason – or chooses to ignore it.
I save the config using «.netsave» (from the netbots script) and then restart the eggdrop from the shell using «killall eggdrop» (simulating powerloss and OS reboot). After the bot starts back up and rejoins, it does Not get op, so I connect to the partyline and check .chaninfo again
Now there is No configuration on how it should gain OPs. It is Losing the «need-op» setting, and i cannot figure out why.
Anyone have any idea what could cause this?
For reference, this is the chan file: