October 20, 20169 yr Description: syslog was saved in previous releases to the flash drive. How to reproduce: Reboot system and syslog is not saved. Expected results: A copy of the syslog would be saved to the flash drive. Actual results: A copy of the syslog is not saved to the flash drive. Other information: This is helpful in troubleshooting issues.
October 20, 20169 yr Specifically took that out and replaced with generating diags but only if cmdStop times out. Is there a need to save the syslog upon every shutdown, even successful shutdowns?
October 20, 20169 yr Author Specifically took that out and replaced with generating diags but only if cmdStop times out. Is there a need to save the syslog upon every shutdown, even successful shutdowns? Yes. Otherwise there is no way for me to know if my plugins are shutting down properly at the right times. I'm kind of blind without it. For example, I am trying to check that the UD plugin is stopping at the right time (after VMs and Dockers but before stop services)and I can't because I have no log form a shutdown.
October 20, 20169 yr Specifically took that out and replaced with generating diags but only if cmdStop times out. Is there a need to save the syslog upon every shutdown, even successful shutdowns? Yes. Otherwise there is no way for me to know if my plugins are shutting down properly at the right times. I'm kind of blind without it. For example, I am trying to check that the UD plugin is stopping at the right time (after VMs and Dockers but before stop services)and I can't because I have no log form a shutdown. You can't use the events "stopping_libvirt" and "stopping_docker" which occur before "stopping_svcs" ?
October 20, 20169 yr Maybe tie a script to "unmounting_disks" to copy the syslog off to a folder somewhere? I'm trying to minimize writing to the usb flash unnecessarily.
October 20, 20169 yr As you know, we have created a few predefined shares: system, appdata, domains, isos. At present the only subdirs under system are: ./docker ./libvirt Longer term we want to move the docker-related files currently downloaded to the flash (config/plugins/dockerMan) to the system/docker directory. We can also create other subdirs there for maintenance purposes; maybe system/tmp could be used for your purposes?
October 20, 20169 yr Longer term we want to move the docker-related files currently downloaded to the flash (config/plugins/dockerMan) to the system/docker directory. Can I suggest then that starting with RC3 (or whatever the next release is) that say within var.ini you add an entry with the current storage location for those files (right now hardcoded at /boot/config/plugins/dockerMan) regardless of whether you implement the change to store everything within the system share. That will allow CA to test if that entry in var.ini exists and look at that location instead of being itself hardcoded to look on the flash which will minimize the amount of updates required to CA to remain functional in the future.
October 20, 20169 yr Longer term we want to move the docker-related files currently downloaded to the flash (config/plugins/dockerMan) to the system/docker directory. Can I suggest then that starting with RC3 (or whatever the next release is) that say within var.ini you add an entry with the current storage location for those files (right now hardcoded at /boot/config/plugins/dockerMan) regardless of whether you implement the change to store everything within the system share. That will allow CA to test if that entry in var.ini exists and look at that location instead of being itself hardcoded to look on the flash which will minimize the amount of updates required to CA to remain functional in the future. Yes that's a good idea. This change won't get into 6.3. Hopefully 6.3 only has one or two more -rc's before we promote to stable. This change would prob go into 6.4.
October 20, 20169 yr Longer term we want to move the docker-related files currently downloaded to the flash (config/plugins/dockerMan) to the system/docker directory. Can I suggest then that starting with RC3 (or whatever the next release is) that say within var.ini you add an entry with the current storage location for those files (right now hardcoded at /boot/config/plugins/dockerMan) regardless of whether you implement the change to store everything within the system share. That will allow CA to test if that entry in var.ini exists and look at that location instead of being itself hardcoded to look on the flash which will minimize the amount of updates required to CA to remain functional in the future. Yes that's a good idea. This change won't get into 6.3. Hopefully 6.3 only has one or two more -rc's before we promote to stable. This change would prob go into 6.4. Time to slow down the pace guys, I can't keep up with the release's
October 20, 20169 yr Longer term we want to move the docker-related files currently downloaded to the flash (config/plugins/dockerMan) to the system/docker directory. Can I suggest then that starting with RC3 (or whatever the next release is) that say within var.ini you add an entry with the current storage location for those files (right now hardcoded at /boot/config/plugins/dockerMan) regardless of whether you implement the change to store everything within the system share. That will allow CA to test if that entry in var.ini exists and look at that location instead of being itself hardcoded to look on the flash which will minimize the amount of updates required to CA to remain functional in the future. Yes that's a good idea. This change won't get into 6.3. Hopefully 6.3 only has one or two more -rc's before we promote to stable. This change would prob go into 6.4. Time to slow down the pace guys, I can't keep up with the release's Try having to compile the kernel every time to release the DVB stuff....
October 20, 20169 yr Longer term we want to move the docker-related files currently downloaded to the flash (config/plugins/dockerMan) to the system/docker directory. Can I suggest then that starting with RC3 (or whatever the next release is) that say within var.ini you add an entry with the current storage location for those files (right now hardcoded at /boot/config/plugins/dockerMan) regardless of whether you implement the change to store everything within the system share. That will allow CA to test if that entry in var.ini exists and look at that location instead of being itself hardcoded to look on the flash which will minimize the amount of updates required to CA to remain functional in the future. Yes that's a good idea. This change won't get into 6.3. Hopefully 6.3 only has one or two more -rc's before we promote to stable. This change would prob go into 6.4. Time to slow down the pace guys, I can't keep up with the release's Try having to compile the kernel every time to release the DVB stuff.... Or being dmacias who has to continually update the packages for every release for NerdPack... (Why I want the most common and most useful that are used by multiple plugins (inotify tools) to be included in the base OS
October 20, 20169 yr Longer term we want to move the docker-related files currently downloaded to the flash (config/plugins/dockerMan) to the system/docker directory. Can I suggest then that starting with RC3 (or whatever the next release is) that say within var.ini you add an entry with the current storage location for those files (right now hardcoded at /boot/config/plugins/dockerMan) regardless of whether you implement the change to store everything within the system share. That will allow CA to test if that entry in var.ini exists and look at that location instead of being itself hardcoded to look on the flash which will minimize the amount of updates required to CA to remain functional in the future. Yes that's a good idea. This change won't get into 6.3. Hopefully 6.3 only has one or two more -rc's before we promote to stable. This change would prob go into 6.4. Time to slow down the pace guys, I can't keep up with the release's Try having to compile the kernel every time to release the DVB stuff.... I'm sure Tom will consider our good points for the future
October 20, 20169 yr Longer term we want to move the docker-related files currently downloaded to the flash (config/plugins/dockerMan) to the system/docker directory. Can I suggest then that starting with RC3 (or whatever the next release is) that say within var.ini you add an entry with the current storage location for those files (right now hardcoded at /boot/config/plugins/dockerMan) regardless of whether you implement the change to store everything within the system share. That will allow CA to test if that entry in var.ini exists and look at that location instead of being itself hardcoded to look on the flash which will minimize the amount of updates required to CA to remain functional in the future. Yes that's a good idea. This change won't get into 6.3. Hopefully 6.3 only has one or two more -rc's before we promote to stable. This change would prob go into 6.4. Time to slow down the pace guys, I can't keep up with the release's Try having to compile the kernel every time to release the DVB stuff.... I'm sure Tom will consider our good points for the future Probably the best way to approach this is to post a [Feature Request] topic in the Prerelease Support board. If it's something we can do short term we'll leave it there to soak & consider getting it in next -rc release. Something more long term might get moved to the Feature Request board itself. re: inotify specifically: we don't use this currently which is why it's not in stock bzroot build, but this particular package may be a pretty good exception. re: the DVB stuff: We have a precedent for augmenting bzroot with additional functionality (bzroot-gui). We may be able to create something like bzroot-dvb that adds on that additional support. But I've lost track of what all that involves. In any case doesn't hurt to open a topic on the Prerelease board. re: releases. Yes we are trying to end the marathon -rc cycles and generate faster, smaller releases.
October 20, 20169 yr Probably the best way to approach this is to post a [Feature Request] topic in the Prerelease Support board. If it's something we can do short term we'll leave it there to soak & consider getting it in next -rc release. Something more long term might get moved to the Feature Request board itself. re: inotify specifically: we don't use this currently which is why it's not in stock bzroot build, but this particular package may be a pretty good exception. re: the DVB stuff: We have a precedent for augmenting bzroot with additional functionality (bzroot-gui). We may be able to create something like bzroot-dvb that adds on that additional support. But I've lost track of what all that involves. In any case doesn't hurt to open a topic on the Prerelease board. re: releases. Yes we are trying to end the marathon -rc cycles and generate faster, smaller releases. Yeah, it's on my list of things to do, to be honest if you just activate the modules in the kernel for the DVB stuff I'm happy to churn out the builds, I'll see if I can get a diff next time I do one. For what it's worth the newer, faster, smaller releases are appreciated here and I think it's a great thing, makes the whole system more responsive and fluid to some of the rapidly changing aspects of security, docker and KVM. Great to see and, like I say, much appreciated.
October 22, 20169 yr As you know, we have created a few predefined shares: system, appdata, domains, isos. At present the only subdirs under system are: ./docker ./libvirt Longer term we want to move the docker-related files currently downloaded to the flash (config/plugins/dockerMan) to the system/docker directory. We can also create other subdirs there for maintenance purposes; maybe system/tmp could be used for your purposes? Would you be averse to having any plugin create subdirs within the system folder for their own purposes to limit the number of writes to the flash drive? eg: Currently CA stores its datafiles within the docker.img, but when docker isn't enabled, it winds up storing them in RAM instead (which I've never particularly liked, but its better than the flash). And various other projects of mine need to store a number of files which have to survive a reboot, but I didn't want to create a dedicated share for them and can't guarantee the user's environment will have a docker.img created, so currently I'm forced to using the flash drive. Perhaps if you automatically create a plugins subdir within system and then encourage the various authors to utilize it for their persistent data files. EDIT: And if you've got no problems with the above, then to do it right, in my mind you should - Make it truly a "system" share - IE: not a regular share, but automatically hidden from exports - Actually created all the time, not dependant upon docker and vms being enabled - shareUseCache setting undecided about ATM - A dedicated name not user changeable. But if that is a no-go, then a single setting to set the location rather than 2 as there is right now (docker and vm managers), and then those managers default to subfolders within it still with the option to store the files elsewhere outside the system share. -
Archived
This topic is now archived and is closed to further replies.