Cinnamon boots to black screen with cursor, then restarts in a loop, the logs reference systemd / dbus timeout

I've been running Linux Mint now for ~10 years after earlier forays into Gentoo, Slackware & Arch.  Back when I was a teenager and I didn't have the cash to purchase new hardware and needed to squeeze every inch of performance out of my machines, distributions which gave me fine-grained control of what was running in the kernel & user space not only gave me this last bit of performance, but also taught me a lot about running Linux & GNU in general.

Since moving over to Linux Mint, things have usually "just worked" without the need for me to actively manage my OS.  Unfortunately, computers are computers and sometimes things break.  I don't have to reboot often, though I do like to keep my machine up-to-date.  After keeping my machine up for a month or two, I noticed that suddenly I was experiencing catastrophic failure--the network was working, but Network Manager was not.  I was unable to perform many tasks on the machine, therefore, I rebooted.

The machine appeared to reboot fine, albeit taking ~5 minutes longer than normal, though once I entered into X is when I noticed that lightdm was not coming up--I would see a pointer on a black screen before X cycled into a loop, exiting to a blinking cursor and then back to the black screen with pointer.

Quickly dropping into my terminal & killing lightdm, I began reviewing the lightdm logs to see exactly where the problem lay.  I saw several lines like so:

WARNING: Failed to get list of logind seats: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)

And so:

WARNING: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.freedesktop.Accounts': timed out (service_start_timeout=25000ms)

Thinking possibly that a package broke my system, I proceeded to perform an apt update / apt upgrade, though while running apt I also was seeing the following suspicious error:

Error: Timeout was reached
Reading package lists... Done

Digging into my syslog also showed multiple service start failures, all pointing back to a DBus timeout:

Oct 18 16:13:14 hostname accounts-daemon[1173]: error getting polkit authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.freedesktop.PolicyKit1': timed out (service_start_timeout=25000ms)

Oct 18 16:13:14 hostname udisksd[1164]: Error initializing polkit authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.freedesktop.PolicyKit1': timed out (service_start_timeout=25000ms) (g-dbus-error-quark, 20)

Oct 18 16:13:14 hostname ModemManager[1172]: <warn>  failed to create PolicyKit authority: 'Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.freedesktop.PolicyKit1': timed out (service_start_timeout=25000ms)'

After doing some research I came across some posts regarding the transition away from /var/run/dbus as a standalone folder, and rather a symlink to /run/dbus:

 

• https://bugs.freedesktop.org/show_bug.cgi?id=75515
• https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/811441
• https://forums.gentoo.org/viewtopic-t-1090156-start-0.html 

 

Clearly, there was something wrong with my /var/run configuration--after checking, it appears that some package had replaced /var/run with a real folder--instead of a symlink to /run.

After re-creating the symlink with the following command and rebooting, everything was back to normal 🎉:

ln -s /run /var/run

Note: After writing this blog post, I realized that the root cause of the issue & the solution were clearly documented on the Linux Mint Releases & Announcements form here: https://forums.linuxmint.com/viewtopic.php?t=331605

The npm pack command works fine manually, but refuses to work when utilizing a Gradle wrapper

It's been a while since my lost post and since then I've moved far into the world of JavaScript development (primarily the React/Angular space).  I just came across something I spent entirely too long on, which I definitely want to share in case someone else makes the same mistake I did.

We recently began migrating our NPM pipelines to a Jenkins / Gradle based system.  With the introduction of Gradle, we needed to create an NPM wrapper script which would be able to properly produce our library artifact (via npm pack), via the same steps are our current build system performed, and naturally in the same order.

Knowing this was the case, I went ahead and determined the steps which were currently called so I could test them manually and ensured they also produced the appropriate artifact.  These steps were actually extremely simple & standard for an NPM library:

• npm install
• npm run build
• npm pack
• npm publish artifact-1.0.45.tgz --registry https://our-internal-registry.local/artifactory/api/npm/repo-artifact-npm

Straight forward enough, I went ahead & developed a Gradle script which would call the first three steps in the appropriate order.  Though the plugin has since been deprecated, I was already familiar with the com.moowork.node Gradle plugin.  Knowing I didn't need much to spin up a simple script, I went ahead & developed the following:

apply plugin: "com.moowork.node"

defaultTasks 'artifactNpmPack'

node {
  download = false
}

task build {
  dependsOn("artifactNpmPack")
}

task artifactNpmInstall(type: NpmTask) {
  args = ['install']
}

task artifactNpmBuild(type: NpmTask) {
  args = ['run', 'build']
}

task artifactNpmPack(type: NpmTask) {
  args = ['pack']
}

This script should, when ran as gradle build essentially run the same commands as the manual ones above with no problems.

Unfortunately, I spent the next 12 hours delving into AV issues, file / folder auditing, ProcMon, and finally the NPM pack source code before determining the silly overlooked cause of my issue.  What was my issue, one would ask?  Well, see below (lifted from a Stack Overflow question as it's the exact same issue):

npm ERR! path c:\Temp\npm-20936-b98f84c8\tmp\fromDir-02dd5394\package.tgz
npm ERR! code EPERM
npm ERR! errno -4048
npm ERR! syscall unlink
npm ERR! Error: EPERM: operation not permitted, unlink 'c:\Temp\npm-20936-b98f84c8\tmp\fromDir-02dd5394\package.tgz'
npm ERR!     at Error (native)
npm ERR!  { Error: EPERM: operation not permitted, unlink 'c:\Temp\npm-20936-b98f84c8\tmp\fromDir-02dd5394\package.tgz'
npm ERR!     at Error (native)
npm ERR!   cause:
npm ERR!    { Error: EPERM: operation not permitted, unlink 'c:\Temp\npm-20936-b98f84c8\tmp\fromDir-02dd5394\package.tgz'
npm ERR!        at Error (native)
npm ERR!      errno: -4048,
npm ERR!      code: 'EPERM',
npm ERR!      syscall: 'unlink',
npm ERR!      path: 'c:\\Temp\\npm-20936-b98f84c8\\tmp\\fromDir-02dd5394\\package.tgz' },
npm ERR!   isOperational: true,
npm ERR!   stack: 'Error: EPERM: operation not permitted, unlink \'c:\\Temp\\npm-20936-b98f84c8\\tmp\\fromDir-02dd5394\\package.tgz\'\n    at Error (native)',
npm ERR!   errno: -4048,
npm ERR!   code: 'EPERM',
npm ERR!   syscall: 'unlink',
npm ERR!   path: 'c:\\Temp\\npm-20936-b98f84c8\\tmp\\fromDir-02dd5394\\package.tgz' }
npm ERR!
npm ERR! Please try running this command again as root/Administrator.

Unfortunately, the solutions which worked for others here did not work for me.  After losing my mind for almost 12 hours, I discovered that I was attempting to add the "./gradle/buildOutputCleanup/buildOutputClean.lock" file into the package when running "npm pack" -- this makes sense as I didn't previously have a ".gradle" directory, and somehow it slipped my mind that it must be added to .gitignore.

The solution was simply adding the following to .gitignore, and my build was successful:

# Gradle
# .gradle/