In the previous post: "Blog Automation Struggles: From launchd Errors to SEO]," I finally traced the elusive launchd error that had eluded me previously. Alongside this, I also addressed the locked Instagram account and prepared for AdSense integration.
Verification from HANDOFF: Automatic posting failed again yesterday
Continuing the session, I first reviewed HANDOFF.md. Having tentatively concluded that the previous session's issue stemmed from a "BTM (Background Task Management) approval delay race condition," this hypothesis emerged from observations: failures shortly after registering a new label, transitioning to successes over time.
Address overdue tasks: Boost KOSPI activity, organize posts.
Apart from launchd issues, I tackled pending tasks first. Verified that the KOSPI API key on the Public Data Portal was activated, and cleaned up 11 problematic inline style posts created by copying AI research tools, reducing file sizes significantly—one down from 781KB to 32KB. This process went smoothly.
Next Session: The BTM Hypothesis Is Incorrect
The following day, upon checking the launchd status in response to the request "Please verify the execution results at 07:00," the attempt failed again, yielding an exit code of 78. Despite being twenty hours past BTMs fully stabilizing, this persistent failure indicated that yesterday's hypothesis was fundamentally incorrect.
The Real Culprit: TCC was blocking the Desktop folder.
A search for the keyword "Sandbox" within integrated logs revealed this line in the kernel log: kernel: (Sandbox) System Policy: xpcproxy(pid) deny(1) file-read-data /Users/.../Desktop/blogger-automation/logs/pipeline.out.log. macOS TCC treats the Desktop folder with enhanced protection, resulting in a LaunchAgent attempting to access a log file within it being permanently denied, despite four failed attempts (two automated runs, two manual executions). This single line encapsulated all instances, irrespective of label names, code signatures, or power management settings.
Migrating the project outside of Desktop
The most reliable solution was to migrate the entire project. I relocated the Desktop subdirectory directly under the home folder and recreated the Python virtual environment due to hardcoded absolute paths in the launchd configuration files and within the codebase. I updated and re-registered all path references in these files and the code, then conducted a temporary test run using only `echo` commands to validate without actual deployment, which successfully terminated normally.
The next morning, finally successful
True verification came the following morning. All four blog posts successfully published with an exit code of 0; the persistent issue was finally resolved.
Instagram was also blocked.
However, during the same execution, posting Instagram card news failed in both Korean and English with a "API access blocked" error message. Direct API calls confirmed that the issue wasn't due to code or token problems. Logging into the developer console triggered a suspicious activity alert. Given the consistent timing and pattern of API calls every day, the automated process likely appeared as a bot to the security system. After reinstating the account through self-verification and retrying, normal responses were restored.
Setting Up AdSense: Creating a Personal Information Processing Policy
While organizing the AdSense review process, I noticed that there were zero static pages on the English blog. Without a privacy policy, reviews effectively result in automatic rejection. I drafted both Korean and English versions as placeholders and added a link at the theme footer. However, actual applications will be postponed until more posts are published.
Trouble Shooting
| Symptoms | Cause | Solution method |
|---|---|---|
| Launchd failed to execute continuously past 7 AM due to errors. | macOS TCC permanently denies access to Desktop subdirectory logs (LaunchAgent cannot display approval prompts) | Move project outside Desktop, recreate virtual environment, re-register launchd settings |
| Possible execution errors after moving to a virtual environment | The previous absolute path is embedded within the executable file. | Delete the virtual environment after relocation and recreate it. |
| Instagram API access blocked returned | Security system flags repetitive automated call patterns as suspicious activity, locking the account daily. | Account recovery confirmed via self-authentication; API rechecked for normalization. |
| No static pages found during AdSense review preparation | No personal information processing policy page created since blog establishment. | Create English draft after Korean draft, add link at theme bottom. |
Reflections / Next Steps
I revisited the lesson that even identical errors can stem from entirely different causes with slight variations in replication conditions. Although yesterday’s hypothesis seemed plausible, had natural execution failed again the following day, it would have remained a misguided conclusion. Delving into kernel logs proved decisive. Moving forward, I plan to expand the posting schedule to three times daily once the target number of posts is reached, subsequently proceeding with the AdSense application.
Comments
Post a Comment