1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER

  • Systemctl masked/disabled/etc

    From Alex Wahl@21:1/5 to All on Sun Dec 22 07:40:02 2024
    --d85250176eb34784b39749965490255c
    Content-Type: text/plain
    Content-Transfer-Encoding: 7bit

    Is there any point to worrying about what's masked and disabled if I don't have a specific technical reason? The reason I asked it really just because I'm wondering if I accidentally set a unit to that in the past I shouldn't have; I don't really know
    what a "normal" system looks like
    --d85250176eb34784b39749965490255c
    Content-Type: text/html
    Content-Transfer-Encoding: 7bit

    <!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Is there any point to worrying about what's masked and disabled if I don't have a specific technical reason? The reason I asked
    it really just because I'm wondering if I accidentally set a unit to that in the past I shouldn't have; I don't really know what a "normal" system looks like<br></div></body></html>
    --d85250176eb34784b39749965490255c--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From john doe@21:1/5 to Alex Wahl on Sun Dec 22 11:20:01 2024
    On 12/22/24 07:16, Alex Wahl wrote:
    Is there any point to worrying about what's masked and disabled if I don't have a specific technical reason? The reason I asked > it really just because I'm wondering if I accidentally set a unit to that in the past I shouldn't have; I don't really
    know what > a "normal" system looks like

    If a service is disabled or masked, this means that the service will not
    be processed by Systemd when the computer boots up.

    --
    John Doe

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to Alex Wahl on Sun Dec 22 14:40:01 2024
    On Sun, Dec 22, 2024 at 01:16:31 -0500, Alex Wahl wrote:
    Is there any point to worrying about what's masked and disabled if I don't have a specific technical reason? The reason I asked it really just because I'm wondering if I accidentally set a unit to that in the past I shouldn't have; I don't really know
    what a "normal" system looks like

    A service that's masked can NEVER be activated, by anything, unless
    it's unmasked first.

    A service that's disabled won't be started automatically, but it
    could be activated by a different service. Or started manually.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pocket@homemail.com@21:1/5 to All on Tue Dec 24 14:10:01 2024
    Sent: Tuesday, December 24, 2024 at 7:39 AM
    From: "Oliver Schode" <oliver.schode@online.de>
    To: debian-user@lists.debian.org
    Subject: Re: Systemctl masked/disabled/etc

    Hi,

    looks like I'm the only one yet as I take it, he wasn't asking about
    meanings of, or differences between states but rather worries about
    defaults he may have inadvertently changed. This is about what is
    essential or required for system operation.

    Is there any point to worrying about what's masked and disabled if I
    don't have a specific technical reason?

    I don't think so, or at least I never had to think about it in all
    those years with systemd. Anything essential or important that's
    missing or failing you'd notice before long, but then you'll have your technical reason. Of course, if you've touched your system to the point
    where you're unsure how to get back, it's easy enough to
    reset/reinstall affected packages but usually than shouldn't be
    necessary.

    The reason I asked it really
    just because I'm wondering if I accidentally set a unit to that in
    the past I shouldn't have; I don't really know what a "normal" system
    looks like

    A "normal" system obviously can look all kinds of things. Maybe you
    really meant vanilla or out-of-the-box and as far as I'm concerned when
    it comes to masking it doesn't look much different from what I have
    now. And either of,

    `systemctl list-units --state=masked` (to see what's loaded+masked)
    or
    `systemctl lits-unit-files --state=masked` (everything installed+masked)

    wouldn't print an overly long list. And those (few) I masked myself
    only show for loaded. You can naturally try this with state=disabled as
    well, in that case it's slightly more interesting to compare current
    and preset values.



    Masked units don't hurt a thing, that is if you known what your doing and know why you want or need to mask certain units.

    Now under debian I remove the services/packages, for example I remove everything/all "debian networking" and then setup networking in a sane and workable way. The "debian way" will just cause all kind of grief, which is not necessary and that is why I
    remove it.

    systemctl list-units --state=masked
    UNIT LOAD ACTIVE SUB DESCRIPTION
    ● rpcbind.service masked inactive dead rpcbind.service
    ● rpcbind.socket masked inactive dead rpcbind.socket

    Legend: LOAD → Reflects whether the unit definition was properly loaded.
    ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
    SUB → The low-level unit activation state, values depend on unit type.

    2 loaded units listed.
    [alarm@alarm ~]$

    I am using NFS and don't want or need NFS V3 as I only wand NFS V4.

    [alarm@alarm ~]$ sudo exportfs
    /srv 192.168.50.0/24

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Oliver Schode@21:1/5 to All on Tue Dec 24 13:50:01 2024
    Hi,

    looks like I'm the only one yet as I take it, he wasn't asking about
    meanings of, or differences between states but rather worries about
    defaults he may have inadvertently changed. This is about what is
    essential or required for system operation.

    Is there any point to worrying about what's masked and disabled if I
    don't have a specific technical reason?

    I don't think so, or at least I never had to think about it in all
    those years with systemd. Anything essential or important that's
    missing or failing you'd notice before long, but then you'll have your technical reason. Of course, if you've touched your system to the point
    where you're unsure how to get back, it's easy enough to
    reset/reinstall affected packages but usually than shouldn't be
    necessary.

    The reason I asked it really
    just because I'm wondering if I accidentally set a unit to that in
    the past I shouldn't have; I don't really know what a "normal" system
    looks like

    A "normal" system obviously can look all kinds of things. Maybe you
    really meant vanilla or out-of-the-box and as far as I'm concerned when
    it comes to masking it doesn't look much different from what I have
    now. And either of,

    `systemctl list-units --state=masked` (to see what's loaded+masked)
    or
    `systemctl lits-unit-files --state=masked` (everything installed+masked)

    wouldn't print an overly long list. And those (few) I masked myself
    only show for loaded. You can naturally try this with state=disabled as
    well, in that case it's slightly more interesting to compare current
    and preset values.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Wright@21:1/5 to Alex Wahl on Fri Dec 27 17:20:01 2024
    On Sun 22 Dec 2024 at 01:16:31 (-0500), Alex Wahl wrote:
    Is there any point to worrying about what's masked and disabled
    if I don't have a specific technical reason? The reason I asked
    it really just because I'm wondering if I accidentally set a unit
    to that in the past I shouldn't have; I don't really know what
    a "normal" system looks like

    Typically, a vanilla system will have very few files in /etc/systemd/
    that aren't just symlinks to files in /lib/systemd or /usr/lib/systemd.

    $ ls -AlFR /etc/systemd/ | grep 'null'

    will search for things that are masked, and the timestamp will tell
    you when the change was made. (Some could date back to installation.)

    $ ls -AlFR /etc/systemd/ | grep '^\-'

    will search for ordinary files that you might have written yourself
    to override systemd's default behaviour. However, there are some
    systemd-owned .conf files (typically listed first) that show the
    default values for parameters, that is if you haven't modified them.
    Again, the timestamps may jog your memory.

    $ systemctl list-unit-files --state=disabled

    Because disabling services removes files, you may need this command
    to give you an overview of disabled services etc. But there could be
    many that normally show as such, so you'll need to check with:

    $ systemctl status whatever.service/timer/socket/whichever

    Cheers,
    David.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From eben@gmx.us@21:1/5 to David Wright on Fri Dec 27 17:30:01 2024
    On 12/27/24 11:18, David Wright wrote:
    On Sun 22 Dec 2024 at 01:16:31 (-0500), Alex Wahl wrote:
    Is there any point to worrying about what's masked and disabled
    if I don't have a specific technical reason? The reason I asked
    it really just because I'm wondering if I accidentally set a unit
    to that in the past I shouldn't have; I don't really know what
    a "normal" system looks like

    Typically, a vanilla system will have very few files in /etc/systemd/
    that aren't just symlinks to files in /lib/systemd or /usr/lib/systemd.

    Hmm. Maybe that applies to certain versions? I don't think I've touched
    that directory.

    eben@cerberus:~$ ls -l /etc/systemd/
    total 44K
    4.0K -rw-r--r-- 1 root root 1.3K Sep 20 2023 journald.conf
    4.0K -rw-r--r-- 1 root root 1.6K Sep 20 2023 logind.conf
    4.0K drwxr-xr-x 2 root root 4.0K Sep 20 2023 network/
    4.0K -rw-r--r-- 1 root root 846 Sep 20 2023 networkd.conf
    4.0K -rw-r--r-- 1 root root 670 Sep 20 2023 pstore.conf
    4.0K -rw-r--r-- 1 root root 953 Sep 20 2023 sleep.conf
    4.0K drwxr-xr-x 11 root root 4.0K Sep 11 11:40 system/
    4.0K -rw-r--r-- 1 root root 2.1K Sep 20 2023 system.conf
    4.0K -rw-r--r-- 1 root root 864 Sep 20 2023 timesyncd.conf
    4.0K drwxr-xr-x 5 root root 4.0K Mar 13 2024 user/
    4.0K -rw-r--r-- 1 root root 1.4K Sep 20 2023 user.conf

    eben@cerberus:~$ cat /etc/debian_version
    12.8

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Wright@21:1/5 to eben on Fri Dec 27 18:30:02 2024
    On Fri 27 Dec 2024 at 11:27:18 (-0500), eben wrote:
    On 12/27/24 11:18, David Wright wrote:
    On Sun 22 Dec 2024 at 01:16:31 (-0500), Alex Wahl wrote:
    Is there any point to worrying about what's masked and disabled
    if I don't have a specific technical reason? The reason I asked
    it really just because I'm wondering if I accidentally set a unit
    to that in the past I shouldn't have; I don't really know what
    a "normal" system looks like

    Typically, a vanilla system will have very few files in /etc/systemd/
    that aren't just symlinks to files in /lib/systemd or /usr/lib/systemd.

    Hmm. Maybe that applies to certain versions? I don't think I've touched that directory.

    Sorry, but did you only read the first two lines of my post?

    You snipped all the examples I gave and their explanations,
    viz:

    $ ls -AlFR /etc/systemd/ | grep 'null'
    [ … … ]
    $ ls -AlFR /etc/systemd/ | grep '^\-'
    [ … … ]
    $ systemctl list-unit-files --state=disabled
    [ … … ]
    $ systemctl status whatever.service/timer/socket/whichever
    [ … … ]

    Those listings will include everything underneath, corresponding with
    the trees in /lib/systemd/, /run/systemd/, /usr/local/lib/systemd/,
    and so on.

    []~$ ls -l /etc/systemd/
    total 44K
    4.0K -rw-r--r-- 1 root root 1.3K Sep 20 2023 journald.conf
    4.0K -rw-r--r-- 1 root root 1.6K Sep 20 2023 logind.conf

    4.0K -rw-r--r-- 1 root root 846 Sep 20 2023 networkd.conf
    4.0K -rw-r--r-- 1 root root 670 Sep 20 2023 pstore.conf
    4.0K -rw-r--r-- 1 root root 953 Sep 20 2023 sleep.conf

    4.0K -rw-r--r-- 1 root root 2.1K Sep 20 2023 system.conf
    4.0K -rw-r--r-- 1 root root 864 Sep 20 2023 timesyncd.conf

    4.0K -rw-r--r-- 1 root root 1.4K Sep 20 2023 user.conf

    Yes, those are the ones I mentioned: “systemd-owned .conf files
    (typically listed first) that show the default values for parameters,
    that is if you haven't modified them”, which you appear
    not to have done.

    BTW is your ls command aliased?

    Cheers,
    David.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From eben@gmx.us@21:1/5 to David Wright on Fri Dec 27 19:20:02 2024
    On 12/27/24 12:21, David Wright wrote:
    On Fri 27 Dec 2024 at 11:27:18 (-0500), eben wrote:
    On 12/27/24 11:18, David Wright wrote:
    On Sun 22 Dec 2024 at 01:16:31 (-0500), Alex Wahl wrote:
    Is there any point to worrying about what's masked and disabled
    if I don't have a specific technical reason? The reason I asked
    it really just because I'm wondering if I accidentally set a unit
    to that in the past I shouldn't have; I don't really know what
    a "normal" system looks like

    Typically, a vanilla system will have very few files in /etc/systemd/
    that aren't just symlinks to files in /lib/systemd or /usr/lib/systemd.

    Hmm. Maybe that applies to certain versions? I don't think I've touched
    that directory.

    Sorry, but did you only read the first two lines of my post?

    You snipped all the examples I gave and their explanations,

    Sorry. Carry on.

    BTW is your ls command aliased?

    Yes.

    eben@cerberus:~$ type ls
    ls is aliased to `ls -shF --color=auto'

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)