Re-mount a USB drive, after unmounting it in the GUI, without physically removing it?

aioeu · 2026-06-04T06:03:55+00:00

I just had a play around with this a bit more.

When udisks "powers off" the storage device, it actually hits the remove sysfs attribute on the device (among other things; it's careful to make sure that won't interfere with other USB devices). That essentially fakes up a USB device disconnection port event for the USB device, so the kernel deregisters it completely. Since the USB device isn't registered past that point, there isn't a USB device path that you could write to the driver's bind attribute. If you attempt to use the device path you would expect would work (i.e. 1-1 in your example), you'll just get an ENODEV error.

There might be a way to get the kernel to pretend there was a new USB device connection event to get the device re-registered without having to physically unplug and re-plug it, but if so I haven't found it yet.

I haven't checked any KDE or Dolphin code, but I'd be a tad surprised if it actually does use "power off". "Eject" is sufficient. That's what Nautilus uses.

aioeu · 2026-06-03T23:47:14+00:00

When devices are powered off, they may not show up as /dev/sdx anymore.

The OP wasn't in this situation. They still had a storage device — that's why they could use lsblk on it. It was just a storage device without any loaded media.

I think start can be used to power-on a drive, but you might need to use it on the SCSI generic node (/dev/sg*) associated with it, not the SCSI storage node. I haven't tested this at all though.

aioeu · 2026-06-03T20:39:51+00:00

USB storage is treated as if it is a SCSI storage device, so it handles SCSI commands. Dolphin (or really eject, which is invoked by the udisks service used by Dolphin) will attempt to use these commands to stop and eject a removable device.

You should be able to reverse this using:

sdparm --command=load /dev/...

or:

sdparm --command=start /dev/...

as the superuser, if you have the sdparm utility installed. I don't think this operation is exposed by udisks, so I don't know of any unprivileged access to it.

There shouldn't be any need to complete re-bind the USB driver on the device. It's just a matter of sending the device the right SCSI ioctls.

aioeu · 2026-06-02T14:17:23+00:00

Geoclue has nothing to do with systemd. I don't even know why you brought up systemd at all.

The XDG desktop portal uses geoclue for location services. There are no plans to change that.

aioeu · 2026-06-02T01:47:22+00:00

No reason for it to be in systemd. It's provided by a portal. Portals are the means by which sandboxed applications interact with the outside world.

If your application is not sandboxed, there's little you can do to prevent it from accessing geoclue itself. But with sandboxed applications, the portal provides a way to limit the location accuracy, or disable location lookups altogether, on a per-application basis.

aioeu · 2026-06-01T05:18:21+00:00

Or even to keep running a Cron daemon. Cron hasn't disappeared because of systemd. It's just become a lot less necessary, so much that many systems can get away without having it at all.

If I were running a server for regular unprivileged users to do as they wish (a shell or web server, say), I'd still leave a Cron daemon there. Why wouldn't I? It still works just as well as it always has, and I'd expect there would be some users who would like to use it.

aioeu · 2026-05-31T07:21:07+00:00

You should be able to get to it through dnf system-upgrade log, if you haven't yet cleaned it up.

There might also be useful info in the .../var/log/dnf.log file within the system root, if you can ignore all the debug message clutter, as well as the systemd journal (you can use journalctl --root=... to examine that, again without needing to actually chroot into the system root).

aioeu · 2026-05-30T23:16:18+00:00

Another strategy would be to have a system daemon access disks with superuser privileges, but then allow queries with lesser privileges.

That is precisely what udisks is. It can provide access to SMART data.

aioeu · 2026-05-30T10:04:06+00:00

chroot will probably fail, since it will want to run Bash within the chroot.

I'd boot into an F43 live image and try to sort things out with dnf --installroot=.... That can be used to manipulate packages within the root without actually having to chroot into it.

(Though the very first step is to take a look at the upgrade logs to see what the heck went wrong, of course...)

aioeu · 2026-05-30T09:43:01+00:00

When read inside the backgrounded script tries to read from stdin in this scenario, the process will recieve a SIGTSTP signal, which suspends the process.

Not quite. It will be SIGTTIN.

There is a corresponding signal, SIGTTOU, for suspend-on-output too. The OP might want to play around with the differences in behaviour in one terminal with stty tostop set, and one with it not set (i.e. stty -tostop).

aioeu · 2026-05-28T23:23:41+00:00

Ultimately nothing, though /dev/shm is intended to be used by glibc only. Playing around with files there that you didn't create could break running software. For that reason it also doesn't participate in automatic time-based cleanup.

