4 ms·

> Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the

> Maybe you have a headless linux box that you want to set some command-line music player playing on, why should you need to keep the terminal open to keep the music playing? If that behavior is desired, then it would make more sense to have the music player be a system service rather than a user service, in my opinion. As a non-user of nohup, it seems like a bizarre way to achieve the desired permanence. I guess maybe it was originally conceived as a way to run a long command from a terminal, but then effectively 'log out' of the terminal to prevent anyone else with physical access from running a command as you? Under graphical environments, this is solved via "locking" the computer. Under non-graphical environments, I would personally find something functionally equivalent to `my_command && exit` (but in a way that doesn't allow other people to ctrl+c and then steal your session) more intuitive - i.e. run the command and then log off, rather than "log off, but keep this command running". Or maybe I'm misunderstanding why things like `nohup` exist? In any case, I can agree that making significant breaking changes in this way is pretty irresponsible. But I'm still not sure it violates the rule of least surprise.

ams6110 10y ago
nohup dates way back, most unix computers were not owned by a single person but were used by dozens if not hundreds of users. People had needs to run jobs (even compiles could take hours) that they would not want terminated if their dial-up connection dropped (common occurrence). Among other reasons.
- kevin_nisbet 10y ago
  Agreed, at work we use nohup / screen for many important tasks. These tasks are items like doing an upgrade, or migration, or a long running script that you want to protect from a dropped ssh connection. Networks are unreliable, your local system may be unreliable, and the last thing we want to happen is for a script or program to die while making changes to the system that leave it in an inconsistent state. In my limited understanding, nohup was a very simple mechanism to achieve this. So to me, when you logoff or drop a connection, the system will send a HUP to all the processes in the tree belonging to that session. If the process doesn't accept the HUP, well then it doesn't want to die right now, which is what nohup allowed you to do by intercepting / wrapping the HUP. I assume screen worked on a similar principle and just ignores the HUP since it knows you may want to re-attach later. Now it sounds like they are working on or have another way to achieve the same result in SystemD, I'm just very curious what the thoughts or reasoning is that this should be a thing. Anyways, all I can say is that to me, changing this behaviour if I didn't see the release notes or this bug, would cause some very unexpected behaviour for me interacting with a SystemD system, where some of the basic mechanisms I use and encourage for change safety would no longer work. I suspect many others also use screen/nohup, and will be in for a big surprise.
digi_owl 10y ago
Err unless i am totally off target, unix do not have anything like "system". The closest you will get is something running as the root user. And doing everything as root is bad juju, as we can see from the DOS legacy that plagues Windows to this day.
- wallacoloo 10y ago
  By "system service", I meant analogous to everything under /etc/systemd/system - it should be operated the same way things like networking and printers, etc are handled. I actually have some services (like Transmission) in /etc/systemd/system that are run on boot as arbitrary users, and they're completely detached from any user sessions (i.e. logging off will never kill them). It seems comparable to logging in, running `nohup transmission` and logging out, but without the weird "he logged out - how are his processes still running?" confusion.
  - digi_owl 10y ago
    There is no confusion unless one is clueness about unix.
    - wallacoloo 10y ago
      I didn't come here to be insulted.
      - digi_owl 10y ago
        Ok, sorry. I just find the whole session thinking an ill fit for unix, outside of a shorthand for a login process and the shell child process it has spawned. Anything beyond that is just another process.
  - khedoros 10y ago
    What, exactly, is confusing about it? It's just how it works, and there are good reasons for it. Screen allows you to do some cool things like keep your session running when you log off, so that you can log back in later and pick up where you left off. Something like a daemon is basically meant to run in the background and never be directly interacted with. It's a different thing to tell a process "hold on; I'll be back later". As an example: I've got some SBCs that are on all the time. It's useful to be able to pop on, pick up where I left off from, do some experiments, then log out, without having to set my environment back up every time I do it. There isn't really a better way to achieve the same goal.

ams6110 10y ago

nohup dates way back, most unix computers were not owned by a single person but were used by dozens if not hundreds of users. People had needs to run jobs (even compiles could take hours) that they would not want terminated if their dial-up connection dropped (common occurrence). Among other reasons.

kevin_nisbet 10y ago
Agreed, at work we use nohup / screen for many important tasks. These tasks are items like doing an upgrade, or migration, or a long running script that you want to protect from a dropped ssh connection. Networks are unreliable, your local system may be unreliable, and the last thing we want to happen is for a script or program to die while making changes to the system that leave it in an inconsistent state. In my limited understanding, nohup was a very simple mechanism to achieve this. So to me, when you logoff or drop a connection, the system will send a HUP to all the processes in the tree belonging to that session. If the process doesn't accept the HUP, well then it doesn't want to die right now, which is what nohup allowed you to do by intercepting / wrapping the HUP. I assume screen worked on a similar principle and just ignores the HUP since it knows you may want to re-attach later. Now it sounds like they are working on or have another way to achieve the same result in SystemD, I'm just very curious what the thoughts or reasoning is that this should be a thing. Anyways, all I can say is that to me, changing this behaviour if I didn't see the release notes or this bug, would cause some very unexpected behaviour for me interacting with a SystemD system, where some of the basic mechanisms I use and encourage for change safety would no longer work. I suspect many others also use screen/nohup, and will be in for a big surprise.

digi_owl 10y ago

Err unless i am totally off target, unix do not have anything like "system". The closest you will get is something running as the root user. And doing everything as root is bad juju, as we can see from the DOS legacy that plagues Windows to this day.

wallacoloo 10y ago
By "system service", I meant analogous to everything under /etc/systemd/system - it should be operated the same way things like networking and printers, etc are handled. I actually have some services (like Transmission) in /etc/systemd/system that are run on boot as arbitrary users, and they're completely detached from any user sessions (i.e. logging off will never kill them). It seems comparable to logging in, running `nohup transmission` and logging out, but without the weird "he logged out - how are his processes still running?" confusion.
- digi_owl 10y ago
  There is no confusion unless one is clueness about unix.
  - wallacoloo 10y ago
    I didn't come here to be insulted.
    - digi_owl 10y ago
      Ok, sorry. I just find the whole session thinking an ill fit for unix, outside of a shorthand for a login process and the shell child process it has spawned. Anything beyond that is just another process.
- khedoros 10y ago
  What, exactly, is confusing about it? It's just how it works, and there are good reasons for it. Screen allows you to do some cool things like keep your session running when you log off, so that you can log back in later and pick up where you left off. Something like a daemon is basically meant to run in the background and never be directly interacted with. It's a different thing to tell a process "hold on; I'll be back later". As an example: I've got some SBCs that are on all the time. It's useful to be able to pop on, pick up where I left off from, do some experiments, then log out, without having to set my environment back up every time I do it. There isn't really a better way to achieve the same goal.