Question: I have of bash script with a loop watching a directory recursively:

```
while true
do
    if path=`inotifywait -q -r -e create --format %w%f $watchpath`; then
        #modify file
    fi
done

```

If I'm not mistaken this comes with this problem:

If many files are created in that directory or the machine is busy with other tasks, a file could be created before `inotifywait` is reached again - which would mean that it would be ignored.

Is there a way to mitigate that? Perhaps there is way to continuously "watch" and process a stream/feed of modfied files instead?

Answer: 
`User=someuser` in a system service defines a system service that is not started as the root user. A system service will run independently of user logins; it will keep running even if nobody logs in to the system. Running services on dedicated service accounts when possible is good security, but sometimes services need to start as root and will transition to the service account on their own, possibly after doing some initial operations that traditionally require root access, like opening a TCP or UDP port with port number below 1024.

`--user` services are started for logged-in users. The default assumption is that all the user services are stopped when the user that owns them logs out from their last remaining session on the system; however, the system administrator can allow user processes to remain after logout. Some distributions even have it allowed by default, because Unix/Linux systems historically weren't at all strict in reaping user processes at log-out time, and users may have an expectation that they can leave background processes running as they log out without doing anything `systemd`-specific. 

(On the other hand, the administrators of multi-user systems have traditionally had to implement various solutions to clean up left-over old user processes, e.g. when a laptop user doesn't actually log out, but just closes the laptop's lid and walks off with their laptop. `systemd` allows each session's processes to be accurately targeted for termination if needed, but as a result the sysadmin will need to make a policy decision on if and when automatic session clean-up is needed.)

If the same user logs in multiple sessions simultaneously, they will have just one copy of their `--user` services running. So the `--user` services are not really associated with any particular session of the user, just with the user themselves.

Having an `--user` service running as someone other than the logged-in user whose session it belongs to would be useful in very limited cases only, I think. If the service's access needs to be restricted to some shared account only, then I think it would usually be best to make it a system service, so there will be an option to share the access to administer the service (and thus the administration responsibility) to others with access to the shared account, if and when desired.
The question is who systemd instance is running the service and who should execute the commands in it.

You may want a service to start on login on a user `joe`, but the commands themselves are meant to be run by a common account `shared_account`. In that case the service is run from `joe`'s user instance, but the access to the commands could be limited to `shared_account`.

In general, the difference between `--user` and `User=` can be boiled down to who owns the service instance versus which UID runs the commands in a service. If `User=` is not specified, it defaults to the owner of the systemd instance.