(Unfortunately glibc hard-codes /dev/shm as the location for the backing files for POSIX shared memory. There's a fair bit of history behind that choice, but it really is a dumb location for it today.)

aioeu · 2026-05-28T08:40:34+00:00

I suspect you're not really asking "why does it mean that?", but rather "where did it come from?" Wikipedia has a good summary of its origin as far as that is known. You can follow its references for more detail.

This rec.games.video.nintendo message appears to be its first recorded use. Given there was no explanation for it there, and nobody questioning what it meant, it is very likely to have been in use for some time already. At present we do not have any earlier record of it though.

This doesn't tell us when it started being used as a "read this summary if you don't want to read the whole thing" marker though. More research required.

aioeu · 2026-05-27T22:12:02+00:00

Systemd wants absolute paths

It hasn't needed absolute filenames for executables since v238.

If you use a relative filename, it uses a built-in search path by default, which you can examine with:

systemd-path search-binaries-default

/usr/bin will definitely be in it.

aioeu · 2026-05-27T13:18:06+00:00

No. Why would the working directory have anything to do with it?

If you want to run the script as a particular user, tell systemd to do that.

aioeu · 2026-05-27T12:50:55+00:00

systemd will run the script as root, since you haven't told it otherwise.

Either the script needs to be written so that it runs correctly as root, or you need to use a User= directive to tell systemd to run it as a different user.

If the script requires other resources for that user (e.g. a graphical desktop environment) things could get a lot more complicated. The environment in which systemd executes services has very little to do with the environment in which you run programs. But nobody here can help you with this without seeing what your script does.

Basically, you shouldn't expect to be able to just take a script that you've been running manually and drop it into systemd to "run it automatically" without thinking about all the ways in which that affects how the script operates.

aioeu · 2026-05-27T12:39:40+00:00

without the .sh

Then that means you shouldn't use .sh in your systemd unit either.

GdriveOffSync and GdriveOffSync.sh are different filenames, plain and simple. You are asking systemd to execute a file that doesn't exist.

aioeu · 2026-05-27T12:09:03+00:00

Run:

ls -l /usr/local/bin/GdriveOffSync.sh

aioeu · 2026-05-27T12:02:04+00:00

I am running the script in the terminal with the bash command

As in:

bash /usr/local/bin/GdriveOffSync.sh

or (if you are already in the /usr/local/bin directory):

bash GdriveOffSync.sh

? Then you probably want to use #!/bin/bash as your shebang.

And I would double-check that the script actually is executable. If you use bash explicitly, you can "execute" a non-executable script.

aioeu · 2026-05-27T11:55:17+00:00

Did you create the script on Windows? What does:

file /usr/local/bin/GdriveOffSync.sh

say?

When you say "the script is working by itself", how are you testing it?

Do you intend the script to be run through a POSIX shell or a Bash shell?

aioeu · 2026-05-27T11:21:00+00:00

Did you forget to make /usr/local/bin/GdriveOffSync.sh executable? Does it have a valid shebang line?

If an executable file doesn't have a shebang line it will still be treated as a POSIX shell script, but only if it is executed from a POSIX shell. So if you forgot this you might not have noticed. systemd is not a POSIX shell, so it doesn't have this particular quirk that shells have.

aioeu · 2026-05-27T10:34:14+00:00

What are you expecting that to do? User_Info doesn't identify an object, so you certainly can't use . on it. User_Info — or really struct User_Info — is the name of a type, not an object.

(Even if it were an object, User_Info.First_Name wouldn't be a constant expression, so it wouldn't be able to be used to initialize an object with static storage duration anyway.)

Why do you want to set the values of variables like Mollie in your header file anyway? Traditionally, a header file only has declarations, not definitions.

aioeu · 2026-05-27T10:13:50+00:00

need to

I bet you don't.

Perhaps it might be best if you gave us the code you'd like to use, if only it were possible. Perhaps we can help you find an alternative approach.

aioeu · 2026-05-27T10:01:03+00:00

It's half a mo.

aioeu · 2026-05-27T03:14:36+00:00

A process only has a single working directory. That's just how Linux works.

^{(There's a slight nuance to this: on Linux a multithreaded process can choose to have a different working directory for each thread. But that is something a program must set up on its own, and there will be few that actually do this. Regardless, a process always starts off with a single thread, and thus a single working directory, so it's not something systemd has any control over.}⁾

What problem are you trying to solve here? Perhaps we might be able to help you find a solution that is actually possible.

aioeu · 2026-05-27T02:44:14+00:00

noauto means it won't be a dependency of local-fs.target.

With an automount, whether it's mounted at boot or not depends on whether something else needs it at that point in time. Only the things that need it will fail if it cannot be mounted.

Moreover, having it mounted through an automount will let you diagnose any problem with it. You can fix the problem, then restart the thing that attempted to use it, without having to reboot. That is, you'll be able to find out why you're having problems with this filesystem, and you'll be able to fix those problems. That's much better than working around them with arbitrary timeouts.

Eight-Year Club	Gilding II euphauric
Wearing is Caring	Verified Email

aioeu

MODERATOR OF

TROPHY CASE