| Summary: | plasma-workspace 93f9ef030 broke my autostart scripts -- repeating the conversion | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Duncan <1i5t5.duncan> |
| Component: | general | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | fuzz, henri, kde, nate, nicolas.fella, plasma-bugs |
| Priority: | NOR | ||
| Version: | master | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Other | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Duncan
2021-05-01 06:35:12 UTC
Did you restart after applying that commit? This happened to me too while testing, but after restarting, everything was all better. This is what users would (presumably, hopefully) do after a system upgrade. (In reply to Nate Graham from comment #1) > Did you restart after applying that commit? Thanks for the review. Yes I restarted. Multiple times in fact. That's how I ended up with 11 copies of each of the scripts (and deleted 10 leaving one) in each of the two dirs (plus the single copy in the old-autostart-scripts backup dir) before I finally figured out what was going on. =:^( If I hadn't restarted multiple times there would have only been the one extra copy, not ten extra copies. Thus the "each time I restart" and "after a few restarts" in the original description. =:^) As for the workaround, setting the dir read-only, with autostart-scripts actually being a symlink to autostart to avoid having two dirs plus the backup with the same content, seems to have been effective. Further restarts haven't produced more copies again. =:^) (I was afraid I was going to have to either set immutable, or worse, add a section to my kde launcher script that deleted the autostart dir and copied it from the backup, like I had to do with konsolerc in a konsole wrapper script for bug #430036 because konsole protests if konsolerc is set readonly or set immutable. But in this case read-only seems to have had the intended effect without further side-effects.) Are you sure you didn't have autostart and autostart-scripts symlinked before ? I don't see how whatever.desktop.desktop.desktop could happen otherwise (autostart should only contain .desktop files, and autostart-scripts, which is the only one looked at by the migration, should only contain scripts). What's more, the migration does attempt to avoid running more than once, by either deleting the autostart-scripts directory if it is empty after the migration, or renaming it to old-autostart-scripts if there are still files inside. Could the renaming have failed on your machine ? perhaps due to a permission issue ? It looks to me like the multiple copies happened as a result of your trying to fix the other issue (with the argv[0] being different since the move to .desktop files) (In reply to hchain from comment #3) > Are you sure you didn't have autostart and autostart-scripts symlinked > before ? Excellent question I'd be asking a reporter as well, but yes, I'm sure they weren't symlinked before as I both knew/used the distinction (preferring symlinks to scripts in the scripts dir to *.desktop files in the non-scripts dir, FWIW), and specifically symlinked the dir *after* the conversion when I noticed it was treating them the same. > I don't see how whatever.desktop.desktop.desktop could happen > otherwise (autostart should only contain .desktop files, and > autostart-scripts, which is the only one looked at by the migration, should > only contain scripts). Well, it happened. There's gotta be something going wrong with the logic, somewhere... > What's more, the migration does attempt to avoid running more than once, by > either deleting the autostart-scripts directory if it is empty after the > migration, or renaming it to old-autostart-scripts if there are still files > inside. > > Could the renaming have failed on your machine ? perhaps due to a permission > issue ? It did do the rename to old-autostart-scripts here. I have that dir with exactly one file for each of the original scripts (and it wasn't there before the conversion). So that part of the script seems to be working. It's gotta be screwing up elsewhere. (In reply to hchain from comment #3) > What's more, the migration does attempt to avoid running more than once, by > either deleting the autostart-scripts directory if it is empty after the > migration, or renaming it to old-autostart-scripts if there are still files > inside. > > Could the renaming have failed on your machine ? perhaps due to a permission > issue ? So I've been looking at the code and trying to figure out what happened, not exactly easy for someone far more comfortable in bash than C++, tho I can sort of read it and even occasionally patch it successfully if I stare at it for long enough... What do I do to turn on the qCInfo/qCDebug output? Because I have a theory or two I'd like to test, and a backup copy of my old autostart and autostart-scripts dirs I can copy back in place to test with. The best theory is a followup on that permissions issue remark. My GUI-user owned both dirs, which had 0750 permissions while the config parent had 0o0700 perms. All files in the autostart-scripts dir were symlinks and the target was obviously readable (perms 0o0740 FWIW) or they'd have not been executing previously. But the symlinks were all root owned.[1] Of course that shouldn't matter unless the dirs are set sticky (they weren't, 0o0750 perms not 0o1750). But if something aborted on root ownership even if it shouldn't matter for symlinks... So I'd like to do a trial run using the files and perms from my backups, with that qCInfo/qCDebug stuff turned on, maybe even adding a couple more debug lines, and see what comes out. But to do that I need to know how to turn it on and where to look for the output... --- [1] I could have sworn that back in the day, kernel 2.4/2.6 kde2/3 era, all my symlinks were root owned. Maybe reiserfs handled them that way or 2.4 in general did?? But I can't seem to find anything to back that up and I've looked, so maybe it was just my being new to *ix back then. In any case current btrfs lets non-root own symlinks. But I remember stopping short when I first noticed them and wondering what had changed. Do you happen to have a reproducible way to trigger this? Because we can't find any fault in the logic, and if you can't make it happen again, it's unlikely this will be debuggable. :( Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |