The officially official Devuan Forum!

Altoid

Member

Registered: 2017-05-07

Posts: 1,592  

Services start issue

Hello:

I run an up-to-date Devian ASCII:

groucho@devuan:~$ uname -ap
Linux devuan 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux
groucho@devuan:~$ 
groucho@devuan:~$ su

There seems to be a problem with the starting of (some?) services.

I ticked them in Applications -> System -> Services = [service], a pop-up for systemtoolsbackends.set asks me to authenticate and I type my root PW in.
Then I click Close but for some reason they won't start.

The services are checkroot-bootclean.sh, smartmontools and sudo.

So I try to start them from a TTY (just two for brevity's sake)

1. Check they are not already running:

[root@devuan groucho]# service --status-all | grep sudo
 [ ? ]  alsa-utils
 [ ? ]  cryptdisks
 [ ? ]  cryptdisks-early
 [ ? ]  hwclock.sh
 [ ? ]  kmod
 [ ? ]  networking
 [ - ]  sudo
[root@devuan groucho]# service --status-all | grep smartmontools
 [ ? ]  alsa-utils
 [ ? ]  cryptdisks
 [ ? ]  cryptdisks-early
 [ ? ]  hwclock.sh
 [ ? ]  kmod
 [ ? ]  networking
 [ - ]  smartmontools
[root@devuan groucho]#

2. Start them as root:

[root@devuan groucho]# service sudo start
[root@devuan groucho]# service smartmontools start

3. Check if they have started:

[root@devuan groucho]# service --status-all | grep sudo
 [ ? ]  alsa-utils
 [ ? ]  cryptdisks
 [ ? ]  cryptdisks-early
 [ ? ]  hwclock.sh
 [ ? ]  kmod
 [ ? ]  networking
 [ - ]  sudo
[root@devuan groucho]# service --status-all | grep smartmontools
 [ ? ]  alsa-utils
 [ ? ]  cryptdisks
 [ ? ]  cryptdisks-early
 [ ? ]  hwclock.sh
 [ ? ]  kmod
 [ ? ]  networking
 [ - ]  smartmontools
[root@devuan groucho]# 

This is a thread split from another one with a similar (?) issue here: https://dev1galaxy.org/viewtopic.php?id=2337.

My installation uses su to get root and my user is included in the sudo group.

[root@devuan groucho]# cat /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults	env_reset
Defaults	mail_badpass
Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root	ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d
[root@devuan groucho]# 

groucho@devuan:~$ groups
groucho adm dialout cdrom floppy tape sudo audio dip video plugdev netdev lpadmin scanner
groucho@devuan:~$ 

I can sudo shutdown, sudo reboot, etc. as permitted by /etc/sudoers.d/user_shutdown.   

[root@devuan groucho]# cat /etc/sudoers.d/user_shutdown
groucho ALL= NOPASSWD: /usr/sbin/pm-suspend, /usr/sbin/pm-hibernate, /sbin/halt, /sbin/reboot
[root@devuan groucho]# 

Any idea as to what is happening with services.?

Thanks in advance,

A.

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,501  

Re: Services start issue

Looking at /etc/init.d/sudo, it looks like all that script does is change the time stamp on /var/lib/sudo. The only command it takes is 'start'. All the others (stop|restart|whatever) do nothing. Anything else gives you the standard error message for init scripts that says you should use start|stop|restart...

If your user is in the sudo group, you should be able to use sudo with your password for all commands. Try something safe like sudo blkid to see if that works. What I don't understand is why user_shutdown works when the includedir directive in /etc/sudoers is commented out. It's commented out in mine, too, but I can shutdown using sudo without password. I'm also getting the same results as you for 'service --status-all' - it doesn't change when I try to start sudo. Maybe that's because sudo runs and then exits after it changes the time stamp.

Edit: 'man sudoers' just answered my question.

The pound sign (‘#’) is used to indicate a comment (unless it is part of a #include directive... (and more)

Altoid

Member

Registered: 2017-05-07

Posts: 1,592  

Re: Services start issue

Hello:

... looks like all that script does is change the time stamp on /var/lib/sudo.

It's rather over my head but if it's to prevent sudo permissions from surviving a reboot it would not have to do much more. (?)

... only command it takes is 'start'.
... (stop|restart|whatever) do nothing.

But I have at least three services that are not starting with the graphic interface or with the command line in a terminal.

... your user is in the sudo group, you should be able to use sudo with your password for all commands.

Hmmm ...
That I don't like.

I can at times be hasty and distracted (maybe it's age?) and recognise the need to be called to attention: requiring me to enter an admin PW does that.
I don't mind being able to run sudo for a selected few commands but not all/any commands.

... safe like sudo blkid to see if that works.

groucho@devuan:~$ sudo blkid
[sudo] password for groucho: 
/dev/sda1: UUID="1ACC-311B" TYPE="vfat" PARTUUID="000e0731-01"
--- snip ---
groucho@devuan:~$ 

It asks for a PW.
Probably because there isn't a dedicated file for that action in /etc/sudoers.d?
BTW: I have tried to create a working file there for tesing purposes but have failed, visudo -c does not like it..
See my other thread (where I split this one from).

What I don't understand is why user_shutdown works when the includedir directive in /etc/sudoers is commented out.

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

It is commented with a percent sign (%) instead of a number/pound sign (#)?

It's commented out in mine, too, but I can shutdown using sudo without password.

I can also ...
My guess is that it is because of the /etc/sudoers.d/user_shutdown file.
If so, % is not being used to comment a line.
But what is it for? (what's the sysntaxis?)

... also getting the same results as you for 'service --status-all' - it doesn't change when I try to start sudo.

OK ...
At least I have not screwed something up.  8^º

Can you start other unstarted services?

Maybe that's because sudo runs and then exits after it changes the time stamp.

No idea ...

But (from what I can understand) the issue goes further: I want to start a service and it will not start by any one of the two known methods.
Does not look right.

I ticked them in Applications -> System -> Services = [service], a pop-up for systemtoolsbackends.set asks me to authenticate and I type my root PW in.
Then I click Close but for some reason they won't start.

I suspect a problem somewhere. (?)
I also see the same problem in the Miyo Linux installation I have on another drive/same hardware.

Thanks for your input.

Cheers,

A.

chris2be8

Member

Registered: 2018-08-11

Posts: 313  

Re: Services start issue

By default sudo will ask for a password the first time you use it, then allow you to use it without asking for a password for 15 minutes. The sudo service clears that so you always get asked for a password the first time you use sudo after a reboot.

You can change how long it remembers by setting timestamp_timeout in /etc/sudoers. Setting it to 0 should make sudo always ask for a password when you use it.

It's a good idea to have another way to get to root (eg su) when experimenting with sudo. So a typo in /etc/sudoers won't lock you out. And keep one terminal session running as root and use another to test sudo as your id.

I'm not sure why you had to add a % to the line in /etc/sudoers.d/[file_name] (mentioned in the other thread). In the line you showed changing groucho to %groucho should make it match members of the group called groucho instead of user groucho. But it's been several years since I've had to use sudo to do more than changing to root.

Chris

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,501  

Re: Services start issue

Yes, I can start and stop services. Everything seems to be working fine here. I keep apache2 and samba turned off, and I start them on those rare occasions that I need them.

If you don't want the user to be able to use sudo for all commands, then remove that user from the sudo group. You'll still be able to shutdown, etc., becuase of sudoers.d/user_shutdown. And you don't need visudo to edit that file; just edit it as root.

To start smartmontools/smartd, edit /etc/default/smartmontools to uncomment #start_smartd=yes.

You don't have to start the sudo service. Use sudo if you want, or don't use it. It's obviously working correctly on your system.

I don't know what checkroot-bootclean.sh does. It doesn't show up in sysv-rc-conf as a service to start/stop, but there is a symlink for it to start in runlevel 1. I see no reason to mess with it.

Altoid

Member

Registered: 2017-05-07

Posts: 1,592  

Re: Services start issue

Hello:

... sudo service clears that so you always get asked for a password the first time you use sudo after a reboot.

That is a good thing (IMO) and what I was wanting to accomplish by starting sudo service.

... change how long it remembers by setting timestamp_timeout in /etc/sudoers.
Setting it to 0 should make sudo always ask for a password when you use it.

OK.

It's a good idea to have another way to get to root (eg su) ...

Yes.
My installation gets to root by means of su.

... had to add a % to the line in /etc/sudoers.d/[file_name] ...

Now I do, thanks to your post.   =-)

... changing groucho to %groucho should make it match members of the group called groucho instead of user groucho.

Indeed ...
That's exactly what it is doing, as there is a group called 'groucho'.
I cannot recall creating it myself, but that does not mean much.  8^/.

BTW:
Group 'groucho has Group ID 1000 and my user 'Julis Henry Marx' belongs to it.

I'll have to look into that and see where group 'groucho' came from.
I think it was created at installation time. (?)

I'll see what happens if I take myself out of it.

But then, if I am the user groucho, why didn't using groucho (instead of %groucho) work?
Could it be that there's a sort of hierachy which which sudo works?
ie: first groups matching and then users?

I have a feeling that there being a group with a name that matches a user name is confusing sudo.
ie: user groucho belonging to group groucho.

I'll try to clean this up and see how it goes.

Thank you very much for your input.

Cheers,

A.

Altoid

Member

Registered: 2017-05-07

Posts: 1,592  

Re: Services start issue

Hello:

... can start and stop services.
... seems to be working fine here.

Good ...
That's a relief.
Then it's an issue with my setup.

... want the user to be able to use sudo for all commands ...

Not all, I just want the user to be able to use sudo for some (inocuous) commands
The rest, run with su.

I used PCLinuxOS for a time and they have this idea (which I adhere to) about the use of sudo:

"When implementing sudo, care should be taken to limit a users entry in /etc/sudoers to the absolute minimum of specific commands needed to perform the task at hand."

To start smartmontools/smartd, edit /etc/default/smartmontools to uncomment #start_smartd=yes.

But why won't it start by using either the CLI or the graphical interface?
Both are correct ways of doing it. (?)

You don't have to start the sudo service.
Use sudo if you want, or don't use it.
It's obviously working correctly on your system.

Yes, it seems to be working OK.
There's still the issue of using % or not using % in the /etc/sudoers.d/ files but I have the feelong that it may be related to the existence of a group name matching a user name and the user belonging to that same group.

ie: user groucho belonging to group groucho.

It's all been very enlightening.

I don't know what checkroot-bootclean.sh does.
It doesn't show up in sysv-rc-conf as a service to start/stop, but there is a symlink for it to start in runlevel 1.
I see no reason to mess with it.

It's listed as a service to run in  Applications -> System -> Services = [service]. 

From: https://unix.stackexchange.com/question … it-scripts

"The *-bootclean.sh scripts clean up files that must or should not survive a reboot: files in /var/run, /var/lock, /tmp, etc.
Checkroot-bootclean.sh runs just after the root filesystem is mounted (which can remove spurious files created under directories that will soon become mount points, such as /run and potentially /tmp)"

I found it interesting to see what it did so I wanted to start the service.
The sudo service I understood and made sense to me to have it running.

What I was really looking for was something I recall seeing years ago (ca. 2000?) in my very early (and unsuccessful) attempts to install Debian on an old laptop.
After a certain amount of days, a script would run and inform you that X days had passed since the last file system check and was now running it. 
I have not seen it since in any distrbution I've tried.

Thanks a lot for your input.

Cheers,

A.

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,269  

Re: Services start issue

Regarding that "X days has passed ...", it sounds like the fsck output, telling you that the file system hasn't been checked in X days, and that a check is forced. Nowadays there is a tendency of not showing the startup messages, but rather just showing an image or a black screen until the desktop environment kicks in. This is something you can configure by changing the boot command line.

Regarding your sudo configuration, I suspect the issue is rather the absence or presence of a newline at the end of the line.

Altoid

Member

Registered: 2017-05-07

Posts: 1,592  

Re: Services start issue

Hello:

... the fsck output, telling you that the file system hasn't been checked in X days ...
... configure by changing the boot command line.

I like to see what goes on at boot time.
It is something I learned to do in my days as a MS minion.  :^,

So I have 'quiet' removed from the grub command line.

... suspect the issue is rather the absence or presence of a newline at the end of the line.

I'm sorry, I don't understand what you mean. 

Thanks for your input.

Cheers,

A.

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,501  

Re: Services start issue

Any time you create a user, there is a corresponding group of the same name created, and that is the primary group for the user. This is configured in /etc/adduser.conf. (I think if you add your user with 'useradd' instead of 'adduser' you won't get that behavior and will have to define group, shell, home and whatever else yourself.) Sudo will not be confused by this.

The % before sudo in /etc/sudoers is to identify sudo as a group. Groups are prefaced with %. (See man sudoers)

I just want the user to be able to use sudo for some (inocuous) commands
The rest, run with su.

Then get your user out of the sudo group, and if you want more than shutdown commands available, add those other commands to sudoers.d/user_shutdown. (The name is just a name - what's inside the file determines what it does.)
deluser groucho sudo will remove the user groucho from the sudo group. If you want the user to enter a password for sudo, then remove NOPASSWD: from the line in user_shutdown.

I don't know why smartmontools won't start from command line, but I'm sure there's a good reason for it. You can still use smartctl on the command line - it doesn't need to be running as a service for that. If you want it to run tests automatically and/or notify you by email if there's a problem, then you need to turn it on in /etc/default/smartmontools and configure /etc/smartd.conf to do what you want.

Back around 2000, you were probably using ext2 filesystems, which are not journaled and take a lot longer to do a filesystem check. Be glad you're not seeing those messages. The filesystem is being checked at boot, but the message probably goes by too fast for you to see it. Install bootlogd, and you can find those messages in /var/log/boot.

You can change how frequently the filesystem checks are done by running tune2fs.

Altoid

Member

Registered: 2017-05-07

Posts: 1,592  

Re: Services start issue

Hello:

... you create a user, there is a corresponding group of the same name created, and that is the primary group for the user.

I see ...
Now user groucho in group groucho makes all the sense to me.
Thank you for taking the time to explain that.  =-)

... configured in /etc/adduser.conf. (I think if you add your user with 'useradd' instead of 'adduser' you won't get that behavior and will have to define group, shell, home and whatever else yourself.) Sudo will not be confused by this.

OK.
Good to know.

And yes, I've very recently had to fix a cock-up and adduser groucho:groucho was what I used.
Almost locked myself out.

The % before sudo in /etc/sudoers is to identify sudo as a group.
Groups are prefaced with %. (See man sudoers)

Yes, that I saw.
And since I am the only user in group groucho ...

I just want the user to be able to use sudo for some (inocuous) commands
The rest, run with su.

... get your user out of the sudo group ...
... more than shutdown commands available, add those other commands to sudoers.d/user_shutdown.
(The name is just a name - what's inside the file determines what it does.)

OK. Now I have learned how to do that.

deluser groucho sudo will remove the user groucho from the sudo group.
If you want the user to enter a password for sudo, then remove NOPASSWD: from the line in user_shutdown.

OK.

I don't know why smartmontools won't start from command line, but I'm sure there's a good reason for it.
You can still use smartctl on the command line - it doesn't need to be running as a service for that.
If you want it to run tests automatically and/or notify you by email if there's a problem, then you need to turn it on in /etc/default/smartmontools and configure /etc/smartd.conf to do what you want.

smartmontools, sudo service and chkroot-bootclean won't start from the CLI or from the user interface.
I have not tried other unstarted services or stopping any already started service to check how far this behavious goes.

... were probably using ext2 filesystems, which are not journaled and take a lot longer to do a filesystem check.
Be glad you're not seeing those messages. =-)

The filesystem is being checked at boot, but the message probably goes by too fast for you to see it.
Install bootlogd, and you can find those messages in /var/log/boot.

Yes.
bootlogd is one of the first things I installed.
PCLinuxOS did not have it available (for some reason took it out of the repo) which, for a rolling release, made little sense to me.
It's one reason I left that distro, that boat rolls far too much for what I am used to and there are not enough life vests.   

You can change how frequently the filesystem checks are done by running tune2fs.

I'll check that out.

Thank you very mych for your input.
Much appreciated.

Cheers,

A.

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,269  

Re: Services start issue

ralph.ronnquist wrote:

    ... suspect the issue is rather the absence or presence of a newline at the end of the line.

I'm sorry, I don't understand what you mean.

Hmm. A "newline" is a character at the end of a line, and it belongs to the text of the line in the same way as space characters belong to the line, but it also is a separator between lines in the way space characters are separators between words. For visudo (and sudo, I guess) the (last) line must have a terminating newline.

Many editors though don't show much different for that last newline being there or not, and some editors (like vi) even force a final newline. Presumably the editor, jed(?), that you used, lets you end the last line without a newline character.

You can check that by making a one-line file, say xxxx.txt without entering a final newline, and then view it by cat xxxx.txt, which will show the text content of the file, and then, if the final newline is missing, the next command prompt becomes joined up on the same line.

So, you configuration file problem was that the first one-liner didn't have the terminating newline, and therefore visudo complained. As you added the % character to the beginning, you also happened to get a terminating newline, presumably because you then edited the file with a different editor (eg through visudo). The fix was due to that newline, and adding the % character "merely" changed the semantics of the line.

Altoid

Member

Registered: 2017-05-07

Posts: 1,592  

Re: Services start issue

Hello:

A "newline" is a character at the end of a line, and it belongs to the text of the line in the same way as space characters belong to the line, but it also is a separator between lines in the way space characters are separators between words.

I see ...
Sort of like what was once known as (this dates me) CR or 'carriage return'.
Typing machines and telex terminals from long ago.

For visudo (and sudo, I guess) the (last) line must have a terminating newline.

OK.

Many editors though don't show much different for that last newline being there or not, and some editors (like vi) even force a final newline.
Presumably the editor, jed(?), that you used, lets you end the last line without a newline character.

OK.

You can check that by making a one-line file, say xxxx.txt without entering a final newline, and then view it by cat xxxx.txt, which will show the text content of the file, and then, if the final newline is missing, the next command prompt becomes joined up on the same line.

Indeed ...  =-)

groucho@devuan:~$ cat nonewline.txt
this is a test file made with jed without a final new_linegroucho@devuan:~$

groucho@devuan:~$ cat newline.txt
this is a test file made with jed with a final new_line 
groucho@devuan:~$ 

... configuration file problem was that the first one-liner didn't have the terminating newline, and therefore visudo complained.

Yes.
But in a very ambiguous manner.
Why not just print "new line character missing"?

As you added the % character to the beginning, you also happened to get a terminating newline, presumably because you then edited the file with a different editor (eg through visudo). The fix was due to that newline, and adding the % character "merely" changed the semantics of the line.

Exactly as you say:

1.
edit user_linssid

groucho ALL=(ALL) NOPASSWD:/usr/bin/linssid[cr]  <- this [cr] is the 'new line' character and % is edited out

2. Check with visudo -c

[root@devuan groucho]# visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/README: parsed OK
/etc/sudoers.d/user_dmesg: parsed OK
/etc/sudoers.d/user_linssid: parsed OK
/etc/sudoers.d/user_shutdown: parsed OK
[root@devuan groucho]# 

Thank you very much for taking the time to explain this to me.
Much obliged.

Now I'm confident I'll be able to write files for /etc/sudoers.d/ as needed.

Cheers,

A.

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,269  

Re: Services start issue

Sort of like what was once known as (this dates me) CR or 'carriage return'.
Typing machines and telex terminals from long ago.

Almost exactly right, I'd say. Time has blessed us with three different ways of ending a line, all relating back to the use of these characters for printer control, and basically a matter of how it is represented on file. So, nowadays we have:

• the Microsoft line ending idea of using both CR (carriage return) and LF (line feed),

• the Apple idea of ending lines with only CR, and

• the Unix (and Linux) idea of ending lines with LF.

That line ending are characters within the files, to make up the traditional "text file" representation. Obviously the Unix idea is the right way, and the others are merely weak attempts of obfuscation.

For some reason, the fourth option of LF+CR never took hold, even though that's really the mechanical sequence that got implemented in type writers, and probably the "safest" motion for a ribbon printer, which otherwise might smudge the printing.

Altoid

Member

Registered: 2017-05-07

Posts: 1,592  

Re: Services start issue

Hello:

Almost exactly right ...
... with three different ways of ending a line ..
... line ending are characters within the files ...

Learned quite a few things today. =^)
Thank you.

Now, off to see if I can find out how to recover my Devuan installtion from whatever apt-get clean and apt-get autoclean (apparently) did to it.

Cheers,

A.

Geoff 42

Member

Registered: 2016-12-15

Posts: 462  

Re: Services start issue

Obviously the Unix idea is the right way, and the others are merely weak attempts of obfuscation.

The use of CR/LF predates Microsoft and was used by DEC (Digital Equipment Corp).

For some reason, the fourth option of LF+CR never took hold, even though that's really the mechanical sequence that got implemented in type writers, and probably the "safest" motion for a ribbon printer, which otherwise might smudge the printing.

No, the order that worked was CR/LF, when using a Teletype ASR 33 printer for your output. Having got your print head to the right hand side, you gave it the CR and the print head mechanism set off at high speed for the left hand side of the printer. While it was travelling across you put in the line feed, which is much quicker to execute. By the time you gave it the first character of the next line the print head was in place and all was well. If you gave them in the order LF/CR then the first character of the next line was printed while the print head was still whizzing back and ended up being printed somewhere in the middle of the next line but smudged. I know, I have tried it! We used ASR33s for the output from our isotope counters, using the paper tape punch for our data transfer to our ICL 1903A.

https://en.wikipedia.org/wiki/Teletype_Model_33

Geoff

Last edited by Geoff 42 (2018-09-04 10:10:55)